A verdade surpreendente sobre a transformação digital: o caos da nuvem

Ecossistema F5 | 04 de junho de 2018

Este é o segundo artigo de uma série sobre os desafios decorrentes da transformação digital.

Caos na nuvem.

Neste exato momento, algum engenheiro esperto deve estar observando que essa expressão é redundante. Afinal, a nuvem é um caos, com sua falta de governança e sua abordagem laissez-faire para proteger aplicativos lançados em suas profundezas brancas e fofas sem um cronograma bem definido.

Façamos uma pausa aqui para observar que o caos associado à nuvem é, na maioria das vezes, um problema de pessoas e processos , não um problema técnico.

Isso não quer dizer que não existam desafios técnicos — ou, pelo menos, arquiteturais — associados à nuvem. Alguns deles estão relacionados às complexidades das redes virtuais. Mas a maioria é de natureza arquitetural. Um desses desafios arquiteturais está relacionado à própria natureza da nuvem, com seu foco em cada aplicação.

Pensando bem, a nuvem pública e seu modelo de implantação são considerados a forma ideal de nuvem (a “forma de nuvem”, como diriam os platônicos). Isso significa que a nuvem privada também deve seguir seus princípios e apresentar as mesmas características.

Isso significa APIs e provisionamento por autoatendimento. Painéis e consoles baseados na web. Mas também significa uma mudança arquitetural para uma implantação totalmente voltada a uma única aplicação.

Arquiteturas dedicadas a cada aplicativo são a norma na nuvem. Os serviços são implantados e configurados para oferecer suporte a um aplicativo por vez e criar um caminho de dados exclusivo entre o usuário e o endpoint, passando por esses serviços. Isso contrasta fortemente com o projeto tradicional de redes de data centers, no qual grande parte da infraestrutura de rede e de serviços de aplicativos é compartilhada.

É a noção de “infraestrutura compartilhada” que se torna desafiadora em um mundo de DevOps e desenvolvimento ágil tão focado em cada aplicação quanto a nuvem pública.

As redes tradicionais de infraestrutura compartilhada resultam em “um único caminho válido da porta até o aplicativo”. Os desafios decorrentes dessa abordagem no mundo digital e dinâmico de hoje são:

  • Alinhamento de versões da infraestrutura. Um aplicativo pode exigir recursos fornecidos por uma atualização ou correção, enquanto outro depende da versão existente. Em geral, a infraestrutura compartilhada não permite diferentes versões no mesmo sistema e, portanto, pode prejudicar um aplicativo para favorecer outro.
  • Cronogramas de implantação conflitantes. Quando os recursos compartilhados são afetados, as empresas iniciam uma fase de negociação na qual as partes interessadas nos aplicativos tentam resolver conflitos nos cronogramas de implantação. O processo pode ser demorado (e é sempre desgastante), e ninguém sai ganhando quando o lançamento de um novo aplicativo ou de uma atualização é adiado devido a conflitos de cronograma.
  • Raio de impacto. É evidente que, se meu aplicativo causar uma falha em um sistema compartilhado, todos os aplicativos que dependem desse sistema também falharão. O raio de impacto da infraestrutura compartilhada é enorme e representa um fator significativo na relutância em ampliar o acesso ao pipeline de implantação para pessoas que não fazem parte da equipe de TI.
  • Solução de problemas. Tentar vasculhar logs agregados é uma tarefa árdua. Empresas muito bem-sucedidas foram construídas apenas com base na capacidade de analisar logs gigantescos e desagregar os dados novamente em fluxos por aplicação. Solucionar problemas em sistemas compartilhados é algo complexo e demorado, além de afetar negativamente o tempo médio de resolução, um KPI essencial para a TI moderna.

Na nuvem, normalmente nada disso é um problema. Há um caminho para cada aplicativo, pois os aplicativos geralmente são implantados de acordo com seu próprio cronograma e em seu próprio ambiente — muitas vezes por equipes diferentes.

Para preservar nossa sanidade (e nosso data center), precisamos adotar essa abordagem no ambiente local, seja em uma nuvem privada ou não.

Você ainda terá serviços de rede compartilhados. Firewalls, IPS/IDS, proteção contra DDoS e inspeção de usuários são, em grande parte, independentes das aplicações e podem (e devem) ser implementados em toda a empresa. Para todo o restante, há serviços e infraestrutura por aplicação (específicos para cada aplicação, se preferir). Essa separação lógica preserva a estabilidade e a segurança dos negócios, ao mesmo tempo que viabiliza um ambiente mais volátil e talvez instável, mais próximo das aplicações. Ela também mantém um caminho de dados para aplicações tradicionais (legadas e herdadas) que não exigem a velocidade e o suporte necessários para aplicações mais recentes. A rede por aplicação pode ser uma nuvem privada, vários clusters de contêineres ou alguma combinação dessas opções.

A união dos dois resultará em uma rede mais estável e resiliente, que também será flexível e rápida.

Uma abordagem de rede por aplicativo oferece diversos benefícios, além de mitigar os problemas decorrentes de uma abordagem compartilhada combinada com arquiteturas e modelos de entrega de aplicativos modernos:

  • Pipelines e cronogramas individuais. Posso programar minhas próprias implantações quando estiverem prontas, pois elas não afetam nenhum aplicativo ou infraestrutura além dos meus. Isso oferece a flexibilidade necessária para atender aos diferentes cronogramas que precisam ser contemplados em um data center moderno.
  • Raio de impacto restrito. Se minha implantação causar uma falha nos meus sistemas dedicados, a responsabilidade será toda minha. Isso não afetará nenhum outro aplicativo. Essa abordagem de caminho de dados dedicado por aplicativo também facilita a solução de problemas, pois posso ter certeza de que os logs e as mensagens de erro em todos os sistemas pertencem a mim e ao meu aplicativo.
  • A escalabilidade não se limita aos recursos da plataforma. Em um mundo altamente volátil e dinâmico, é praticamente impossível saber quando ocorrerá o próximo pico de visitantes, se algum conteúdo viralizará ou se, Deus nos livre, você estará sob ataque. Seja qual for a causa, quando há um aumento repentino na demanda por aplicativos em sistemas compartilhados (hardware ou software), a escalabilidade fica limitada aos recursos disponíveis na plataforma. O uso de uma arquitetura dedicada por aplicativo reduz essa limitação e permite que componentes individuais sejam expandidos conforme necessário para atender à demanda.
  • Oferece suporte a um verdadeiro modelo de infraestrutura como código. Os sistemas compartilhados usam configurações compartilhadas, mesmo que seja apenas uma configuração básica com políticas específicas para cada aplicativo. Esse modelo pode causar caos ao tentar implementar um modelo de infraestrutura como código , especialmente quando vários aplicativos tentam fazer atualizações ao mesmo tempo. As alterações podem afetar outros aplicativos sem aviso, ou as ações de commit e clonagem podem falhar porque outras pessoas bloquearam os recursos quando você precisa deles. Uma arquitetura por aplicativo garante que os artefatos de implantação pertençam a apenas um aplicativo e possam ser gerenciados adequadamente pelos responsáveis pelo aplicativo (sejam eles de desenvolvimento, DevOps, NetOps ou ).


Embora uma arquitetura por aplicativo não resolva todos os problemas decorrentes da transformação digital, ela pode contribuir muito para controlar o caos gerado pela nuvem. Ela oferece mais oportunidades para padronizar a segurança e também para dar suporte aos ambientes multinuvem que a maioria das empresas está adotando.

Fique de olho no próximo post desta série, no qual veremos em detalhes como lidar com quem está deixando a segurança de lado devido às pressões para acelerar a entrada no mercado decorrentes da transformação digital.

Compartilhar
Tags: 2018

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...