Um número crescente de serviços de aplicativos é um componente integral de uma arquitetura nativa da nuvem. É, em parte, por isso que vemos uma mudança na responsabilidade pelos serviços de aplicativos, das operações de TI para o DevOps.
Monitoramos mais de 30 serviços de aplicativos diferentes em nossa pesquisa State of App Services . Há mais, e todo ano revisamos a lista para determinar o que eliminar e o que adicionar.
Em 2020, consolidamos vários serviços de aplicativos em categorias mais amplas. Por exemplo, firewall de rede, antispam, IPS/IDS e mitigação de spam foram agregados em "serviços de segurança comuns". Decidimos por essa abordagem por dois motivos. Primeiro, porque seis anos de dados indicaram agrupamentos 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 queríamos sobrecarregar nossa base de entrevistados, que já é muito paciente.
Esses serviços de aplicativos emergentes são quase exclusivamente serviços de aplicativos nativos de contêiner. Eles geralmente são — embora nem sempre — implantados como parte do ambiente operacional necessário para entregar um aplicativo nativo da nuvem. Pense em controle de entrada, descoberta de serviço e malha de serviço. Os gateways de API também costumam ser intimamente acoplados a aplicativos nativos da nuvem, embora seu uso esteja amplamente alinhado com qualquer aplicativo baseado em API.
Dada a crescente importância deles para o fornecimento de aplicativos modernos e nativos da nuvem e as incríveis taxas de implantação que estamos observando, parece um bom momento para dar uma olhada nesses campeões das abordagens nativas da nuvem.
Estado da implantação dos serviços de aplicativos em 2020: Controle de entrada
|
Implantado hoje |
Planejado para 2020 |
No local |
45% |
27% |
Nuvem pública |
51% |
32% |
O controle de entrada é um conceito introduzido no mundo do Kubernetes para segmentar e analisar solicitações HTTP. Ele permite que os operadores mapeiem facilmente um URI para um serviço específico do Kubernetes. Isso permite o roteamento de solicitações de entrada (ingresso) para a instância correta do microsserviço.
Este não era um conceito novo. Leitores ávidos se lembrarão de que costumo enaltecer as virtudes do roteamento HTTP (Camada 7), particularmente como um componente arquitetônico projetado para auxiliar em estratégias de dimensionamento mais eficientes. Se você não se lembra ou está se juntando a nós agora, esta palestra é uma boa atualização: Então você acha que consegue escalar?
A novidade é a 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 significa integração com os componentes apropriados do Kubernetes por meio de sua API operacional.
Essa integração é o que vincula o controle de entrada ao ambiente e, portanto, o incorpora à arquitetura do aplicativo. Um controlador de entrada totalmente funcional é inerentemente "nativo de contêiner" porque faz parte da infraestrutura necessária para dimensionar e operar um aplicativo nativo da nuvem.
Estado da implantação dos serviços de aplicativos em 2020: Descoberta de serviços
|
Implantado hoje |
Planejado para 2020 |
No local |
14% |
24% |
Nuvem pública |
21% |
34% |
Um fato interessante sobre aplicativos nativos da nuvem é a vida útil de suas partes componentes. A natureza dinâmica da escalabilidade dentro de um cluster de contêineres significa necessariamente que os "contêineres" estão em fluxo constante. Os dados mais recentes da Sysdig mostram quantidades crescentes de fluxo, com 39% dos contêineres vivendo menos de um minuto e 54% vivendo menos de 5 minutos.
O problema com isso é que outros componentes precisam ser capazes de encontrar esses contêineres.
Esta é a razão de ser do componente de descoberta de serviço . Esses componentes são executados dentro do cluster de contêineres e servem como "fonte autorizada" para serviços. As partes interessadas podem consultar este componente para descobrir como se conectar e se comunicar com um determinado serviço. Ao monitorar os serviços em tempo real, o componente de descoberta de serviços aborda a volatilidade de um cluster e permite que outros componentes, como o controle de entrada, funcionem corretamente.
Estado da implantação dos serviços de aplicativos em 2020: MALHA DE SERVIÇOS
|
Implantado hoje |
Planejado para 2020 |
No local |
14% |
25% |
Nuvem pública |
19% |
37% |
O Service Mesh é provavelmente o mais controverso dos serviços de aplicativos nativos de contêiner. Não por causa de seu valor conceitual, mas por causa de preferências de implementação. As malhas de serviço são projetadas para resolver problemas de visibilidade, escala e segurança em clusters de contêineres. Eles são implementados como proxies hiperconectados — sidecar ou por aplicativo — e oferecem uma variedade de recursos para desenvolvedores e operadores.
Uma malha de serviço não é um serviço de aplicativo que você encontrará fora de um cluster de contêineres. Assim como a descoberta e o controle de entrada, uma malha de serviço é intimamente integrada ao ambiente do contêiner. Isso também o torna um serviço de aplicativo nativo de contêiner.
Nós (a indústria e o nós corporativo) nunca categorizamos serviços de aplicativos dessa maneira antes. Certamente, categorizamos com base em seu uso principal: segurança, disponibilidade, desempenho, mobilidade e identidade. Mas essas são categorias de uso amplas e nenhuma é específica de uma arquitetura de aplicativo.
Mas a integração e as dependências de uma arquitetura nativa da nuvem podem tornar necessário fazer isso para esses serviços de aplicativos (e quaisquer outros que possam surgir no futuro). Isso ocorre porque o crescimento de um (o serviço de aplicativo) indica claramente o crescimento do outro (a arquitetura do aplicativo) — e vice-versa. Esta é uma situação única, na qual os serviços de aplicativos e os aplicativos estão tão intimamente interligados que os dois terão taxas de implantação muito semelhantes.
Da mesma forma que distinguimos entre aplicativos móveis iOS e Android, podemos achar valioso marcar aqueles serviços de aplicativos projetados para operar apenas em um ambiente de contêiner como "nativos de contêiner" em vez daqueles que operam em qualquer outro lugar.
Independentemente de como os categorizamos, eles estão definitivamente em ascensão, junto com os aplicativos que dependem deles.