Kubernetes a aceitação está crescendo e continuará a crescer. Seu desenvolvimento contínuo é impulsionado pela ampla adoção: mais empresas, equipes e indivíduos o adotarão como uma plataforma para inovação, criando novos aplicativos e dimensionando os existentes mais rapidamente do que nunca.
O mais recente Pesquisa anual da Cloud Native Computing Foundation (CNCF) suporta a afirmação de que o Kubernetes está crescendo e O estado do Kubernetes 2022 relatório da VMware Tanzu também confirma a adoção. Gartner e Forrester confirmam o crescimento e a ampla adoção do Kubernetes. Não há necessidade de prever que a adoção do Kubernetes continuará a explodir!
No entanto, se descompactarmos essa rápida adoção, o que mais sabemos sobre a aceitação generalizada do Kubernetes? O que os líderes precisam prestar atenção para que o ecossistema do Kubernetes floresça em sua organização? Há cinco coisas a serem observadas se o Kubernetes for importante para sua organização de TI:
- A criação de equipes distintas de DevOps e plataformas, já que as áreas de conhecimento estão se tornando tão amplas. O Kubernetes adiciona complexidade adicional e precisa de habilidades específicas entre as equipes.
- As empresas encontrarão melhores maneiras de distribuir engenharia de confiabilidade do site (SRE) entre as equipes.
- A política como código para Kubernetes amadurecerá e ganhará força.
- A luta em torno da solução de problemas do Kubernetes será parcialmente resolvida.
- SLIs e SLOs serão adotados por mais equipes e orientarão as decisões de investimento.
Criação de DevOps e equipes de plataforma
Ultimamente, tem havido artigos e tweets proclamando que DevOps está morto. Discordo totalmente: a estreita colaboração entre várias disciplinas continua crítica e o foco na automação e na aceleração é vital para sobreviver nesta era digital.
No entanto, as empresas lutam para trazer outra grande área de conhecimento para a equipe. Depois de CI/CD, shift left testing, monitoramento, observabilidade e segurança, as equipes lutam para obter amplo conhecimento sobre o Kubernetes e outras plataformas de nuvem. Essas tecnologias oferecem enormes vantagens comerciais e financeiras em potencial, mas são ambientes complicados de aprender e manter.
Empresas de todos os tamanhos devem considerar onde desejam construir uma base de conhecimento sobre o Kubernetes. Muitas empresas escolhem uma equipe de plataforma para construir e configurar esse conhecimento. Uma única equipe de plataforma pode oferecer suporte a várias equipes de DevOps. Com essa segregação, as equipes de DevOps continuam a se concentrar no desenvolvimento e na operação dos aplicativos (comerciais), enquanto a equipe de plataforma cuida de uma plataforma subjacente robusta e confiável. O DevOps não está morto, mas os líderes devem considerar qual nível de responsabilidade e suporte de tecnologia é realista colocar em cada equipe.
Melhores maneiras de distribuir conhecimento de SRE
Se você for um especialista em Kubernetes em uma equipe SRE, talvez não entenda esse desafio. No entanto, muitas equipes não têm experiência em engenharia de confiabilidade de site para otimizar o uso do Kubernetes. Muitas equipes lutam com esse problema. Mas com cada vez mais empresas se esforçando para ampliar o compartilhamento de conhecimento, novos modelos começam a surgir. Em 2023, mais empresas desenvolverão as melhores práticas sobre como disseminar o conhecimento internamente.
A necessidade de um cenário mais confiável, aplicativos com melhor desempenho e um processo sem muito desperdício impulsionará o crescimento de uma cultura de compartilhamento de conhecimento.
Uma equipe SRE central pode ser adequada se você tiver equipes de engenharia maduras que estejam familiarizadas com o Kubernetes e outras tecnologias de nuvem. Se essas equipes de engenharia precisarem apenas de orientação e direção ocasionais ou talvez algum suporte na seleção de ferramentas, esse modelo pode se adequar à sua organização.
Um treinador/esquadrão é um modelo perfeito se suas equipes são novas no uso do Kubernetes. Um grupo de especialistas pode ir de uma equipe para outra e ajudar a aumentar a implementação da prática, bem como compartilhar conhecimento. Priorize trabalhar primeiro com suas equipes mais críticas; ajude-os por algumas semanas ou meses e depois passe para a próxima equipe.
A distribuição local de conhecimento SRE em cada equipe de DevOps é obviamente o modelo mais forte. Habilitar isso pode levar tempo, mas ter conhecimento de confiabilidade do site em equipes que usam o Kubernetes é o modelo ideal.
Política como código para Kubernetes amadurecerá e ganhará força
Por vários anos, o foco tem sido permitir que as equipes se tornem mais autônomas na implantação de aplicativos no Kubernetes. O desenvolvimento de pipelines que podem enviar aplicativos facilmente agora é uma prática comum em muitas empresas.
Embora a autonomia seja uma grande vantagem, encontrar o equilíbrio certo no que diz respeito à manutenção de algum controle manual continua sendo um desafio. Com a mudança para o as-code, um mundo inteiro de possibilidades está se abrindo. As políticas definidas como código podem ser facilmente validadas e revisadas seguindo as práticas de engenharia estabelecidas. Portanto, as estruturas políticas se tornarão mais importantes. Dentro do CNCF, Open Policy Agent (OPA) é a estrutura de política mais comum. Agente de Política Aberta descreve-se da seguinte forma:
“A OPA fornece uma linguagem declarativa de alto nível que permite especificar políticas como código e APIs simples para descarregar a tomada de decisões sobre políticas de seu software. Você pode usar o OPA para impor políticas em microsserviços, Kubernetes, pipelines de CI/CD, gateways de API e muito mais.”
Para continuar a adoção de Kubernetes e equipes autônomas, práticas como essa amadurecerão em paralelo para permitir o crescimento contínuo, mantendo ou mesmo ganhando controle adicional. A adoção permite que você controle como o Kubernetes é usado por uma ampla variedade de equipes.
Solução de problemas do Kubernetes
Solucionar problemas de aplicativos em execução em um cluster Kubernetes em escala pode ser problemático não apenas porque o próprio Kubernetes é complexo, mas também devido às conexões entre tantas partes móveis. Ter conhecimento de todos eles continua sendo um problema. Fornecer soluções de solução de problemas que ajudem as equipes a remediar os problemas de forma eficaz proporcionará uma vantagem competitiva.
Para obter a imagem completa, quatro elementos precisam ser reunidos. Todos os quatro são necessários para entender completamente o que está errado, remediar o problema e analisar o que o causou para evitá-lo no futuro.
- Eventos—Várias soluções de solução de problemas são orientadas a eventos; eles mostram cada mudança que aconteceu. Por meio desses dados, eles podem indicar onde está um problema e o que o causou.
- Histórico—Muitas equipes usarão análises de log para detectar avisos e problemas contínuos e, em seguida, tentar determinar o que deu errado. Os logs fornecem ótimas informações, mas podem ser difíceis de filtrar.
- dados de telemetria—Com um influxo de métricas e padrões como o OpenTelemetry crescendo em adoção, os dados de telemetria são essenciais para solucionar problemas do Kubernetes. Detectar a degradação do desempenho de serviços, memória ou discos que atingem seus limites é útil para resolver esses problemas.
- Dados de rastreamento— Reunidos por meio, por exemplo, do eBPF, os dados de rastreamento são poderosos para ajudá-lo a obter informações sobre sinais de ouro, como taxa de erro, taxa de transferência e tráfego.
As soluções que reúnem esses quatro elementos o ajudarão a determinar mais rapidamente o que está errado e, assim, como remediar. Fornecedores e estruturas de código aberto continuarão a impulsionar essa tendência.
SLIs e SLOs serão adotados e orientarão as decisões de investimento
Por muitos anos, indicadores de nível de serviço (SLIs) e objetivos de nível de serviço (SLOs) foram usados para medir e rastrear como as organizações estão progredindo em relação às metas definidas. Por muitos anos, definir SLIs e SLOs foi um exercício focado em TI sem muita visibilidade para a linha de negócios.
A conexão entre SLIs, SLOs e acordos de nível de serviço (SLAs) torna-se mais relevante e será estabelecida com o auxílio de ferramentas que, enfim, conectam negócios e TI.
Mais importante, definir SLIs e SLOs não será apenas uma unidade de medida, mas iniciará conversas sobre investimento de recursos, incluindo perguntas como: “Quais serviços e áreas em meu ambiente Kubernetes estão ficando para trás e não estão atendendo a seus SLOs?” Essas são as áreas que exigirão investimentos adicionais. “Quais são as áreas que funcionam muito bem e exigem menos investimento? O que requer o mesmo nível de investimento, mas mais experimentação?”
Em 2023, equipes e líderes estarão mais cientes dos dados que estão ocultos nesses SLOs e os transformarão em insights valiosos para orientar as decisões de investimento.
Conclusão
O Kubernetes e o ecossistema ao seu redor estão em um momento interessante de crescimento em direção à maturidade. Com a adoção contínua, ou mesmo acelerada, do Kubernetes, as empresas e, principalmente, os líderes de engenharia, precisam começar a desenvolver um olhar mais amplo para o conhecimento dentro de suas equipes, ferramentas para facilitar o crescimento e formas diferenciadas de solucionar problemas. Caso contrário, a adoção do Kubernetes pode diminuir, os resultados podem ser abaixo do ideal, os engenheiros podem sair ou as regras de conformidade podem ser violadas. Isso por si só já é um desafio, mas, mais importante, afetará as metas de negócios, a estabilidade pode ser comprometida e os clientes podem ter um engajamento ruim por meio de seus canais digitais.
Relacionado