O esforço para configurar o Kubernetes é menor do que você pensa. Certamente, é menos do que o esforço necessário para refatorar seu aplicativo posteriormente para oferecer suporte à conteinerização.

 

Se você está começando um novo projeto do zero – um novo aplicativo, serviço ou site – sua principal preocupação geralmente não é como operá-lo em escala web com alta disponibilidade. Em vez disso, é provável que você se concentre em construir a coisa certa para o cliente que está almejando ou em encontrar o produto adequado para o mercado. Se você estiver criando um MVP para uma inicialização, você precisa chegar a isso antes de escalar, caso contrário, para quem você está escalando? Se você é um desenvolvedor em uma empresa, deseja ter certeza de que está atendendo às expectativas e necessidades do negócio. Operar em grande escala é, na melhor das hipóteses, um problema de amanhã.

 

Portanto, quando se trata de escolher o conjunto certo de tecnologias, o Kubernetes – comumente associado a sistemas grandes e distribuídos – pode não estar no seu radar agora. Afinal, ele vem com uma quantidade significativa de sobrecarga: configuração e operação de um cluster, contêinerização de seu aplicativo, definição de serviços, implantações, balanceadores de carga e assim por diante. Isso pode parecer um exagero no estágio inicial, e você pode pensar que seu tempo seria melhor gasto em outras tarefas, como codificar as primeiras duas iterações do seu aplicativo real.

 

Passar por esse processo nos deu uma nova perspectiva. Se você estiver criando um novo aplicativo hoje, pode valer a pena dar uma olhada mais de perto em torná-lo nativo da nuvem e usar o Kubernetes desde o início. O esforço para configurar o Kubernetes é menor do que você pensa. Certamente, é menos do que o esforço necessário para refatorar seu aplicativo posteriormente para oferecer suporte à conteinerização.

 

Aqui estão três motivos pelos quais criar seu aplicativo no Kubernetes desde o início pode não ser mais uma ideia tão ruim.

 

Kubernetes gerenciado faz o trabalho pesado

 

No Avance Network, quando configuramos nosso primeiro cluster Kubernetes interno há alguns anos, demoramos quase uma semana para colocar tudo em funcionamento: provisionar máquinas virtuais, instalar, configurar, configurar, configurar. Assim que o cluster foi ativado, houve manutenção contínua. No final das contas, percebemos que o Kubernetes era ótimo para nós, mas queríamos que outra pessoa o executasse.

 

Hoje, os serviços Kubernetes gerenciados, como o Elastic Kubernetes Service (EKS) da Amazon, o Azure Kubernetes Service (AKS) da Microsoft ou o Google Kubernetes Engine (GKE) do Google, permitem que você configure seu próprio cluster literalmente em minutos. Por exemplo, no AKS, você pode apenas clicar em alguns botões no portal e preencher alguns formulários:

 

Isso é conveniente, mas você pode querer parar antes de realmente criar o cluster no final do fluxo de trabalho. Vá até o assistente, mas não clique no botão azul “Criar” no final! Em vez disso, baixe a configuração que você acabou de criar como um modelo ARM e verifique-a em seu sistema de controle de origem. Agora você tem o melhor dos dois mundos – facilidade de uso e infraestrutura como código (IaC)!

 

Uma vez que você está configurado aqui, há pouco a fazer depois de começar a dimensionar seu aplicativo, exceto escrever verificações maiores para seu provedor de nuvem. Qualquer alocação de recursos adicionais é fácil. Os problemas que vêm com a escala – tolerância a falhas, balanceamento de carga, modelagem de tráfego – já foram resolvidos. Em nenhum momento você atingirá aquele momento de ser oprimido pelo sucesso; você preparou seu aplicativo para o futuro sem muito esforço extra.

 

Você pode permanecer (um pouco) agnóstico em relação à nuvem

 

Se o seu projeto for bem-sucedido, é provável que as decisões de tecnologia tomadas nos estágios iniciais ainda tenham um impacto meses ou anos depois.

 

O mesmo pode ser dito sobre dependências de serviços em nuvem. Você pode construir seu novo aplicativo com base em produtos de infraestrutura como serviço (IaaS), como o EC2 da Amazon. Ou talvez você esteja começando a depender de ofertas de plataforma como serviço (PaaS), como o Azure SQL da Microsoft. Mas você está disposto a assumir um compromisso de longo prazo com os provedores de nuvem por trás deles neste estágio? Se você ainda não sabe aonde sua jornada o levará, talvez prefira permanecer agnóstico em relação às nuvens por um pouco mais de tempo.

 

Vamos voltar à infraestrutura como código: colocar uma ferramenta como o Terraform na mistura vai ajudá-lo a permanecer agnóstico em relação à nuvem até certo ponto. Ele fornece um kit de ferramentas unificado e linguagem de configuração ( HCL ) para gerenciar seus recursos em diferentes provedores de nuvem e infraestrutura. É improvável que seu aplicativo seja realmente agnóstico em relação à nuvem, no sentido de que você poderá apenas trocar de provedor de nuvem tão facilmente quanto o provedor de Internet ou eletricidade em casa.

 

Aqui está uma boa discussão sobre este tópico no fórum da HashiCorp: O Terraform é realmente agnóstico em relação à nuvem? Como um dos comentadores aponta:

 

“Um cluster Kubernetes é um bom exemplo de abstração sobre recursos de computação: há muitas implementações hospedadas e autogerenciadas dele em diferentes plataformas, todas as quais oferecem uma API comum e um conjunto comum de recursos.”

 

Isso resume muito bem! Ainda não é uma abstração perfeita. Por exemplo, é provável que cada provedor de nuvem tenha sua própria maneira personalizada de implementar coisas como balanceadores de carga públicos e volumes persistentes no Kubernetes. Ainda é justo dizer que, se você estiver construindo no Kubernetes, vai se manter independente da nuvem até certo ponto.

 

Você pode facilmente criar novos ambientes – quantos quiser!

 

O Kubernetes geralmente é visto como uma forma de gerenciar sua infraestrutura de produção. Mas aqui no Avance Network, nós o usamos para gerenciar nossos ambientes de teste dinamicamente. Estamos usando o Kubernetes para hospedar o que chamamos de ambientes de relações públicas. Cada solicitação pull pode ser