A introdução do mais novo membro da família do cloud computing é "TI como serviço." É compreensível que cause certa confusão, por que, afinal, soa como mais uma maneira de descrever a "nuvem privada", certo? Não, na verdade é aplicável a modelos privados e públicos. Igualar “cloud computing" com "TI como Serviço" é um desserviço, assim como tornar sinônimos “Infraestrutura 2.0" e "cloud computing". Estes três conceitos, modelos e tecnologias são altamente integradas e em alguns casos mesmo interdependentes, mas não são a mesma coisa.
Na explicação mais simples possível: Infraestrutura 2.0 possibilita a computação em nuvem que assim possibilita a TI como Serviço.
Agora que nós colocamos esses conceitos, vamos analisar com mais profundidade.
POSSIBILITAR NÃO QUER DIZER SER IGUAL A
Uma das questões centrais parece ser o ímpeto de igualar "possibilitar" com "ser igual a". Existe uma relação entre os três conceitos tecnológicos citados acima, mas eles não são equivalentes e nem devem ser tratadas como tal. Como SOA, as diferenças entre eles giram principalmente em torno do nível de abstração e das camadas em que operam. Não as camadas do modelo OSI e sim as camadas de uma arquitetura de data center.
Vamos começar na parte inferior, OK?
INFRAESTRUTURA 2.0
Na camada mais baixa da arquitetura está a Infraestrutura 2.0. Ela é focada em prover dinamismo e colaboração de toda a rede e da infraestrutura de rede para entrega de aplicativos. É a maneira pela qual tradicionais componentes básicos desconectados dos data centers (de um ponto de vista de comunicação e gerenciamento) são imbuídos com a capacidade de conectar-se e colaborar-se. Isto é primeiramente alcançado por meio de APIs abertas e baseadas em padrões, que fornecem um conjunto detalhado de funções operacionais, oferecendo uma variedade de métodos de programação, tais como sistemas de orquestração, aplicativos customizados e através da integração com soluções tradicionais de gestão de data centers. Infraestrutura 2.0 se baseia em tornar a rede mais inteligente, tanto a questão de gerenciamento como do tempo de execução. Mas no caso de sua relação com a cloud computing com a TI como Serviço, o foco é principalmente no gerenciamento.
A Infraestrutura 2.0 inclui a habilitação de todos os serviços, incluindo roteadores, switches, balanceadores de carga, aceleradores de aplicativos, firewalls, componentes de segurança de aplicativos web de servidores (físicos e virtuais) e os outros mais. Em sua essência, são componentes com APIs fornecidas.
CLOUD COMPUTING
A cloud computing é a mais próxima do SOA no que diz respeito a permitir serviços operacionais, da mesma maneira como SOA atua nos serviços de negócios. A computação em nuvem trabalha com a camada de serviços de infraestrutura e organiza-os de forma a codificar um processo operacional, que forneça um meio mais eficiente de como computação, armazenamento, rede e recursos de segurança são provisionados e gerenciados. A computação em nuvem, como a Infraestrutura 2.0, é uma tecnologia capacitadora. Sozinhos, estes serviços operacionais são geralmente discretos e são empacotados especificamente como o meio para um fim - provisionando serviços de TI sob demanda.
A cloud computing é o serviço que habilita serviços operacionais e também traz consigo a noção de uma API. No caso da computação em nuvem, essa API serve como uma estrutura através da qual, operações específicas podem ser realizadas apenas pressionando uma botão.
TI COMO SERVIÇO
A TI como Serviço, ao contrário da cloud computing, não é só projetada para ser consumida por outras pessoas de TI, mas também por pessoas (supostamente) de negócios. A TI como Serviço amplia o provisionamento e gerenciamento de recursos e passa a incluir não só os serviços operacionais, mas os serviços que são mais claramente ligados ao negócio, tais como gerenciamento de identidade e acesso aos recursos.
A TI como Serviço baseia-se nos serviços prestados pela computação em nuvem, que é muitas vezes chamada de um framework em nuvem ou uma API em nuvem, e fornece os meios pelos quais os recursos podem ser provisionados e gerenciados. Neste momento, admito que soa terrivelmente parecido com a cloud computing, mas a abstração é um pouco maior. Em uma API de cloud computing interagimos mais diretamente com os recursos operacionais e de computação. Estamos provisionando, primeiramente, serviços de infraestrutura, mas estamos fazendo em uma camada muito acima e de uma maneira que torna fácil para os desenvolvedores de negócios, de aplicações e para os analistas fazerem.
CAMADA UM
Para cumprir essa estrutura você necessitará de pelo menos dois servidores e um balanceador de carga, um servidor de armazenamento de dados, e, embora ainda desconhecido pelo usuário empresarial, você deve ter as regras do firewall, a fim de garantir que a aplicação só é acessível para os usuários indicados. Assim, na camada inferior da estrutura (Infraestrutura 2.0) você precisa de um conjunto de componentes que correspondam a essas funções e que devem estar habilitados com uma API (ou, no mínimo, poderem ser automatizadas através de métodos tradicionais de criação de scripts). Agora, a tarefa real de configurar um balanceador de carga não é apenas uma questão de API. Isso requer vários passos para autenticar e configurar - na ordem certa - esse componente. É o mesmo caso de muitos componentes na camada de Infraestrutura 2.0: as APIs devem permitir flexibilidade para ser combinadas de forma a serem adaptáveis a cada ambiente único em que podem ser utilizadas. Assim o que você acaba obtendo é um conjunto de serviços de infraestrutura que compõem as APIs adequadas para cada componente, com base nas políticas operacionais específicas em vigor.
CAMADA DOIS
Nessa próxima camada até que você terá mais frameworks abstratos. A "API em nuvem" nesta camada pode prestar serviços como "auto-escalação", que requer uma grande quantidade de configuração e de registro de componentes com outros componentes. Há automação e orquestração que ocorrem, tornando a camada muito mais complexa, mas estritamente mais focada do que na camada anterior da infraestrutura. É nessa camada que os serviços se tornam mais personalizados e capazes de fornecer opções customizadas aos negócios e aos clientes. É também nesta camada que as coisas se tornam operacionalmente mais focadas, com o provisionamento de "aplicativos", compreendendo, talvez, o provisionamento de ambos os recursos de computação e armazenamento. Esta camada também estabelece a base para medição e controle (porque você quer dar visibilidade, certo?) como um determinado serviço ou serviços de monitoramento múltiplos recursos de infraestrutura.
CAMADA TRÊS
Na camada superior está o TI como Serviço, e este é o lugar onde os sistemas se tornam muito abstratos e um verdadeiro “Menu de TI A La Carte", que é o objetivo final de acordo com a maioria dos especialistas. Esta camada oferece uma interface em nuvem de forma que torna o auto-atendimento possível. Pode parecer complicado, mas quando você finaliza o trabalho, percebe valorização do que existe. TI como Serviço é o ponto alto de todo o trabalho feito nas camadas anteriores, e coloca os layers em sintonia até que eles estejam no ponto para serem consumíveis. Isso significa serem fáceis de compreender e não exigirem nenhum real entendimento técnico do que está acontecendo. Afinal, um usuário da empresa ou desenvolvedor de aplicações não precisa saber como os recursos de servidor e armazenamento são provisionados, e sim apenas os tamanhos e quanto isso vai custar.
A TI como Serviço, em última análise, permite que o usuário final solicite serviços de TI para satisfazer os requisitos específicos de aplicação, associados ao funcionamento de um aplicativo. Isso significa disponibilidade, escalabilidade, segurança, monitoramento e desempenho.
UMA ARQUITETURA DINÂMICA DE DATA CENTER
Uma das primeiras perguntas que devem vir à sua mente é: por que isso importa? Afinal, pode-se cortar a camada do "cloud computing" e ir diretamente de Infraestrutura 2.0 para TI como Serviço. Embora isso seja tecnicamente verdade, elimina um dos maiores benefícios de uma arquitetura em camadas e altamente abstrata: agilidade. Ao apresentar cada camada à camada acima como serviço, estamos efetivamente empregando os princípios de uma arquitetura orientada a serviços e separando a implementação da interface. Isso proporciona a habilidade de modificar a aplicação sem afetar a interface, o que significa menos downtime e muito pouco - se houver - modificação em camadas acima da camada cuja se está modificando. Isto traduz-se no fim das contas em independência do provedor e capacidade para evitar ficar refém do fornecedor. Se dois componentes, digamos, um switch Juniper e um switch Cisco estão habilitados como meios de serviços, então torna-se possível mudar os dois na camada de aplicação, sem a necessidade de mudanças afetarem a interface e as camadas superiores da arquitetura.
É um polimorfismo aplicado a uma operação de data centers ao invés de operações de um único objeto, para colocar a situação em linguagem de desenvolvedor. É SOA aplicado a um data center ao invés de um aplicativo, para colocar em linguagem de um arquiteto.
É uma arquitetura de arroz com feijão. E como sabemos, todo brasileiro não dispensa arroz com feijão, certo?
Participe do fórum do maior instituto de Service Desk e Field Support do mundo!
Saiba das últimas novidades do mercado de Service Desk e Field Support
Nenhum comentário:
Postar um comentário