Tente usar o Kubernetes como um servidor de aplicativos para equipes menores, em vez de tratá-lo como uma nuvem centralizada
O Kubernetes é legal, mas não pelos motivos que você pensa. Por um tempo, as pessoas se aglomeraram no Kubernetes porque ele prometia ser uma ótima nova tecnologia de nuvem – algo como o OpenStack (sem todos os seus problemas). Mas o Kubernetes não. Nem era uma cura mágica para o aprisionamento que oferecia portabilidade desenfreada. Nem mesmo perto.
Em vez disso, o Kubernetes se tornou o novo Linux. Ou, talvez mais precisamente, é um novo servidor de aplicativos, como sugeriu Alexis Richardson, CEO da Weaveworks, em uma entrevista. Em vez de as empresas tentarem criar suas próprias nuvens, ele argumenta: “Deixe suas equipes de desenvolvimento executarem clusters Kubernetes de curta duração que são como servidores de aplicativos”.
O que isso significa, exatamente?
Richardson e eu deveríamos conversar sobre multicluster Kubernetes em bare metal com microVMs alimentados por Firecracker. Cinco segundos depois, meus olhos estavam vidrados, o que era um problema, já que eu estava dirigindo. “Além de ser adequado para o cenário de borda, o modo misto permite uma eficiência significativamente maior no gerenciamento de clusters Kubernetes bare metal, movendo os nós do plano de controle de servidores bare metal dedicados para microVMs, reduzindo significativamente o número geral de nós necessários em um pool bare metal!”, ele entoou, citando a postagem do blog da empresa sobre o assunto.
Eu estava tentando desesperadamente me importar, visto que meu empregador lançou o Firecracker como um projeto de código aberto. Mas eu não consegui. Eu não poderia ficar animado com as operadoras de telecomunicações lançando “aplicativos 5G onde a ‘função de rede’ (carga de trabalho 5G) pode ser executada junto com funções de sinalização, funções de gerenciamento, aplicativos da web e do cliente no mesmo hardware com forte isolamento e controle de recursos”.
Alguém se preocupa com isso. Eu não.
Nesse ponto, Richardson disse: “Estou fazendo sentido? Você está aí? Olá?” e pensei em desligar e fingir que meu sinal havia caído. Mas então ele disse que tudo se tratava de “uma maneira hipereficiente de iniciar frotas de clusters do Kubernetes com recursos mínimos” e meus olhos começaram a desviar um pouco.
Quando realmente fez sentido, no entanto, foi quando ele comparou o Kubernetes ao Linux ou a um servidor de aplicativos. Este era um mundo que eu conhecia, tendo crescido em tecnologia durante a era JBoss/BEA dos servidores de aplicativos. Um servidor de aplicativos é uma coleção de funcionalidades genéricas que você pode usar para executar um aplicativo, seja incorporando-o ao aplicativo ou executando-o primeiro e, em seguida, executando o aplicativo na parte superior. Embora não falemos mais sobre eles, eles são muito comuns na empresa.
No modelo de servidor de aplicativo, o ciclo de vida do aplicativo está associado ao ciclo de vida da pilha ou cluster do aplicativo em que está sendo executado. Quando você não precisa mais da infraestrutura, basta desligá-la e jogá-la fora. A nuvem é diferente; é permanente, mesmo que os recursos em execução não sejam. A ideia de nuvem é aquela em que alguém cuida da nuvem e persiste além de seus requisitos para usá-la. Em vez de empresas construindo suas próprias nuvens, Richardson diz, “deixe Amazon, Google e Microsoft executarem nuvens e deixe suas equipes de desenvolvimento executarem clusters Kubernetes de curta duração que são como servidores de aplicativos”.
Implícito no pensamento de Richardson sobre o Kubernetes-as-app-server está um princípio poderoso para a TI corporativa: liberte suas equipes de desenvolvimento. “Na verdade, é muito melhor permitir que equipes de aplicativos individuais configurem sua própria infraestrutura usando clusters Kubernetes em vez de adquirir recursos de cluster corporativo da TI central”, observa ele. Em vez de um enorme cluster do Kubernetes do qual as equipes de desenvolvimento individuais são forçadas a tomar emprestado, uma estratégia melhor é encorajar “aplicativos de uso único ou grupos de aplicativos que podem ser gerenciados por um pequeno grupo de pessoas – ou mesmo apenas um. A prática recomendada para usá-lo é ter muitos clusters do Kubernetes, muitos aplicativos apoiados pelo Kubernetes, em vez de tentar gerenciá-los como uma nuvem”.
Isso vai de encontro ao pensamento estabelecido que o Kubernetes é complicado e difícil. Bem, talvez. Mas essa dificuldade geralmente vem de tentar tratar o Kubernetes como uma nuvem centralizada, em vez de habilitar a funcionalidade de servidor de aplicativo para equipes menores. É uma questão de autonomia, Richardson explica:
“As equipes de desenvolvimento serão produtivas quando tiverem permissão para as próprias operações. Eles precisam saber que podem consertar as coisas quando elas dão errado. Caso contrário, eles não podem assumir a responsabilidade pela segurança e desempenho. Estamos capacitando isso na Weaveworks. O Kubernetes e o GitOps ajudaram muito nisso, porque as equipes de desenvolvimento podem fazer a infraestrutura, o cluster, a pilha, algo que eles podem iniciar e interromper à vontade. Eles podem adquiri-lo sob demanda. Antigamente, os desenvolvedores começavam e interrompiam o Tomcat à vontade. Eles não pediriam permissão a outra pessoa para fazer isso, certo? É assim que o Kubernetes está indo. Funciona exatamente da mesma maneira na empresa”.
Esta é uma visão incrivelmente libertadora para a TI moderna. É também uma ótima maneira de entender o technobabble que deu início à nossa conversa. “Na postagem do blog que compartilhei com você”, diz ele, “estamos apenas mostrando que podemos fazer isso de forma mais eficiente com uma classe mais ampla de casos de uso, incluindo cargas de trabalho periféricas”. Oh, bem, por que ele não disse isso antes?
