Por que os profissionais de DevOps deveriam se importar com arquiteturas por aplicativo?

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

Essa pergunta traz implícita a conclusão de que você deveria fazer isso.

Há décadas, implantamos em plataformas compartilhadas os serviços de aplicação que compõem grande parte do pipeline de produção. Serviços de aplicação como balanceamento de carga, serviços de desempenho de aplicações, WAF e identidade federada são fornecidos pela equipe de operações de rede (NetOps) em uma infraestrutura compartilhada, muitas vezes na forma de um controlador de entrega de aplicações (ADC).

Mas o tempo e a demanda — juntamente com as novas arquiteturas de aplicações, como microsserviços — estão forçando mudanças nesse pipeline. Essas mudanças são positivas tanto para NetOps quanto para DevOps, pois promovem a transição para um modelo mais alinhado aos cronogramas de implantação e às práticas operacionais, como infraestrutura como código.

Alguns serviços de aplicativos permanecem firmemente estabelecidos em uma infraestrutura compartilhada. DNS. Proteção contra ataques DDoS volumétricos. Firewalls de rede. Esses serviços são, por natureza, serviços corporativos . Ou seja, eles são projetados para proteger, defender e atender à empresa. Se esses serviços falharem, não haverá produtividade nem lucro em toda a empresa.

Mas outros serviços de aplicação têm alta afinidade com aplicações específicas; suas configurações, APIs e serviços costumam ser definidos especificamente para dar suporte a uma única aplicação. Não a uma única arquitetura, mas a uma única aplicação.

A responsabilidade por esses serviços está cada vez mais sendo transferida para as operações de aplicações (DevOps), envolvendo os desenvolvedores responsáveis por entregá-las. Embora um modelo compartilhado ainda possa funcionar — e muitas vezes funcione — para fornecer os serviços necessários de entrega e segurança de aplicações, por vários motivos é preferível adotar um modelo específico por aplicação para muitos desses serviços.

Primeiro, um modelo por aplicativo resolve de forma simples os conflitos de cronograma de implantação. As organizações empresariais muitas vezes enfrentam limitações devido a conflitos na infraestrutura compartilhada relacionados à configuração e à implantação dos serviços de aplicativos aos quais ela dá suporte. Infraestrutura compartilhada significa recursos compartilhados, o que invariavelmente aumenta a possibilidade de conflito entre configurações. Ao eliminar essa possibilidade, é possível reduzir a resistência a implantações mais frequentes ou fora do cronograma. Afinal, se um serviço de aplicativo é dedicado ao meu aplicativo e executado em sua própria plataforma, com seus próprios recursos, o conflito é facilmente resolvido. Meu aplicativo, meu risco.

Em segundo lugar, um modelo por aplicativo dá suporte a iniciativas emergentes de automação que incluem a adoção de metodologias como infraestrutura como código. Ao dedicar recursos e uma plataforma a um único aplicativo, a configuração inclui apenas esse aplicativo. A imutabilidade pode ser garantida, evitando-se o risco de entropia. Na verdade, eu diria (e disse isso recentemente) que não é possível implementar corretamente uma infraestrutura imutável sem uma arquitetura por aplicativo. Essa abordagem permite a inclusão em um pipeline de implantação contínua que vai além da infraestrutura de aplicativos e chega à “rede”. Oferecer esse recurso significa transferir a responsabilidade pela configuração e pelo gerenciamento contínuo de NetOps para DevOps. A boa notícia é que, com essa responsabilidade maior, vem também um controle maior, pois DevOps passa a ser o “proprietário” do serviço de aplicativo e ganha autonomia para atualizá-lo, aplicar correções e reimplantá-lo de acordo com seus próprios critérios e cronogramas.

Por fim, um modelo por aplicativo oferece, de imediato, maior portabilidade. Sem ficar vinculado a uma plataforma compartilhada e dependendo quase exclusivamente de artefatos de implantação (configurações e modelos), a maior parte do pipeline de produção pode migrar de uma nuvem para outra ou de um ambiente local para a nuvem, com muito menos atrito e esforço. Essa liberdade permite que as organizações escolham a melhor nuvem e localização para o aplicativo em questão, sem as limitações impostas pelos custos associados à migração.

O DevOps pode se beneficiar muito ao incentivar a adoção de uma arquitetura por aplicativo para os serviços de aplicações, tanto no ambiente local quanto na nuvem pública. Com o NetOps sob pressão para oferecer mais controle e visibilidade a outras áreas operacionais, este seria um bom momento para pedir uma pizza, tomar uma cerveja e conversar com seus colegas de NetOps sobre a adoção de uma arquitetura de última geração, centrada em aplicações e baseada no modelo por aplicativo.

Sobre o autor

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