O futuro da infraestrutura será conteinerizado

Atualmente, a maioria das startups e empresas de tecnologia usa a nuvem, mas muitas ainda não perceberam todos os benefícios dela. Se você está na nuvem, mas não no Kubernetes, provavelmente está usando soluções proprietárias na criação e manutenção das suas próprias ferramentas personalizadas complementares. Você também não está operando com a máxima eficiência, as cargas de trabalho de máquinas virtuais (VMs) estão subutilizadas e é possível que esteja se prendendo a esse modelo. 

Quantas ferramentas você usa para gerenciar e corrigir suas VMs? Como você faz o upgrade dos aplicativos? E como você usa as VMs? O que você tem agora pode não ser tão eficiente. Problemas acontecem (falhas temporárias, problemas de escalonabilidade etc.) devido à fragilidade da arquitetura da VM, os custos estão fora de controle ou a infraestrutura não comporta tudo que a empresa precisa fazer:

• Refatorar/reestruturar a arquitetura de um MVP para criar uma solução escalonável.
• Adotar mais provedores de nuvem para atender às exigências regulamentares ou às expectativas dos clientes.
• Expandir geograficamente para reduzir a latência e oferecer experiências melhores para uma ampla base de clientes.
• Reforçar a postura de segurança de ponta a ponta.
• Melhorar a experiência do cliente (por exemplo, disponibilidade do serviço)

Dívidas antigas ou técnicas podem atrapalhar. É por isso que vemos essa grande mudança para o Kubernetes. Uma arquitetura moderna e composta por contêineres gerenciados oferece acesso a padrões comprovados para executar uma infraestrutura confiável e segura. É possível acelerar o tempo de lançamento e aumentar a produtividade sem sacrificar a estabilidade e a segurança. Além disso, fica mais fácil atrair os melhores talentos técnicos para trabalhar em inovação.

Também é preciso se preocupar em não se isolar da comunidade do Kubernetes e do ecossistema ao redor. Afinal, a inovação estável dele define os padrões e as práticas recomendadas atuais do setor. Em última análise (e isso é ainda mais importante por causa do desafios atuais nas contratações), é preciso decidir onde você quer que os engenheiros passem o tempo: na manutenção da infraestrutura e na criação e manutenção de ferramentas personalizadas ou na administração das prioridades para impulsionar seus negócios. O que você tem hoje pode estar funcionando. No entanto, pelo caminho você provavelmente passará por problemas que preferiria não encontrar, como débitos técnicos e lacunas na plataforma com relação a alguns itens:

• Criptografia de ponta a ponta
• Observabilidade (registros, métricas, geração automática de registros)
• Gerenciamento e aplicação de políticas
• Alta disponibilidade e failover automático
• Redução de custos

O Kubernetes tem código aberto, não depende de nenhuma plataforma e oferece todas as ferramentas comuns prontas para uso para proteger e acelerar cada estágio do ciclo de vida de criação e implantação. Ele é a soma de todos os scripts bash e práticas recomendadas que a maioria dos administradores de sistemas juntou ao longo do tempo, reunidos em um sistema no formato de um conjunto declarativo de APIs. Tudo é automatizado, os dados são ocultos e ele está pronto para uso. Com o Kubernetes, é possível eliminar boa parte da infraestrutura como código e mudar sua plataforma para a infraestrutura como dados. Não é preciso escrever ou manter códigos, basta informar o Kubernetes o que você quer, não o que fazer. Assim você economiza muito tempo e reduz gastos indiretos de gestão. 

Se você quer executar cargas de trabalho tradicionais, pode fazer isso em uma plataforma moderna com Kubernetes separando aplicativos de VMs e colocando-os em contêineres. Adotar imagens de contêiner para empacotar seu software facilita as atualizações das VMs. Agora é possível desacoplar o gerenciamento do ciclo de vida da VM e do aplicativo, simplificando a VM com a remoção de tudo que seja Ruby, Python e Java. E ao movê-lo para o lugar dele (próximo ao aplicativo do desenvolvedor), é possível controlar tudo em um único local e manter as máquinas bare metal.

As plataformas de computação gerenciada transformam os serviços em nuvem em plataformas como serviço, o que oferece a você o poder e a flexibilidade dos contêineres e a praticidade de estar sem servidor. Não há servidor, configuração de cluster e manutenção, o que significa que é possível ter benefícios enormes enquanto mantém o controle.

Para cargas de trabalho que não exigem muito controle sobre a configuração do cluster, é possível permitir que os serviços provisionem e gerenciem a infraestrutura subjacente do cluster, incluindo nós e pools de nós, pagando apenas pela carga de trabalho, não pelo cluster. Dessa forma, é possível eliminar a administração do cluster, além de otimizar a segurança e economizar bastante.

Para aplicativos mais nativos da nuvem, não ter servidor significa fazer o mesmo com menos trabalho, eliminando a infraestrutura subjacente e servindo como host de ponta a ponta para aplicativos, dados e até análises. Uma plataforma sem servidor permite que você comece a executar contêineres em um ambiente totalmente gerenciado com complexidade e segurança mínimas, desempenho, escalabilidade e práticas recomendadas incorporadas.

Vamos dar uma olhada nas possíveis implicações para seu negócio e como é possível manter sua organização à frente da curva de eficiência.

Algumas empresas acham necessário operar em várias nuvens. A gravidade dos dados é real e, se você tiver uma base de clientes global, inevitavelmente se verá atendendo clientes que querem minimizar a latência e as taxas de rede mantendo a computação perto de onde os dados residem.

Nesses casos, a opção com várias nuvens pode expandir seu mercado endereçável. Você acabará dando suporte a serviços gerenciados e dados em outros provedores de qualquer maneira. Outras empresas valorizam o uso de várias nuvens como uma estratégia de Redução de riscos. Em qualquer situação, a chave é adotar várias nuvens corretamente, e as soluções padrão do setor podem ajudar.

Primeiro: certifique-se de poder aproveitar novamente o máximo possível de seus fluxos de trabalho para realizar as tarefas. Por "fluxos de trabalho", queremos dizer ativar a automação de tarefas para criar a arquitetura de fluxo de dados entre o banco de dados e a computação. É aqui que o código aberto é importante: se você selecionar um banco de dados que não esteja aberto, terá dificuldade em implementar a arquitetura e a automação do fluxo de dados. É melhor usar algo como o protocolo Postgres (por exemplo, Cloud Spanner) ou um banco de dados Postgres gerenciado (por exemplo, Cloud SQL) em qualquer provedor de nuvem. 

Segundo: no lado da computação, o Kubernetes economiza muito tempo em implantações e automação. Portanto, ao escolher um conjunto de tecnologias, verifique se elas funcionam além dos limites estabelecidos pelo seu provedor. Os limites podem ser regiões ou zonas diferentes, projetos ou contas diferentes e até mesmo no local ou na nuvem. Não perca tempo criando e mantendo infraestruturas separadas para cada provedor de nuvem (por exemplo, uma na AWS, uma no Google e uma no Azure). Os engenheiros vão se afundar tentando mantê-las em pé de igualdade. Se você criar uma vez e implantar em várias nuvens, quando precisar fazer atualizações, poderá fazer isso de maneira centralizada e consistente. Pilhas de computação como o Kubernetes oferecem uma enorme vantagem aos clientes que levam a sério o uso de várias nuvens de uma maneira eficiente e que não exige a reinvenção da roda toda vez que você quer integrar um provedor de nuvem novo.

Terceiro: gerenciamento de riscos. Conseguir executar sua pilha em outro ambiente ajuda a mitigar o risco de seu provedor de nuvem cair ou começar a concorrer com sua empresa. Para cumprir os regulamentos, as organizações escolhem provedores para garantir a continuidade dos negócios. Por exemplo, se você perder operações em uma região, não terá inatividade com um provedor de backup.

As migrações em várias nuvens que tendem a funcionar bem são as que utilizam padrões abertos. Veja o Kubernetes, por exemplo, que oferece uma API que não depende de provedor tanto para executar aplicativos quanto para configurá-los e implantá-los e para integrar itens como políticas de segurança, rede e muito mais. Pense no Kubernetes como um sistema operacional de várias nuvens. Como é sua camada de abstração, geralmente é possível ocultar as diferenças entre a maioria dos principais provedores de nuvem.

Quando você decide usar o Kubernetes, tem algumas opções. Com certeza, é possível executá-lo por conta própria. O Kubernetes é um projeto de código aberto, então é possível fazer o download dele e passar anos integrando-o ao seu provedor de nuvem ou ambiente preferido.

No entanto, se você decidir que esse não é o melhor uso do seu tempo, poderá usar uma oferta gerenciada do Kubernetes. Se você está na AWS, isso significa o EKS. Se você está no Azure, significa o AKS. E, se está no Google Cloud, significa o Google Kubernetes Engine (GKE). Todas essas opções fornecem uma API Kubernetes comum. Portanto, quando sua equipe criar as ferramentas e os fluxos de trabalho, será possível reutilizá-los em vários provedores.

Mas nem todas as ofertas de serviços gerenciados são criadas da mesma forma. A qualidade do Kubernetes depende da infraestrutura em que ele é executado, e o GKE cumpre todos os requisitos de um serviço de orquestração do Kubernetes maduro e totalmente gerenciado. Ele oferece IaaS totalmente integrada, desde o provisionamento de VMs Tau, com um desempenho de preço 42% melhor em relação a ofertas de uso geral comparáveis, ¹ escalonamento automático em várias zonas e upgrades, até a criação e o gerenciamento de GPUs, TPUs para machine learning, volumes de armazenamento e credenciais de segurança sob demanda. Tudo o que você precisa fazer é colocar seu aplicativo em um contêiner e escolher um sistema de acordo com suas necessidades.

E se você escolheu a AWS como provedor de nuvem para VMs? Você precisa ficar com o EKS? Em alto nível, o Kubernetes é igual em todos os provedores de nuvem: você terminará com a API Kubernetes. No entanto, abaixo dessa API há um cluster, nós de trabalho, políticas de segurança, tudo. E é aí que o GKE se destaca.

Por exemplo, se você ainda precisar desses outros clusters, poderá conectá-los ao GKE Connect, que oferece um local único para gerenciar, visualizar, resolver problemas e depurar todos eles, além de também gerenciar de maneira centralizada itens como credenciais. O GKE é o melhor Kubernetes por causa da capacidade de gerenciamento de ponta a ponta, não apenas por causa do plano de controle ou da alta disponibilidade multirregião ou multizona. O GKE também pode aproveitar os balanceadores de carga globais usando a Ingress de vários clusters gerenciada de maneira centralizada em vários clusters e várias regiões.

E se você quiser a API Kubernetes, mas não a responsabilidade de provisionar, escalonar e fazer upgrade de clusters? Para a maioria das cargas de trabalho, o GKE Autopilot abstrai a infraestrutura subjacente do cluster, incluindo nós e pools de nós, e você paga apenas pela carga de trabalho. O GKE Autopilot oferece a você a API Kubernetes padrão com todos os padrões de segurança robustos. Assim, é possível se concentrar em suas cargas de trabalho, não no cluster.

__________________________

¹ Os resultados têm como base a estimativa do SPECrate®2017_int_base executado em VMs de produção de dois outros fornecedores de nuvem líderes e nas VMs Tau de pré-produção do Google Cloud usando os compiladores recomendados pelo fornecedor. SPECrate é uma marca registrada da Standard Performance Evaluation Corporation. Mais informações estão disponíveis em www.spec.org..

O Kubernetes passou as organizações das VMs para um novo conjunto de abstrações que permitem automatizar operações e focar nos seus aplicativos. Mas para cargas de trabalho mais específicas (por exemplo, aplicativos para dispositivos móveis e para a Web, back-end de APIs REST, processamento de dados, automação de fluxo de trabalho), é possível simplificar ainda mais e otimizar sua implantação aproveitando o modelo sem servidor.

Talvez você esteja usando o AWS Lambda, uma plataforma sem servidor conhecida e que permite escrever funções como serviço e conectá-las a todos os tipos de eventos. No entanto, como você acaba se conectando a um banco de dados e lidando com questões de segurança, essas funções tendem a crescer em complexidade, algumas até maiores que os aplicativos normais. Então, o que acontece quando você tem um aplicativo que supera a simplicidade de uma função como serviço ou um aplicativo atual que quer uma execução sem servidor?

Ao contrário de uma plataforma sem servidor tradicional que exige que você reescreva seus aplicativos, o Cloud Run oferece uma abordagem que ajuda você a reutilizar os investimentos atuais em aplicativos conteinerizados. O GKE é um serviço gerenciado, mas ainda é preciso tomar algumas decisões importantes: em quais zonas executar, onde armazenar registros, como gerenciar o tráfego entre diferentes versões de aplicativos, nomes de domínio registrados e gerenciamento de certificados SSL.

O Cloud Run elimina todas essas decisões, permitindo que você execute cargas de trabalho mais tradicionais e evite inicializações a frio desativando completamente a redução da escala a zero. O Cloud Run também aceita executar os aplicativos sempre, junto com outros requisitos tradicionais, como integrações VPC, WebSockets e NFS. No entanto, como a maioria das plataformas tradicionais sem servidor, o Cloud Run é opinativo e oferece recursos como gerenciamento de tráfego integrado e escalonamento automático.

Imagine que você não esteja usando contêineres e se pergunte por onde começar. Veja aqui a abordagem pragmática para adotar a conteinerização.

O primeiro motivo para adotar contêineres é resolver o problema de empacotamento. Hoje em dia, há muito trabalho sendo feito para produzir artefatos reproduzíveis e entender o que realmente está no nosso software. Ou, como o setor chama, a "cadeia de suprimentos de software segura". Acreditamos que uma maneira ideal de fazer isso é usar imagens de contêiner que contenham o código do aplicativo, os ambientes de execução e as dependências deles. Um benefício dos contêineres é que eles podem ser implantados em VMs, o que reduz a complexidade de implantação e manutenção de software em suas máquinas.

O segundo motivo para adotar contêineres é a orquestração. O gerenciamento de VMs vem com muita sobrecarga de gerenciamento e manutenção. Se sua empresa for como a maioria, sua equipe executa dezenas ou centenas de etapas para gerenciar a infraestrutura e, mesmo que essas etapas sejam automatizadas, essas ferramentas de automação ainda exigem manutenção contínua. E isso supondo que você esteja usando ferramentas de automação padrão do setor, como Terraform, Puppet, Chef e Ansible. A sobrecarga de manutenção é ainda pior para ferramentas caseiras ou personalizadas.

O terceiro motivo para adotar contêineres é a eficiência. Além da carga de manutenção, a maioria das organizações atinge apenas de 5 a 10% de utilização da CPU, sem mencionar memória e armazenamento. São muitos recursos desperdiçados. Muitas equipes estão criando ferramentas ainda mais personalizadas para sanar esse problema, implementando itens como escalonamento automático e empacotamento de caixas, gastando assim mais tempo operacional. Isso leva a gastos excessivos e uma conta de nuvem surpreendentemente alta.

Poucas organizações conseguem criar com sucesso a própria plataforma de orquestração, e é por isso que aproveitar uma plataforma de código aberto como Kubernetes, Mesos ou Nomad é uma escolha comum. Mas, se você quer uma plataforma que ajude a conseguir benefícios como manutenção reduzida, práticas recomendadas padrão do setor e integração profunda com o restante do seu provedor de nuvem, escolha um serviço gerenciado como o GKE para maximizar o valor potencial dos contêineres.

Neste ponto, talvez você se pergunte: "A migração para contêineres realmente significa um monte inatividade sem nenhum valor?". Você não quer apertar o botão de pausa para o desenvolvimento futuro, certo?

Para responder a isso, vamos ver como fazer o certo de um jeito que aproveite sua experiência na nuvem até o momento.

Pode parecer assustador migrar aplicativos de VMs para contêineres, especialmente se isso significa mover toda a sua computação para um provedor de nuvem novo. Mas a realidade é que não é preciso fazer tudo de uma vez. É possível fazer um aplicativo por vez, começando com VMs e movendo um ou dois aplicativos para o Kubernetes, onde podem ficar lado a lado na mesma rede e conversar com as VMs. Não é preciso embarcar em uma transição completa. Dá para fazer uma mudança lenta de uma plataforma para outra.

Permanecer em VMs pode fazer sentido para alguns aplicativos, como bancos de dados grandes e pesados que aproveitam pouco o Kubernetes. Não há problema em misturar e combinar. Mas o que vimos é que a maioria dos clientes ganha muito ao mover aplicativos e projetos de código aberto para o cenário do Kubernetes. Priorize os aplicativos que trarão o maior retorno ao migrar para o GKE. Não é preciso mover tudo de uma vez.

O Kubernetes ainda é executado nas mesmas VMs Linux que você provavelmente usa hoje. O que você recebe é um fluxo de trabalho mais simplificado e consistente que incorpora muitos itens que precisam estar em seu roteiro de infraestrutura, em vez do que poderia ser uma coleção de automação e scripts caseiros. A integração de novos componentes da equipe também se torna muito mais fácil quando você usa uma ferramenta padrão do setor, como o Kubernetes, em vez de ter que ensiná-los todas as maneiras personalizadas que sua empresa usa.

Neste ponto, você tem um caminho a seguir para adotar os contêineres de maneira lenta, mas pragmática, economizando o tempo da equipe em termos de sobrecarga administrativa e poupando o dinheiro da empresa em custos com computação.

Falamos muito aqui sobre contêineres e migrações para a nuvem, seja se você tem interesse no Kubernetes e procura uma oferta melhor, seja se quer uma abordagem diferente que se adapte aos seus aplicativos e roteiro atuais.

Seja qual for o caminho de desenvolvimento do seu aplicativo, a opção de contêineres gerenciados minimiza os custos de infraestrutura e maximiza a capacidade de sua equipe de se concentrar na criação de ótimos produtos. O futuro da infraestrutura é a conteinerização. É hora de garantir que seus engenheiros e sua empresa estejam preparados para ter o maior sucesso possível. 

Kubernetes para nativos da nuvem: comece sua jornada de desenvolvimento no GKE

Contêineres no Cloud: uma maneira melhor de desenvolver e implantar aplicativos

O passado, presente e futuro do Kubernetes com Eric Brewer

Como migrar para a arquitetura nativa da nuvem: uma abordagem evolucionária para aumentar a produtividade do desenvolvedor em escala