Hierarquia das Necessidades de Automação de Maslow

Ecossistema F5 | 07 de setembro de 2017

Se há algo mais em alta do que os contêineres no momento, provavelmente é alguma tecnologia baseada neles, como a computação sem servidor. Além de ser a novidade mais “descolada” do momento, ela também evidencia o quanto a automação e a orquestração* são importantes para as aplicações modernas.

Praticamente todos os dias surge algum novo componente para arquiteturas de contêineres e, com ele, o nível adequado de automação. Se algo puder ser automatizado no mundo dos contêineres, será. Uma infinidade de APIs e a dependência de artefatos baseados em configurações/modelos impulsionam a evolução quase contínua da automação em ambientes baseados em contêineres. Se a economia de APIs é importante para a transformação digital das empresas, então a outra economia de APIs é fundamental para a transformação digital da TI.

Os ambientes de contêineres não são exceção e, à medida que continuam avançando para os ambientes de produção, torna-se cada vez mais importante que os serviços upstream (N-S) sejam capazes não apenas de disponibilizar os aplicativos que estão sendo dimensionados e fornecidos a partir desses ambientes altamente voláteis, mas também de se integrar 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 a destruição de contêineres, por exemplo, acontecem com muito mais frequência do que a criação e/ou destruição de clusters inteiros. De fato, o relatório Adoção do Docker da Data Dog HQ observa que “em março de 2017, cerca de 40% dos clientes da Datadog que usavam Docker também usavam Kubernetes, Mesos, Amazon ECS, Google Container Engine ou outro orquestrador”. A automação/orquestração é fundamental para o sucesso dos contêineres, especialmente em seu núcleo. Isso significa que, à medida que avançamos, é imprescindível atender a algumas necessidades de automação da forma mais rápida (e completa) possível, pois elas são a base de todo o restante.

Isso também se aplica aos 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 “autoatendimento” associado à computação em nuvem exige automação para viabilizar o conceito de arquiteturas elásticas e sob demanda da computação em nuvem dentro de um modelo de computação como serviço público. Há um conjunto identificável de necessidades de automação comuns tanto à nuvem quanto aos contêineres que estabelece a base para compreender seu valor para os negócios.

Assim como a Hierarquia das Necessidades de Maslow, a Hierarquia das Necessidades de Automação baseia-se na premissa de que existem necessidades de “deficiência” que precisam ser atendidas para que se possa avançar em direção a necessidades de ordem superior que possibilitam o crescimento.

É preciso satisfazer as necessidades de deficiência dos níveis inferiores antes de avançar para as necessidades de crescimento dos níveis superiores. Quando uma necessidade de deficiência é satisfeita, ela desaparece, e nossas atividades passam a ser habitualmente direcionadas para atender ao próximo conjunto de necessidades que ainda não satisfizemos. Essas, então, tornam-se nossas necessidades mais relevantes. No entanto, as necessidades de crescimento continuam a ser sentidas e podem até se intensificar depois de despertadas. Quando essas necessidades de crescimento tiverem sido razoavelmente satisfeitas, pode-se alcançar o nível mais elevado, chamado de autorrealização. -- https://www.simplypsychology.org/maslow.html

Em sua essência, esta Hierarquia das Necessidades de Automação concentra-se nas necessidades fundamentais relacionadas ao dimensionamento de aplicações e dos serviços que as compõem. Como explica o talentoso engenheiro da F5 que apresentou esse conceito pela primeira vez: “A automação na base é a mais valiosa porque ocorre com maior frequência e é crucial para manter uma aplicação online. A automação no topo é a menos valiosa porque ocorre com menor frequência (talvez apenas "uma vez") e acontece ao mesmo tempo em que muitas pessoas já estarão realizando tarefas manualmente.”

hierarquia-das-necessidades-de-automação

Essas são as necessidades “básicas”: automatizar a criação e a destruição de contêineres, máquinas virtuais e aplicativos é fundamental não apenas para a escalabilidade, mas também para a eficácia dessa escalabilidade. Essa eficácia é importante para conter custos e aliviar a carga da escalabilidade, tradicionalmente atribuída a operações manuais (dispendiosas). Considerando o volume e a frequência com que esses eventos ocorrem atualmente, a automação é uma necessidade, não apenas algo desejável. Trata-se de uma necessidade básica, o que significa que, se ela não for atendida, não há muito motivo para se preocupar com automações de nível mais elevado e menos frequentes.

Isso é especialmente verdadeiro para contêineres e parece ser novamente corroborado pela Data Dog ao observar que “os contêineres têm uma vida útil média de 2,5 dias, enquanto, considerando todas as empresas, as VMs tradicionais e baseadas em nuvem têm uma vida útil média de 23 dias”. Ao que parece, isso é influenciado 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. Nas organizações que executam o Docker sem orquestração, um contêiner existe, em média, por 5,5 dias.”

A capacidade de automatizar a criação e a destruição de contêineres e, consequentemente, de aplicativos é essencial para alcançar a velocidade e a agilidade de escalabilidade necessárias para que as organizações aproveitem os benefícios dos contêineres tanto em ambientes tradicionais quanto na nuvem.

As necessidades de automação de nível mais elevado são, em grande parte, necessidades de roteamento e se enquadram no que chamamos de necessidades de crescimento. As necessidades de crescimento são buscadas depois que as necessidades básicas (de deficiência) são atendidas. A criação/destruição de clusters e as alterações de roteamento ocorrem com pouca frequência e só passam a agregar valor quando o aplicativo está implantado e pode ser escalado. Isso se torna imprescindível quando o ambiente migra de desenvolvimento/teste para produção e passa a ser usado para gerar valor para o negócio por meio da disponibilização de aplicativos. Afinal, rotear para um aplicativo que não consegue responder é como abraçar um homem faminto. A sensação calorosa e reconfortante não atende à necessidade básica de alimento. Uma pesquisa da Mesosphere com seus usuários, realizada em 2016, constatou que 62% deles já usavam contêineres em ambientes de produção. Uma pesquisa da Portworx realizada em 2017 na DockerCon, conferência voltada a contêineres, constatou que 67,2% dos entrevistados usavam contêineres em produção. Isso significa que as necessidades de roteamento estão rapidamente ganhando importância, pelo menos para o subconjunto de organizações que estão adotando contêineres.

necessidades-de-automação-de-contêineres

O objetivo final da autorrealização das empresas — o crescimento — não pode ser alcançado até que toda a hierarquia seja atendida, ou seja, até que toda a “pilha” seja automatizada e orquestrada. Portanto, é natural que aqueles que atuam principalmente no plano de dados N-S façam a orquestração de baixo para cima, atendendo primeiro às necessidades de escalabilidade do ambiente e avançando até as necessidades de roteamento, onde ocorre a transição do tráfego N-S para E-W. Isso também fica evidente no desenvolvimento contínuo de um ecossistema mais estreitamente integrado 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 fazem o roteamento na camada 7 (URI/API) para garantir que a transição dos serviços N-S para E-W ocorra de forma transparente. Esse componente também deverá, em algum momento, ser integrado (automatizado) para atender às necessidades de roteamento e continuar impulsionando as organizações rumo aos níveis mais altos da hierarquia, a fim de alcançar o crescimento.

Traduzir isso em estruturas específicas de contêineres nos permite associar as necessidades de automação do ambiente de contêineres aos serviços de rede que dão suporte à sua necessidade de escalabilidade para viabilizar o crescimento. Tanto as estruturas de contêineres quanto as de serviços de rede/aplicação exigem automação. Criar cem contêineres para escalar um aplicativo sem automatizar simultaneamente os serviços responsáveis por gerenciá-los durante a entrega resulta em necessidades não atendidas. Essas estruturas de rede podem existir como estruturas nativas de contêineres ou como serviços de aplicativos existentes adaptados para se integrarem de forma nativa ao ambiente de contêineres. Os detalhes de implementação variam de acordo com a arquitetura e os requisitos operacionais, embora a existência dos dois conjuntos de estruturas seja necessária para atender às necessidades básicas (escalabilidade) e de crescimento (roteamento) e alcançar o sucesso.

Em todos os casos, o sucesso dos contêineres e da nuvem depende fortemente de seus ecossistemas, o que significa depender da economia das Outras APIs para viabilizar a automação e a orquestração essenciais ao 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 ser confundidos no universo dos contêineres, como se fossem equivalentes. Mas, por enquanto, vamos simplesmente ignorar isso, e tentarei manter o pedante dentro de mim onde ele deve ficar. Dentro da minha cabeça. Gritando. Desesperadamente.

Compartilhar

Sobre o autor

Lori Mac Vittie
Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.

Mais publicações de Lori Mac Vittie

Publicações relacionadas no blog

Entrega e proteção de agentes de IA em fábricas de IA: F5 para a arquitetura de referência NVIDIA OpenShell para agentes de IA seguros
Ecossistema F5 | 21/10/2026

Entrega e proteção de agentes de IA em fábricas de IA: F5 para a arquitetura de referência NVIDIA OpenShell para agentes de IA seguros

As soluções da F5 ampliam a Arquitetura de Referência NVIDIA OpenShell para agentes de IA seguros.

Como medir – e minimizar – o custo total de propriedade do seu Kubernetes
Ecossistema F5 | 10/12/2020

Como medir – e minimizar – o custo total de propriedade do seu Kubernetes

O Kubernetes pode ser baixado e executado gratuitamente, mas sua manutenção está longe de não ter custos. Assim como outras grandes plataformas de código aberto que são “gratuitas” apenas em um sentido simplista, o Kubernetes quase certamente exigirá investimentos para ser implantado e operado.

As-Code: a pilha de TI contínua
Ecossistema F5 | 08/10/2018

As-Code: a pilha de TI contínua

Infraestrutura, configuração, pipeline, operações. De repente, tudo é “como código”. Lori MacVittie busca esclarecer a terminologia e identificar os diferentes componentes de uma stack contínua de TI.

O estado da entrega de aplicações em 2017: automação, APIs e DevOps
Ecossistema F5 | 17/04/2017

O estado da entrega de aplicações em 2017: automação, APIs e DevOps

Explore o relatório State of Application Delivery de 2017. Leia o blog retrospectivo da F5 sobre o início da ascensão das redes declarativas e dos pipelines de DevOps.

DevOps Summit: onde a rede foi convidada para a festa
Ecossistema F5 | 11/06/2015

DevOps Summit: onde a rede foi convidada para a festa

No DevOps Summit NY, falou-se muito não apenas sobre DevOps, mas também sobre contêineres, IoT e microsserviços. As sessões se concentraram não só na mudança cultural necessária para crescer em escala com uma abordagem DevOps, mas também fizeram questão de incluir...

F5 e Nutanix convergem em infraestrutura no .NEXT
Ecossistema F5 | 08/06/2015

F5 e Nutanix convergem em infraestrutura no .NEXT

Aplicações empresariais como Microsoft SharePoint e Exchange, juntamente com a VDI, continuam sendo a espinha dorsal da sua empresa. A produtividade, embora não seja tão atraente quanto o lucro, é um fator essencial para o sucesso das operações empresariais atuais. Deixar de...