Hierarquia de necessidades de automação de Maslow
Se há algo mais popular do que contêineres atualmente, provavelmente é algo baseado em contêineres, como serverless. Além de ser o garoto “cool” do pedaço agora, também é o foco de quão importante a automação e a orquestração* são para os aplicativos modernos.
Quase todos os dias surgem algum novo componente nas arquiteturas de contêineres e, com ele, o nível apropriado de automação. Se algo puder ser automatizado em um mundo de contêineres, será. Uma infinidade de APIs e uma dependência de artefatos baseados em configuração/modelo impulsionam a evolução quase contínua da automação em ambientes baseados em contêineres. Se a economia de API é importante para a transformação digital dos negócios, a outra economia de API é crítica para a transformação digital da TI.
Os ambientes de contêiner não são exceção e, à medida que continuam a chegar aos ambientes de produção, torna-se cada vez mais importante que os serviços upstream (N-S) não apenas consigam entregar os aplicativos que estão sendo dimensionados e servidos dentro desses ambientes altamente voláteis, mas também que se integrem a eles nas camadas de automação e orquestração.
Isso ocorre porque algumas camadas dessa “pilha” de tecnologia são mais voláteis do que outras. A criação e destruição de contêineres, por exemplo, acontecem com muito mais regularidade do que a criação e/ou destruição de clusters inteiros. De fato, o relatório de adoção do Docker do Data Dog HQ observa que "em março de 2017, cerca de 40% dos clientes do Datadog que executavam o Docker também estavam executando o Kubernetes , Mesos, Amazon ECS , Google Container Engine ou outro orquestrador". A automação/orquestração é essencial para o sucesso do contêiner, principalmente em seu núcleo. Isso significa que, à medida que avançamos, é fundamental que algumas necessidades de automação sejam atendidas o mais rápido (e completamente) possível, porque elas são a base para todo o resto.
Isso também é verdade para ambientes de nuvem. Afinal, não é apenas a volatilidade que impulsiona a necessidade de automação e orquestração, mas também a agilidade. O complexo modelo de “self-service” associado à computação em nuvem exige automação para dar suporte à noção de arquiteturas elásticas e sob demanda da computação em nuvem dentro de um modelo de computação utilitária. Há um conjunto identificável de necessidades de automação comuns à nuvem e aos contêineres que estabelecem a base para entender seu valor para o negócio.
Assim como a Hierarquia de Necessidades de Maslow, a Hierarquia de Necessidades de Automação se baseia na premissa de que há necessidades de “deficiência” que devem ser atendidas para progredir em direção a necessidades de ordem superior que permitam o crescimento.
É preciso satisfazer as necessidades de déficit de nível mais baixo antes de prosseguir para atender às necessidades de crescimento de nível mais alto. Quando uma necessidade deficitária é satisfeita, ela desaparece, e nossas atividades se tornam habitualmente direcionadas para atender ao próximo conjunto de necessidades que ainda precisamos satisfazer. Essas então se tornam nossas necessidades mais importantes. No entanto, as necessidades de crescimento continuam a ser sentidas e podem até se tornar mais fortes depois de serem atendidas. Uma vez que essas necessidades de crescimento tenham sido razoavelmente satisfeitas, pode-se atingir o nível mais alto chamado autorrealização. -- https://www.simplypsychology.org/maslow.html
Em essência, essa Hierarquia de Necessidades de Automação específica se concentra nas necessidades fundamentais em torno do dimensionamento de aplicativos e seus serviços compostos. Como explica o talentoso engenheiro da F5 que apresentou este conceito pela primeira vez: “A automação na parte inferior é mais valiosa porque acontece mais e é crucial para que um aplicativo permaneça online. A automação no topo é menos valiosa porque acontece com menos frequência (talvez apenas "uma vez") e acontece ao mesmo tempo em que muitas pessoas já estarão fazendo coisas manuais.”
Essas são as necessidades “básicas” de automatizar a criação/destruição de contêineres/máquinas virtuais e aplicativos, o que é essencial não apenas para a escala, mas também para a eficácia da escala. Essa eficácia é importante para restringir custos e aliviar o fardo de escala tradicionalmente imposto às operações manuais (dispendiosas). Dado o volume e a frequência com que tais eventos ocorrem hoje em dia, a automação é uma exigência, não algo desejável. É uma necessidade de deficiência , o que significa que se ela não for atendida, há poucos motivos para se preocupar com automação de ordem superior e menos frequente.
Isso é especialmente verdadeiro para contêineres e parece validado pela Data Dog novamente quando observa que "os contêineres têm uma vida útil média de 2,5 dias, enquanto em todas as empresas, as VMs tradicionais e baseadas em nuvem têm uma vida útil média de 23 dias". Isso parece ser impactado pela automação. “Em organizações que executam o Docker com um orquestrador, a vida útil típica de um contêiner é inferior a um dia. Em organizações que executam o Docker sem orquestração, o contêiner médio existe por 5,5 dias.”
A capacidade de automatizar a criação/destruição de contêineres e, posteriormente, aplicativos é fundamental para concretizar a velocidade e a agilidade de escala necessárias para que as organizações colham os benefícios dos contêineres em ambientes tradicionais e baseados em nuvem.
As necessidades de automação de ordem superior são basicamente necessidades de roteamento e se enquadram nas necessidades de crescimento. As necessidades de crescimento são buscadas quando as necessidades básicas (deficiência) são atendidas. A criação/destruição de clusters e as alterações de roteamento acontecem com pouca frequência e só se tornam valiosas quando o aplicativo está instalado e pode ser dimensionado. Isso se torna essencial quando o ambiente migra de desenvolvimento/teste para um ambiente de produção e passa a ser considerado responsável por gerar valor comercial ao fornecer aplicativos. Afinal, encaminhar para um aplicativo que não responde é como dar um abraço em um homem faminto. A sensação agradável e aconchegante não atende à necessidade básica de comida. Uma pesquisa da Mesosphere de 2016 com seus usuários descobriu que 62% deles já estavam usando contêineres em ambientes de produção. Uma pesquisa da Portworx de 2017 na conferência focada em contêineres DockerCon descobriu que 67,2% dos entrevistados estavam usando contêineres em produção. O que significa que as necessidades de roteamento estão rapidamente se tornando importantes, pelo menos para o subconjunto de organizações que adotam contêineres.
O objetivo final da autorrealização dos negócios – crescimento – não pode ser alcançado até que toda a hierarquia seja cumprida; isto é, até que toda a “pilha” seja automatizada e orquestrada. Portanto, é certo que aqueles que vivem principalmente no plano de dados NS orquestrarão de baixo para cima, permitindo primeiro as necessidades de dimensionamento do ambiente e trabalhando até as necessidades de roteamento, onde ocorre a transição do tráfego NS para EW. Isso também é evidente no desenvolvimento contínuo do ecossistema mais fortemente acoplado em torno dos próprios orquestradores de contêineres, como o Kubernetes. Um dos desenvolvimentos mais recentes tem se concentrado nas necessidades de “roteamento” com a inclusão de controladores de entrada que roteiam na camada 7 (URI/API) para garantir que a transição do NS para serviços EW ocorra sem problemas. Esse componente também deve ser eventualmente integrado (automatizado) para satisfazer as necessidades de roteamento e continuar a impulsionar as organizações na hierarquia para alcançar o crescimento.
Traduzir isso para construções específicas de contêiner nos permite mapear as necessidades de automação do ambiente de contêiner para os serviços na rede que dão suporte à sua necessidade de escala para concretizar o crescimento. Tanto a construção do contêiner quanto a do serviço de rede/aplicativo exigem automação. Criar cem contêineres para dimensionar um aplicativo sem automatizar simultaneamente os serviços responsáveis por gerenciá-los durante a entrega gera necessidades não atendidas. Essas construções de rede podem existir como construções de contêineres nativos ou como serviços de aplicativos existentes adaptados para se adequarem nativamente ao ambiente do contêiner. Os detalhes da implementação variam de acordo com a arquitetura e os requisitos operacionais, embora a existência de ambos os conjuntos de construções seja necessária para satisfazer as necessidades básicas (escala) e de crescimento (roteamento) para alcançar o sucesso.
Em todos os casos, o sucesso dos contêineres e da nuvem depende muito de seus ecossistemas e isso significa dependência da economia de outras APIs para permitir a automação e a orquestração essenciais para o crescimento dos negócios por meio de iniciativas de transformação digital.
* Acho frustrante que os conceitos de automação e orquestração pareçam estar misturados no mundo dos contêineres, justapondo um ao outro. Mas por enquanto, vamos ignorar isso e tentarei manter o pedante dentro de casa, onde ele pertence. Dentro da minha cabeça. Gritando. Desesperadamente.