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 executada em um ambiente de teste isolado com o toque de um botão:

E quando dizemos “ambiente isolado”, queremos dizer tudo : o próprio aplicativo (com as alterações de código no ramo PR) com suas próprias instâncias dedicadas de SQL Server, Redis, Elasticsearch e peças de serviços adicionais. Tudo girado do zero em minutos e executado em um punhado de contêineres em um namespace dedicado , apenas para você e qualquer pessoa interessada em seu PR.  

Isso não é algo que inventamos; outras organizações têm usado esse conceito. A ideia é que cada mudança de código vá para um sistema de controle de versão como o Git por meio de uma solicitação de pull. Outros desenvolvedores revisarão o código, mas o código não contará toda a história. Você quer ver o código em ação. Normalmente, você teria que baixar todo o código localmente, compilá-lo e executá-lo. Isso pode ser simples, mas se você estiver executando um grande aplicativo que extrai código de vários repositórios ou - tenha misericórdia - uma arquitetura de microsserviço, então você pode executar várias horas de depuração.

Melhor ainda, digamos que você comprimiu todos os commits de um novo recurso em um único e o está comprometendo como um único PR. Envie esse ambiente de RP para vendas ou marketing como um único link para que eles possam visualizar o recurso em ação. Se sua equipe de vendas deseja demonstrar o aplicativo com recursos específicos ou construções personalizadas, envie um link de ambiente de RP. Você não terá que perder tempo orientando seus colegas menos técnicos pelo processo de construção. 

Foi necessário muito trabalho de base para chegar a esse ponto. Em primeiro lugar, executar o .NET Framework clássico em contêineres do Windows não era realmente um caminho que queríamos seguir. É possível em teoria - o suporte do Windows está disponível no Kubernetes desde a v1.19 - mas o ecossistema Docker / Kubernetes é realmente mais centrado no Linux. Felizmente, nossa migração para o .NET Core já estava em andamento, então decidimos apostar nos containers Linux. 

Isso, é claro, veio com seu próprio conjunto de desafios. Quando você está lidando com uma base de código com mais de 10 anos de idade, provavelmente encontrará suposições sobre a infraestrutura em que está sendo executado: caminhos de arquivo codificados (incluindo nosso favorito: barra vs. barras invertidas), URLs de serviço, configuração e assim sobre. Mas, eventualmente, chegamos lá e agora estamos em um lugar onde podemos acionar um número arbitrário de instâncias de teste, a rede e nosso produto em nosso cluster Kubernetes com escalonamento automático. Que hora de estar vivo!

Olhando para os primeiros dias, ter esse tipo de ferramenta disponível naquela época seria uma virada de jogo. Nos estágios iniciais da construção de um produto, você normalmente deseja construir, medir e aprender o máximo e o mais rápido possível. Usando recipientes e Kubernetes lhe permitirá construir as ferramentas para isso e à prova de futuro você no caso de você estiver indo para escala. 

Então, você deve usar o Kubernetes desde o primeiro dia? Pode ser! Ainda depende, é claro, de seu projeto específico, de seus requisitos e de suas prioridades. 

Mas você tem dito “não precisamos do Kubernetes porque ainda não temos produtos adequados ao mercado”? Dê uma olhada mais de perto e talvez você se pegue dizendo "precisamos do Kubernetes porque ainda não temos produtos adequados para o mercado".

O Avance Network é uma comunidade fácil de usar que fornece segurança de primeira e não requer muito conhecimento técnico. Com uma conta, você pode proteger sua comunicação e seus dispositivos. O Avance Network não mantém registros de seus dados; portanto, você pode ter certeza de que tudo o que sai do seu dispositivo chega ao outro lado sem inspeção.