Por que os profissionais de DevOps devem se preocupar com as arquiteturas por aplicação?
Implícita nessa pergunta está a conclusão de que você deveria.
Há décadas, implantamos os serviços de aplicativos que compõem grande parte do pipeline de produção em plataformas compartilhadas. Serviços de aplicativos como balanceamento de carga, serviços de desempenho de aplicativos, WAF e identidade federada são fornecidos pelo NetOps em infraestrutura compartilhada, geralmente na forma de um Controlador de Entrega de Aplicativos (ADC).
Mas o tempo e a demanda – juntamente com arquiteturas de aplicativos emergentes, como microsserviços – estão forçando mudanças nesse pipeline . Essas mudanças são boas, tanto para NetOps quanto para DevOps, porque estão migrando para um modelo que se alinha mais de perto com cronogramas de implantação e práticas operacionais, como infraestrutura como código.
Existem alguns serviços de aplicativos que permanecem firmemente enraizados na infraestrutura compartilhada. DNS. Defesa 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 servir o negócio. Se esses serviços falharem? Nenhuma produtividade ou lucro em todo o negócio.
Mas outros serviços de aplicativos são altamente afins; suas configurações, APIs e serviços são frequentemente configurados especificamente para dar suporte a um único aplicativo. Não uma única arquitetura, mas uma única aplicação.
A responsabilidade por esses serviços está cada vez mais sendo transferida para as operações de aplicativos (DevOps) e para o envolvimento dos desenvolvedores que entregam os aplicativos. E embora um modelo compartilhado possa (e geralmente funciona) ainda funcionar para fornecer os serviços de entrega e segurança de aplicativos necessários, um modelo por aplicativo para muitos deles é desejável por vários motivos.
Primeiro, um modelo por aplicativo resolve de forma organizada os conflitos de cronograma de implantação . As organizações empresariais geralmente são limitadas por conflitos de infraestrutura compartilhada com relação à configuração e implantação dos serviços de aplicativos que ela suporta. Infraestrutura compartilhada significa recursos compartilhados, o que invariavelmente aumenta o potencial para um conflito de configurações. Ao eliminar essa possibilidade, a resistência a implantações mais frequentes ou fora do cronograma pode ser mitigada. Afinal, se um serviço de aplicativo for dedicado ao meu aplicativo e executado em sua própria plataforma com seus próprios recursos, o conflito será resolvido perfeitamente. Meu aplicativo, meu risco.
Em segundo lugar, um modelo por aplicativo oferece suporte a esforços de automação emergentes que incluem colocar em prática metodologias como infraestrutura como código. Ao dedicar recursos e plataforma a um único aplicativo, a configuração inclui apenas esse aplicativo. A imutabilidade pode ser imposta e o risco de entropia pode ser evitado. Na verdade, eu argumentaria ( e recentemente o fiz ) que não é possível criar uma infraestrutura imutável adequadamente sem uma arquitetura por aplicativo. Essa abordagem permite a inclusão em um pipeline de implantação contínua que se estende além da infraestrutura do aplicativo e para dentro da “rede”. Fornecer esse recurso significa transferir a responsabilidade da configuração e do gerenciamento contínuo do NetOps para o DevOps. A boa notícia é que com essa responsabilidade maior vem um controle maior, pois o DevOps se torna o "proprietário" do serviço do aplicativo e tem autoridade para atualizar, corrigir e reimplantar em seus próprios termos e cronogramas.
Por fim, um modelo por aplicativo é imediatamente mais portátil. Sem estar preso a uma plataforma compartilhada e depender quase exclusivamente de artefatos de implantação (configurações e modelos), a maior parte do pipeline de produção consegue migrar de nuvem para nuvem, do local para o externo, com muito menos atrito e esforço. Essa liberdade oferece às organizações a capacidade de escolher a melhor nuvem e local para o aplicativo em questão sem serem limitadas pelos custos associados à migração.
O DevOps pode se beneficiar muito ao incentivar a adoção de uma arquitetura por aplicativo para serviços de aplicativos, tanto no local quanto na nuvem pública. Com a NetOps sob pressão para fornecer maior controle e visibilidade a outros domínios operacionais, agora seria um bom momento para comer uma pizza e beber uma cerveja e conversar com seus colegas da NetOps sobre a mudança para oferecer suporte a uma arquitetura por aplicativo de última geração e centrada em aplicativos.