Hoje, uma das perguntas mais ouvidas nos corredores de um provedor de infraestrutura é como explicar o valor dessa infraestrutura à comunidade de desenvolvedores. O problema é que a maioria dos benefícios da infraestrutura só é obtida após a implantação em produção. Nenhum deles realmente oferece valor direto ao desenvolvedor, pelo menos não de uma forma significativa que afete sua rotina diária.
Os benefícios que vão além do desenvolvimento são algo de que os desenvolvedores certamente estão cientes. Em nosso relatório de 2018, Estado da Entrega de Aplicações uma pequena porcentagem dos participantes era composta por desenvolvedores. Mas essa parcela se manifestou de forma contundente sobre os serviços de aplicação que desejava implantar. Alguns desses serviços de aplicação — balanceamento de carga, armazenamento em cache e aceleração — são implantados tanto como parte da própria aplicação quanto como infraestrutura. As otimizações de TCP e o WAF quase sempre são serviços de infraestrutura, implantados a montante (no caminho dos dados), à frente das aplicações (sejam elas monolíticas ou baseadas em microsserviços).
Todos esses serviços de aplicação agregam valor: redução de riscos, melhoria de desempenho e escalabilidade. No entanto, esses são benefícios para a aplicação e para o negócio; eles beneficiam os desenvolvedores após a entrega da aplicação em produção. É difícil identificar — quanto mais explicar — os benefícios da infraestrutura antes da entrega, ou seja, como parte do ciclo de desenvolvimento.
Mas, à medida que continuamos adotando contêineres e microsserviços, o valor da infraestrutura antes e depois da entrega se torna mais evidente.
Como ocorre com a maioria das tecnologias emergentes, os primeiros dias de uma nova arquitetura de aplicações trazem consigo pouquíssima infraestrutura. Talvez seja surpreendente para os desenvolvedores saber que a arquitetura de aplicações influencia significativamente a infraestrutura de serviços de aplicações. Com a migração para aplicações web de três camadas, surgiu a escalabilidade (balanceamento de carga). Com a adoção da Web 2.0 e sua camada de apresentação responsiva, surgiu a infraestrutura de aceleração de front-end. Com o advento dos dispositivos móveis e a crescente digitalização de todos os setores, vimos a infraestrutura reagir com serviços de segurança como WAF, proteção contra DDoS e defesa contra bots.
Então, o que vemos acontecer neste momento é que os desenvolvedores estão codificando recursos de serviços de infraestrutura em suas aplicações. Os desenvolvedores estão transformando em código aquilo que tradicionalmente era responsabilidade dos serviços upstream. Novas tentativas realizadas pelos balanceadores de carga. mTLS fornecido pelas plataformas ou pelos proxies. Controle de acesso para restringir a comunicação a clientes legítimos.
Essas são responsabilidades de infraestrutura que, devido ao caráter ainda incipiente dos frameworks de contêineres e à rápida adoção, acabaram sendo assumidas pelos desenvolvedores.
Mas, como sempre aconteceu, isso está mudando. Assim como as arquiteturas de aplicações anteriores impulsionaram mudanças na infraestrutura de rede, os contêineres e microsserviços também estão fazendo isso. Só que, desta vez, as mudanças não vêm na forma de um novo equipamento. O que está acontecendo agora é um movimento para integrar os serviços de aplicação de que os desenvolvedores precisam ao ambiente de contêineres. É aí que entra a malha de serviços, oferecendo valor real e quantificável diretamente aos desenvolvedores.
Como explicou Andrew Jenkins, arquiteto-chefe da Aspen Mesh em uma entrevista ao Linux.com:
“É impressionante como é fácil começar a criar um serviço web hoje em dia. O código cabe em um tuíte. No entanto, isso ainda não é um serviço web de verdade. Para torná-lo resiliente e escalável, é preciso adicionar alguns recursos ao plano de dados da aplicação. Ele precisa usar TLS, tentar novamente em caso de falha, aceitar solicitações apenas deste serviço, mas não daquele, verificar a autenticação do usuário e assim por diante. Uma malha de serviços pode ajudar você a obter essas funcionalidades no plano de dados sem precisar adicionar código à aplicação.”
O valor antes da entrega está na redução do escopo e na eliminação de código repetitivo, porém necessário, para lidar com a segurança básica e a escalabilidade em um ambiente de contêineres. Uma malha de serviços oferece uma grande variedade de recursos interessantes, mas seus benefícios continuam sendo, em grande parte, operacionais — observabilidade, responsabilização e escalabilidade. Para um desenvolvedor, o valor mais significativo está na eliminação de código (e, consequentemente, na redução da dívida técnica e arquitetural).
O uso de uma malha de serviços para escalar, proteger e monitorar aplicações implantadas em ambientes de contêineres elimina a necessidade de escrever código para tarefas que deveriam ser gerenciadas pela infraestrutura, mas que, até recentemente, eram delegadas aos desenvolvedores. Uma malha de serviços é uma forma de aliviar essa responsabilidade dos desenvolvedores e devolver a eles um tempo precioso, que pode ser usado para criar serviços e aplicações que, por sua vez, gerem valor para a empresa.
Sobre o autor
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 VittiePublicaçõ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
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
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
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
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
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
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...