Kubernetes nem sempre é a escolha certa

Hoje em dia, você pode encapsular praticamente qualquer aplicativo em um contêiner para execução. Os contêineres resolvem muitos problemas, mas apresentam um novo desafio de orquestração. Devido à crescente necessidade de orquestração de contêineres por parte de um grande número de equipes que trabalham para construir aplicativos nativos da nuvem, o Kubernetes ganhou popularidade significativa como uma ferramenta poderosa para resolver esse desafio.

Construir em um ambiente Kubernetes bem gerenciado oferece vários benefícios, como escalonamento automático, autocorreção, descoberta de serviço e balanceamento de carga. No entanto, abraçar o mundo do Kubernetes muitas vezes implica mais do que apenas adotar a tecnologia de orquestração de contêineres. As equipes precisam considerar estrategicamente: “O Kubernetes é a escolha certa para minha solução?” E devem fazê-lo avaliando vários componentes desta questão mais ampla.

A composição da minha equipe é adequada para Kubernetes?

Não faltam artigos elogiando as capacidades do Kubernetes (K8s), e não é isso que pretendemos contestar. K8s é a escolha certa em muitos casos. Dito isto, a interação direta e a manutenção dos K8s não são apropriadas para todas as equipes e projetos.

1. Pequenas startups com aplicativos nativos da nuvem: Essas equipes considerarão o gerenciamento direto do Kubernetes uma distração complexa e demorada de seu objetivo de lançar e dimensionar um produto. Dado o seu tamanho, as equipes não terão largura de banda para gerenciar clusters Kubernetes enquanto desenvolvem seu aplicativo.
2. Equipes empresariais com uma variedade de tipos de aplicativos: Para equipes maiores com habilidades especializadas, o Kubernetes é uma excelente escolha. No entanto, tempos de execução de contêineres totalmente gerenciados ou Kubernetes como ofertas de serviços ainda devem ser considerados. Esses serviços permitem que recursos limitados de DevOps se concentrem na produtividade da equipe, no autoatendimento do desenvolvedor, no gerenciamento de custos e em outros itens críticos.
3. Empresas de médio porte com cultura DevOps: Embora essas equipes estejam mais preparadas para a mudança para o Kubernetes, é um projeto importante que irá atrapalhar os fluxos de trabalho existentes. Novamente, as ofertas gerenciadas revelam muitos benefícios do Kubernetes sem investimento significativo.
4. Consultorias de software: Embora essas equipes sejam adaptáveis, contar com o Kubernetes pode limitar sua capacidade de atender clientes com necessidades diferentes, pois leva a consultoria a recomendá-lo mesmo quando não é o mais adequado.

Quão complexo é meu projeto? O K8s é um exagero?

Em vez de determinar se o K8s atende a alguns de seus requisitos, considere identificar características e requisitos específicos que não se alinham bem com os recursos do Kubernetes ou que introduzem complexidade desnecessária.

1. Necessidades mínimas de escalabilidade: Se o projeto tiver tráfego consistentemente baixo ou demandas de recursos previsíveis e constantes, sem requisitos de escalabilidade significativos, o Kubernetes introduzirá sobrecarga desnecessária. Nesses casos, tempos de execução de contêineres gerenciados ou soluções de servidor virtual privado (VPS) normalmente representam um valor melhor.
2. Aplicações monolíticas simples: Se o projeto for um aplicativo monolítico com dependências limitadas e não exigir serviços escalonáveis ​​de forma independente ou contagens de instâncias extremamente altas, o Kubernetes será muito complexo para suas necessidades.
3. Infraestrutura estática ou limitada: Se o projeto tiver infraestrutura pequena ou estática sem muita variação no uso de recursos, opções de implantação mais simples, como serviços gerenciados ou VPS, serão suficientes.
4. Recursos limitados de DevOps: O Kubernetes requer experiência em orquestração de contêineres, o que não é viável para projetos com recursos limitados de DevOps ou se a equipe não estiver disposta a investir no aprendizado do Kubernetes. Os benefícios dos contentores ainda podem ser alcançados sem este investimento adicional.
5. Prototipagem e projetos de curto prazo: Para projetos com ciclos de vida de desenvolvimento curtos ou durações de produção limitadas, a sobrecarga do Kubernetes não pode ser justificada.
6. Restrições de custo do projeto: Se o projeto tiver restrições orçamentárias rigorosas, o custo adicional de criação e manutenção de um cluster Kubernetes não será viável. Isto é particularmente verdadeiro quando se considera o custo dos membros da equipe altamente qualificados necessários para realizar este trabalho.
7. Requisitos de infraestrutura: Kubernetes pode consumir muitos recursos, exigindo uma infraestrutura robusta para funcionar de maneira eficaz. Se seus projetos forem de pequeno ou médio porte e com requisitos de recursos modestos, usar serviços gerenciados ou sem servidor é muito mais apropriado.

A complexidade dos seus requisitos por si só não determinará se o Kubernetes é perfeito ou excessivo para a sua equipe; no entanto, pode ajudá-lo a inclinar-se para um lado ou para outro. Se você estiver usando o Kubernetes diretamente, isso não elevará inerentemente seu produto. Em vez disso, a sua força reside na criação de uma plataforma resiliente na qual o seu produto possa prosperar.

Imagem 1

As consequências são que os esforços de desenvolvimento do seu produto deixarão de ser a base do seu negócio, à medida que você se compromete a colocar o seu próprio trabalho por baixo dele.

Isto revela a verdadeira questão: estamos a construir uma plataforma ou estamos a tentar acelerar o nosso tempo de colocação no mercado com um retorno do investimento mais imediato para os nossos principais objetivos de negócio?

Temos o conjunto de habilidades necessárias?

O Kubernetes é frequentemente reconhecido por sua desafiadora jornada de aprendizado. O que contribui para esta complexidade? Para oferecer clareza, organizei uma lista de tópicos com base em critérios específicos que ajudam a avaliar o esforço necessário para melhorar as habilidades de alguém.

Observação: esses níveis de complexidade variam de acordo com a formação individual e a experiência anterior.

Para equipes que não possuem o conhecimento necessário ou o tempo para aprender, o processo geral de desenvolvimento e implantação pode se tornar complicado e lento, o que não será saudável para projetos com prazos apertados ou equipes pequenas.

Quais são as implicações de custo?

Embora o Kubernetes em si seja de código aberto e gratuito, executá-lo não é. Você precisará contabilizar as despesas associadas à infraestrutura, incluindo o custo de servidores, armazenamento e rede, bem como custos ocultos.

O primeiro custo oculto está em seu gerenciamento e manutenção – o tempo e os recursos gastos no treinamento de sua equipe, solução de problemas, manutenção do sistema, manutenção de fluxos de trabalho internos e infraestrutura de autoatendimento.

Por vários motivos, os salários dos funcionários altamente qualificados necessários para este trabalho são ignorados por muitos ao calcular o custo de um ambiente Kubernetes completo. Tenha cuidado com as muitas comparações falhas entre ofertas totalmente gerenciadas ou sem servidor e Kubernetes autogerenciados. Freqüentemente, eles não contabilizam o custo com pessoal e os custos de oportunidade associados ao tempo perdido no Kubernetes.

O segundo custo oculto está vinculado ao ecossistema Kubernetes. Abraçar o mundo do Kubernetes muitas vezes implica mais do que apenas adotar uma plataforma de orquestração de containers. É como pisar num vasto continente, rico em funcionalidades e com todo um universo de ferramentas, serviços e produtos auxiliares oferecidos por diversos fornecedores, o que acaba por introduzir outros custos.

Conclusão

Uma boa ferramenta não se trata de seu entusiasmo ou popularidade, mas de quão bem ela resolve seus problemas e se encaixa em seu ecossistema. No cenário dos aplicativos nativos da nuvem, o Kubernetes, compreensivelmente, ocupou uma grande parte da conversa. No entanto, incentivo as equipes a considerarem as vantagens e desvantagens de diferentes abordagens viabilizadas por soluções como OpenShift, Docker Swarm ou serviços gerenciados e sem servidor orquestrados por estruturas como Nitric.

Em uma postagem de acompanhamento, explorarei uma abordagem para criar aplicativos nativos da nuvem sem depender diretamente do Kubernetes. Abordarei o processo de construção e implantação de aplicativos nativos da nuvem robustos, escaláveis ​​e resilientes usando infraestrutura provisionada por meio de serviços gerenciados como AWS Lambda, Google CloudRun e Azure ContainerApps.

Essa abordagem de desenvolvimento de aplicativos para a nuvem foi a inspiração para a Nitric, a estrutura de nuvem que estamos construindo e que se concentra em melhorar a experiência tanto para desenvolvedores quanto para operações.

Nitric é uma estrutura multilíngue de código aberto para desenvolvimento nativo em nuvem, projetada para simplificar o processo de criação, implantação e gerenciamento de aplicativos na nuvem. Ele fornece uma experiência consistente ao desenvolvedor em diversas plataformas de nuvem, ao mesmo tempo que abstrai e automatiza as complexidades envolvidas na configuração da infraestrutura subjacente.

Para equipes e projetos que consideram inadequada a interação e o gerenciamento direto do Kubernetes, seja devido a restrições orçamentárias, recursos limitados ou conjunto de habilidades, a Nitric oferece um caminho para aproveitar as mesmas vantagens. Mergulhe mais fundo na abordagem da Nitric e compartilhe seus comentários conosco no GitHub.

A postagem Kubernetes nem sempre é a escolha certa apareceu pela primeira vez em The New Stack.