Um número cada vez maior de serviços de aplicativos é parte integrante de uma arquitetura nativa da nuvem. Isso explica, em parte, por que observamos uma transferência da responsabilidade pelos serviços de aplicativos das operações de TI para o DevOps.
Acompanhamos mais de 30 serviços de aplicações diferentes em nossa pesquisa Estado dos Serviços de Aplicações. Há outros, e todos os anos revisamos a lista para decidir quais remover e quais adicionar.
Para 2020, consolidamos vários serviços de aplicativos em categorias mais abrangentes. Por exemplo, firewall de rede, antispam, IPS/IDS e mitigação de spam foram agrupados como "serviços comuns de segurança". Decidimos adotar essa abordagem por dois motivos. Primeiro, porque seis anos de dados indicaram grupos de serviços de aplicativos com taxas de implantação muito semelhantes. Segundo, porque queríamos abrir espaço para serviços de aplicativos emergentes e não sobrecarregar nossa já muito paciente base de respondentes.
Esses serviços de aplicativos emergentes são quase exclusivamente serviços de aplicativos nativos de contêineres. Em geral — embora nem sempre —, eles são implantados como parte do ambiente operacional necessário para disponibilizar uma aplicação nativa da nuvem. Alguns exemplos são controle de entrada, descoberta de serviços e malha de serviços. Os gateways de API também costumam estar estreitamente vinculados a aplicações nativas da nuvem, embora seu uso seja amplamente compatível com qualquer aplicação baseada em API.
Dada a importância cada vez maior desses serviços para a entrega de aplicativos modernos e nativos da nuvem, bem como as incríveis taxas de implantação que estamos observando, este parece ser um bom momento para explicar melhor esses expoentes das abordagens nativas da nuvem.
Controle de entrada
Implantação do State of Application Services 2020: controle de entrada
| Implantado atualmente | Planejado para 2020 |
Local | 45% | 27% |
Nuvem pública | 51% | 32% |
Controle de ingresso é um conceito introduzido no universo do Kubernetes para segmentar e direcionar requisições HTTP. Ele permite que os operadores mapeiem facilmente um URI para um serviço específico do Kubernetes. Isso possibilita o roteamento das requisições de entrada (ingress) para a instância correta do microsserviço.
Esse não era um conceito novo. Os leitores assíduos devem se lembrar de que costumo exaltar as vantagens do roteamento HTTP (camada 7), especialmente como um componente arquitetural projetado para viabilizar estratégias de escalabilidade mais eficientes. Se você não se lembra ou acabou de chegar, esta palestra é uma boa forma de recapitular: Então você acha que consegue escalar?
A novidade está na forma como os "mapas" são gerenciados. Os controladores de entrada precisam ser atualizados dinamicamente com base nas condições atuais dentro de um cluster de contêineres. Isso significa que um controlador de entrada precisa ter visibilidade do estado atual de um cluster. Isso requer integração com os componentes apropriados do Kubernetes por meio de sua API operacional.
Essa integração é o que vincula o controle de ingresso ao ambiente e, assim, o incorpora à arquitetura da aplicação. Um controlador de ingresso totalmente funcional é inerentemente "nativo de contêineres", pois faz parte da infraestrutura necessária para dimensionar e operar uma aplicação nativa da nuvem.
Descoberta de serviços
Estado da implantação de serviços de aplicações em 2020: descoberta de serviços
| Implantado atualmente | Planejado para 2020 |
Local | 14% | 24% |
Nuvem pública | 21% | 34% |
Um fato interessante sobre aplicações nativas da nuvem é a vida útil de seus componentes. A natureza dinâmica da escalabilidade dentro de um cluster de contêineres significa necessariamente que os "contêineres" estão em constante mudança. Os dados mais recentes da Sysdig mostram um aumento nessa rotatividade, com 39% dos contêineres tendo uma vida útil inferior a um minuto e 54% inferior a 5 minutos.
O problema é que outros componentes precisam ser capazes de localizar esses contêineres.
Essa é a razão de ser do componente de descoberta de serviços. Esses componentes são executados dentro do cluster de contêineres e funcionam como a "fonte oficial" dos serviços. As partes interessadas podem consultar esse componente para descobrir como se conectar e se comunicar com determinado serviço. Ao monitorar os serviços em tempo real, o componente de descoberta de serviços lida com a volatilidade de um cluster e permite que outros componentes — como o controle de entrada — funcionem corretamente.
Malha de serviços
Relatório State of Application Services 2020 — Implantação: Service Mesh
| Implantado atualmente | Planejado para 2020 |
Local | 14% | 25% |
Nuvem pública | 19% | 37% |
A malha de serviços é provavelmente a mais controversa entre os serviços de aplicativos nativos de contêineres. Não por seu valor conceitual, mas devido às preferências de implementação. As malhas de serviços são projetadas para solucionar problemas de visibilidade, escalabilidade e segurança em clusters de contêineres. Elas são implementadas como proxies hiperconectados — seja como sidecars ou por aplicativo — e oferecem diversos recursos tanto para desenvolvedores quanto para operadores.
Uma malha de serviços não é um serviço de aplicação que você encontrará fora de um cluster de contêineres. Assim como a descoberta e o controle de entrada, uma malha de serviços é totalmente integrada ao ambiente de contêineres. Isso também a torna um serviço de aplicação nativo de contêineres.
Serviços de aplicativos nativos de contêineres
Nós (o setor e o “Nós” corporativo) nunca categorizamos os serviços de aplicativos dessa forma. É claro que os categorizamos com base em seu uso principal: segurança, disponibilidade, desempenho, mobilidade e identidade. Mas essas são categorias de uso amplas, e nenhuma delas é específica de uma arquitetura de aplicativos.
No entanto, a integração com uma arquitetura nativa da nuvem e as dependências em relação a ela podem tornar necessário fazer essa categorização para esses serviços de aplicativos (e quaisquer outros que possam surgir no futuro). Isso porque o crescimento de um deles (o serviço de aplicativo) indica claramente o crescimento do outro (a arquitetura do aplicativo) — e vice-versa. Trata-se de uma situação única, na qual os serviços de aplicativos e os próprios aplicativos estão tão intimamente interligados que ambos apresentarão taxas de implantação muito semelhantes.
Da mesma forma que distinguimos entre aplicativos móveis para iOS e Android, pode ser útil classificar como "nativos de contêiner" os serviços de aplicativos projetados para operar exclusivamente em ambientes conteinerizados, diferenciando-os daqueles que operam em qualquer outro ambiente.
Independentemente de como os categorizemos, eles estão definitivamente em ascensão — assim como os aplicativos que dependem deles.
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...