Impeça a expansão das operações com um plano de dados unificado

Quando a atualização de um elemento crítico da infraestrutura para equipes de aplicativos leva semanas devido à coordenação entre NetOps, SecOps, PlatformOps e FinOps, você tem um problema: expansão de operações.

Primeiro foi a equipe de operações de tecnologia. Depois vieram as operações de rede e as operações de segurança. Então, decorrente do movimento de engenharia de confiabilidade de sites (SRE) e do objetivo de empurrar mais decisões operacionais para o ambiente de desenvolvimento, veio o DevOps. Para não desanimar, isso deu lugar ao DevSecOps com foco na segurança. À medida que o nativo da nuvem chegou, o PlatformOps passou a selecionar e implantar cadeias de ferramentas para uma mudança adequada para a esquerda.

Agora existe até uma disciplina que une PlatformOps com operações financeiras – logicamente, é chamada FinOps, e trata-se de dar sentido aos custos caóticos da computação em nuvem. O resultado final desta explosão de operações é, naturalmente, uma “expansão de operações” que leva ao “rastreamento de operações” – equipes fragmentadas com seus próprios painéis e conhecimento tribal, o que cria gargalos.

O plano de dados como antídoto para a expansão operacional

Existe um único thread que une tudo isso: o plano de dados. Tanto na Camada 4 quanto na Camada 7, o plano de dados é o carro-chefe que faz o trabalho pesado. Ele recebe instruções do plano de controle e move os dados. Ele encaminha pacotes, aplica regras de segurança e executa tarefas como balanceamento de carga. Para usar o enquadramento biológico, o plano de dados é o sangue e os músculos das aplicações e redes modernas. O plano de controle é o sistema nervoso. E, tal como o cérebro humano, o plano de controlo pode ter múltiplos módulos para funcionalidades específicas.

Garantir que todas as funções operacionais sejam cidadãos de primeira classe no plano de dados é a chave para quebrar os silos entre as equipes operacionais e aliviar o flagelo da expansão operacional. O desafio? A maioria das organizações não implantou um plano de dados unificado e permanece inconsciente do conceito. À medida que avançamos em direção a um mundo onde a maioria das aplicações é composta por APIs, e mesmo as aplicações monolíticas precisam ser capazes de se comunicar com outros sistemas, o conceito de um plano de dados unificado torna-se cada vez mais relevante.

O plano de dados surgiu originalmente de construções de rede como resposta à teoria da “separação de interesses”. Este princípio fundamental de design envolve dividir um sistema complexo em seções menores e distintas, onde cada seção se concentra em um aspecto ou “preocupação” específico da funcionalidade do programa. Nas redes, as operadoras queriam separar a funcionalidade em um plano de dados, onde os dados eram transmitidos e as regras que governavam a movimentação de dados eram aplicadas, e um “plano de controle” que gerenciava o plano de dados e as políticas relacionadas.

A teoria foi posteriormente aplicada ao software por meio de conceitos como model-view-controller. Nas redes, a separação de interesses foi devidamente copiada de roteadores centrais maiores e sistemas de backhaul para sistemas menores, como controladores de entrega de aplicativos e proxies reversos. Mesmo que mais e mais elementos das pilhas de tecnologia seguissem esta convenção, diferentes funções tendiam a manter seus planos de dados isolados, seja como uma separação física ou de fato com ferramentas incompatíveis ou desconectadas. E então veio o Kubernetes.

Lições da API Kubernetes Gateway

O Kubernetes foi projetado para priorizar a API e ser fracamente acoplado, mapeando para arquiteturas nativas da nuvem. Mais recentemente, a API Kubernetes Gateway separa de forma mais clara os dados e os planos de controle. Ele dá funções claras às diferentes equipes (quem lida com a infraestrutura básica, quem gerencia o cluster, quem desenvolve aplicativos), permite definir configurações de rede com mais detalhes e facilita a adição de novos recursos.

Isso significa que as equipes podem trabalhar melhor juntas, você tem mais controle sobre como o tráfego de rede flui sem que as coisas fiquem muito confusas e é mais fácil conectar ferramentas de rede especializadas quando você precisar delas. Na verdade, a nova API Gateway provavelmente se tornará o plano de dados para todas as equipes operacionais e a estrutura conjuntiva crítica que não apenas melhora a segurança e a escalabilidade, mas também permite implantações mais rápidas, iterações de plataforma mais fáceis e melhores controles de custos.

Cinco princípios para reduzir a dispersão de operações com um plano de dados unificado

Nem todas as organizações apostarão tudo no Kubernetes, nem deveriam. Dito isso, é possível extrair princípios arquitetônicos da API do Gateway para traçar um plano para colocar todas as equipes de operações na mesma página do plano de dados e cortar o nó górdio da expansão de operações.

Princípio 1: Padronização por meio de APIs

A API Gateway, com foco em definições de objetos padronizados, abre caminho para uma integração perfeita. Um plano de dados unificado deve adotar padrões semelhantes, permitindo a comunicação de ferramentas diferentes e, em última análise, reduzindo a dependência de soluções personalizadas que aumentam os silos. As APIs devem pelo menos ser capazes de se comunicar. Idealmente, uma única estrutura de API para gerenciar dados operacionais deveria ser projetada e implantada.

Princípio 2: Visibilidade como Unificadora

Um plano de dados centralizado deve oferecer visibilidade total do tráfego de rede, desempenho e latência de aplicativos, uso de recursos e tipos de contêiner e métricas de segurança. Para remediar verdadeiramente a expansão das operações, os custos (de infraestrutura e largura de banda) também devem ser visíveis para ajudar as equipas a compreender o impacto das suas escolhas de design. Cada equipe de operações se beneficia de uma compreensão compartilhada e em tempo real da integridade do sistema, eliminando o conhecimento tribal e promovendo a resolução proativa de problemas.

Princípio 3: Empoderamento por meio da abstração

O plano de dados deve apresentar o nível certo de abstração para cada função operacional. Os engenheiros de rede precisam de controle refinado da Camada 4 com alguns insights sobre a Camada 7 para entrega de aplicativos e fins de segurança. As equipes de FinOps precisarão de uma visão de quanto está sendo gasto em cada provedor de nuvem e dos gastos projetados. Permita que eles mergulhem conforme necessário, mas projete para uma abstração confortável.

Princípio 4: Configuração Orientada por Políticas

O estabelecimento de um plano de dados unificado oferece a oportunidade de abandonar a configuração manual e propensa a erros. Em vez disso, adote uma abordagem declarativa e baseada em políticas aplicável em NetOps, SecOps, PlatformOps, FinOps e outros. Isso promove consistência e facilita o gerenciamento de mudanças. Também permite gerir por excepção e não por repetição.

Princípio 5: Observabilidade como base

Os verdadeiros insights vêm de mais do que apenas visibilidade. Projete seu plano de dados unificado tendo em mente a observabilidade abrangente: logs estruturados, métricas e rastreamento que abrangem todas as funções operacionais. Com esse recurso, as equipes de operações podem identificar rapidamente problemas, identificar gargalos e otimizar o desempenho geral.

A expansão das operações cria um obstáculo à inovação e à eficiência. Um plano de dados unificado construído com base nos princípios inspirados na API Kubernetes Gateway oferece um caminho para quebrar silos. Isso permite que as equipes de operações colaborem perfeitamente, levando a uma entrega mais rápida e a uma melhor saúde operacional para sua organização.

A postagem Impedir a expansão das operações com um plano de dados unificado apareceu pela primeira vez em The New Stack.