Controle versus execução no caminho de dados

Antigamente, os serviços de aplicativos que entregavam aplicativos formavam um caminho de dados estreito e direto. Todos os aplicativos basicamente percorreram o mesmo conjunto de serviços pela mesma rede. Essa simplicidade arquitetônica facilitou a combinação de um único ponto de controle com um único ponto de execução. Isso, por sua vez, levou ao surgimento do controlador de entrega de aplicativos (ADC). Por meio dele, o tráfego de aplicativos pode ser moldado, direcionado, dimensionado e protegido, tudo em um só lugar. Controle e execução combinados para fornecer às operações um ponto estratégico no caminho de dados no qual todos os tipos de políticas podem ser aplicadas e executadas.

A ascensão da nuvem e a adoção contínua de contêineres interromperam esse caminho de dados. Agora temos vários caminhos de dados, às vezes dinâmicos, pelos quais os aplicativos são entregues. Um único ponto estratégico de controle e execução muitas vezes não é mais viável operacionalmente — ou arquitetonicamente.

Mas isso não significa que um ponto de controle unificado não seja mais possível, mesmo quando a execução é delegada a um conjunto distinto de serviços de aplicativos.

É importante ter o mínimo possível de pontos de controle por meio dos quais os serviços de aplicativo no caminho de dados podem ser operados (implantados, configurados e gerenciados). Incentivar o uso de múltiplos pontos de controle inevitavelmente resulta em políticas conflitantes que causam problemas para os consumidores de aplicativos. A solução de problemas se torna mais complexa e demorada, o que aumenta a ira e a angústia dos usuários. Infelizmente, a proliferação de ferramentas é uma reclamação comum entre aqueles que gerenciam a adição de arquiteturas nativas da nuvem a um portfólio de aplicativos já diversificado .

Sabemos, pela nossa pesquisa State of App Services de 2020, que as operações são as principais responsáveis pela operação dos serviços de aplicativos, mas elas não estão sozinhas. DevOps, NetOps e SecOps são todos investidos na operação de serviços de aplicativos tanto no local quanto na nuvem pública. 

O que geralmente os separa são as funções específicas dos serviços de aplicativos pelos quais eles são responsáveis.

O DevOps é amplamente responsável pela confiabilidade, pelo desempenho e pelas políticas específicas do aplicativo. NetOps, por outro lado, são, a propósito de seu apelido, mais focados em atributos de rede. É o NetOps que geralmente mantém os serviços de aplicativos de uma perspectiva de infraestrutura. O SecOps, é claro, se preocupa com a segurança no que se refere à infraestrutura e ao aplicativo.

Mas só porque pode haver uma divisão de tarefas não significa que deva haver ferramentas separadas com as quais eles praticam suas artes. Hoje, há ampla evidência de que os pipelines de CI/CD e implantação contínua são construídos em conjuntos de ferramentas distintos. Jenkins e repositórios git dominam o pipeline de CI/CD, enquanto Ansible e Python são as ferramentas preferidas no lado da implantação contínua. Grande parte da decisão está em adequar o conjunto de ferramentas às formas de trabalho dos vários constituintes que devem interagir com as ferramentas diariamente.

Portanto, caso surja uma única ferramenta para melhorar a consistência das políticas, acelerar a solução de problemas e eliminar a complexidade e o custo da proliferação de ferramentas, ela deve ter as interfaces certas para garantir que todos os principais constituintes dos serviços de aplicativo no caminho de dados sejam capazes de aproveitar o conjunto de ferramentas para executar suas respectivas tarefas.

Isso é importante para a segurança geral e a confiabilidade dos serviços do aplicativo. Ao manter um ponto de controle unificado, as organizações podem ter certeza de que as mudanças serão rastreadas e compreendidas. Embora não seja uma implementação imutável, ela dá vários passos em direção a essa prática ao centralizar o controle em uma única ferramenta. 

Um exemplo de tal ferramenta é o NGINX Controller .  

Você notará que, conforme previsto, uma variedade de serviços de aplicativos (análise, gerenciamento de API, segurança e malha de serviços) podem ser controlados centralmente, mesmo que a operação e a execução sejam distribuídas.

Em qualquer ambiente, é importante reduzir o número de ferramentas permitidas para interagir com componentes do caminho de dados (serviços de aplicativo) para mitigar possíveis problemas com configurações incorretas ou conflitantes. Em um ambiente moderno e multinuvem, é ainda mais crítico centralizar o controle devido à complexidade gerada pelo crescimento frequentemente exponencial de serviços de aplicativos que compõem o caminho de dados. 

Mais atraente para aqueles que possuem os orçamentos é a redução de despesas operacionais associadas à eliminação de atividades manuais repetitivas com automação.

Unificar o controle em uma única ferramenta é uma maneira de fazer isso.