![Modelos Pulumi para pilhas GenAI: Pinecone, LangChain First](https://optimuscloud.com.br/wp-content/uploads/2024/02/1708536339_Modelos-Pulumi-para-pilhas-GenAI-Pinecone-LangChain-First-150x150.jpg)
Modelos Pulumi para pilhas GenAI: Pinecone, LangChain First
21 de fevereiro de 2024![Roteiro de streaming para 2024: navegando na revolução em tempo real](https://optimuscloud.com.br/wp-content/uploads/2024/02/Roteiro-de-streaming-para-2024-navegando-na-revolucao-em-tempo-150x150.jpg)
Roteiro de streaming para 2024: navegando na revolução em tempo real
21 de fevereiro de 2024Em 2020, as pessoas previam que o Kubernetes desapareceria dentro de um ano. Eles acreditavam que alguém criaria um serviço que reduziria as opções adjacentes e tornaria o Kubernetes o padrão fácil. Todos usariam o Kubernetes, mas poucas pessoas trabalhariam no nível básico.
Verifiquei esta manhã e ainda está aqui – assim como as porcas e os parafusos. Então, por que a solução para o problema de complexidade do Kubernetes se mostrou tão ilusória?
Um ecossistema de escolhas
Isoladamente, o Kubernetes não é particularmente complicado, mas é rodeado por um amplo ecossistema de ferramentas, opções e decisões. Você pode executar o Kubernetes em qualquer lugar, desde uma máquina local até a nuvem. Você pode executar em uma única máquina de baixo consumo ou em milhares de nós de hiperescala. Você pode usá-lo para executar um monólito ou milhares de microsserviços.
Não existe uma maneira opinativa de usar o Kubernetes. Ele foi projetado para ser altamente flexível. Isso significa que você pode tomar todas as decisões. Você escolhe exatamente como configurar o Kubernetes e quais ferramentas usar junto com ele.
É sobre o grande volume de decisões que você precisa tomar para começar que as pessoas falam quando dizem que as coisas estão difíceis, e não sobre a complexidade do Kubernetes em si.
E isso antes de você considerar o software em si. Se você acabou de escrever um microsserviço em Go que roda em um contêiner, é muito fácil executá-lo no Kubernetes. Se você tiver um monólito legado escrito sob a suposição de que ele seria executado em uma máquina virtual, há muito trabalho para dobrá-lo para funcionar em um contêiner.
Não é de admirar que um desenvolvedor responsável por entregar software que resolva problemas de negócios fique sobrecarregado quando se depara com tantas opções ao longo do caminho, especialmente quando visto de forma agregada entre as diferentes escolhas a serem feitas para contêineres, automação de infraestrutura e registros de contêineres, com os diversos arquivos formatos e convenções usados.
Se você quer ir de bicicleta para o trabalho, escolher uma bicicleta é uma tarefa que exige muita pesquisa, então imagine comprar quadro, rodas, guidão, freios e câmbio separadamente. Alguns motociclistas vão querer esse nível de controle, mas é impressionante quando seu trabalho é apenas chegar ao destino.
Sobrecarga cognitiva e equipes de plataforma
A visão de que o Kubernetes se tornaria um utilitário silencioso e efetivamente desapareceria enquanto executava todas as nossas cargas de trabalho não se concretizou. Ninguém conseguiu criar um caminho único e opinativo para o Kubernetes que cuidasse de todas essas escolhas.
A simples razão para isso é que o caminho mítico e verdadeiro não funcionaria para a maioria dos aplicativos e serviços. É impossível criar um caminho simples e simples sem reconhecer o contexto da aplicação e da organização.
É por isso que a engenharia de plataformas ganhou força. Embora haja poucas chances de criar um caminho de escolhas simplificadas em todo o setor, criar um dentro de uma organização é perfeitamente viável.
Uma plataforma mínima viável poderia ser uma página wiki listando decisões pré-preparadas e fornecendo um exemplo padrão para cada arquivo de configuração. Isso pode evoluir para uma fachada que permite aos desenvolvedores especificar o que precisam em uma dimensão simples, como “tamanho”, com a plataforma cuidando dos detalhes por trás da bandeira.
As plataformas devem fornecer maneiras simplificadas de fazer a coisa certa e, ao mesmo tempo, permitir que desenvolvedores especialistas retirem as camadas quando a abordagem padrão não for adequada.
Menos opções sem limitar equipes
A falta de um caminho único e opinativo para o Kubernetes ressalta a importância dos fatores contextuais para a aplicação e a organização. Embora a criação de uma abordagem universal e simplificada seja impraticável, a engenharia de plataforma é uma forma de reduzir as muitas decisões que precisam ser tomadas ao longo do caminho, especialmente quando tais decisões não são cruciais.
Apesar dos problemas de complexidade percebidos, o Kubernetes não fez nada além de crescer. Claramente, os benefícios superam os problemas da adoção. Então, imagine o que aconteceria se o Kubernetes e as partes móveis associadas fossem mais fáceis de adotar?
As equipes de plataforma podem ser o fator crucial na criação de uma configuração obstinada do Kubernetes que ainda respeite o contexto local. Talvez as previsões não estejam erradas, apenas atrasadas.
Para saber mais sobre o Kubernetes e o ecossistema nativo da nuvem, junte-se a nós na KubeCon + CloudNativeCon Europe em Paris, de 19 a 22 de março.
A postagem As previsões do Kubernetes estavam erradas apareceu pela primeira vez em The New Stack.