Porque é que os CTO estão finalmente a levar a sério a complexidade do Kubernetes

Para muitos CTO, o Kubernetes começou por ser um motivo de orgulho — uma prova de que a sua equipa de engenharia conseguia arregaçar as mangas e “construir melhor por si própria”. Mas, algures entre o orgulho de fazer tudo sozinho e o caos à escala da produção, a realidade impôs-se. A complexidade instalou-se. A produtividade caiu a pique. E a promessa de agilidade começou a parecer pouco animadora.

Andrew Rynhard, fundador e CTO da Sidero Labs, já assistiu a esta mudança mais vezes do que consegue contar. Depois de criar o Talos Linux e o Omni para eliminar o excesso do Kubernetes e devolver a previsibilidade à infraestrutura, está agora a observar uma nova vaga de CTO chegar à mesma conclusão que ele: a simplicidade é uma estratégia.

Nesta conversa, Andrew explica como os líderes tecnológicos modernos equilibram o controlo com a eficiência, por que motivo a mentalidade de “não foi inventado aqui” compromete a produtividade dos programadores e como os sistemas declarativos redefinem o significado de fiabilidade na era nativa da nuvem.

1. Como estão os CTO a gerir a tensão entre a complexidade da infraestrutura e a produtividade dos programadores à medida que adotam o Kubernetes? Que padrões estão a surgir entre aqueles que conseguem navegar esta realidade com sucesso?

Quando muitos CTO se aventuram pela primeira vez no Kubernetes, pensam frequentemente: “Ora, conseguimos pô-lo a funcionar sozinhos!” É uma mentalidade totalmente orientada para fazer tudo internamente que, francamente, vem acompanhada de uma forte dose da síndrome do “não foi inventado aqui”.

Muitas equipas acreditam que conseguem fazer melhor por si próprias, em vez de adotarem a abordagem de outra pessoa (mesmo quando isso significa afundarem-se na complexidade). Mas, em pouco tempo, em vez de impulsionarem o negócio, ficam presas a lutar com a infraestrutura.

É por isso que estou a assistir a uma mudança na estratégia de Kubernetes entre os CTO, que se resume a três medidas fundamentais. Em primeiro lugar, o objetivo é eliminar o excesso desnecessário logo na base. Em vez de se agarrarem a soluções genéricas e universais, os CTO estão a mudar as suas equipas para ferramentas mais especializadas e concebidas para fins específicos, desenvolvidas para ambientes nativos da nuvem. Isto não tem que ver com reinventar a roda — trata-se de eliminar os pontos de fricção que atrasam tudo.

Depois, os CTO estão a adotar cada vez mais princípios declarativos em toda a pilha (e não apenas no Kubernetes). Enquanto CTO, isto é especialmente pessoal para mim. Criei o Talos Linux e o Omni porque estava farto dos sistemas excessivamente formais e inflexíveis que existiam. Com uma abordagem declarativa, tratamos a infraestrutura como código, tornando tudo previsível e simples, e esse é o tipo de sistema em que podemos realmente confiar.

Também reparei que os CTO mais inteligentes estão a ser realistas quanto ao local onde as suas equipas devem investir o seu tempo. Em vez de manter os seus melhores programadores ocupados a gerir todos os pequenos detalhes da infraestrutura, por que não deixar que ferramentas concebidas para fins específicos tratem do trabalho pesado? Desta forma, a sua equipa pode concentrar-se no que realmente importa — fazer o negócio avançar.

No fim de contas, trata-se de eliminar toda essa complexidade desnecessária. Foi essa a abordagem que quis adotar com a nossa empresa — tratar dos detalhes complicados para que se possa concentrar no trabalho técnico mais criativo e de maior impacto que faz avançar o seu negócio.

2. Muitos CTO estão a ponderar se devem criar plataformas internas baseadas em Kubernetes ou adotar serviços geridos. Que fatores fundamentais devem os CTO / líderes tecnológicos considerar ao tomar esta decisão estratégica para a sua infraestrutura SaaS?

Decidir se deve criar a sua própria plataforma Kubernetes ou depender de serviços geridos passa por equilibrar a previsibilidade dos custos, o controlo e a liberdade técnica.

Os serviços geridos são uma opção tentadora para começar rapidamente, mas muitas vezes implicam custos ocultos que só se fazem sentir quando a escala aumenta. Já vi demasiadas empresas serem apanhadas desprevenidas por esses custos. Gerir a sua própria plataforma — especialmente em servidores dedicados — pode proporcionar um controlo dos custos mais fiável a longo prazo. Além disso, embora os serviços geridos permitam começar rapidamente, podem prendê-lo a uma configuração rígida.

Quando precisa de otimizar cargas de trabalho únicas ou reforçar a segurança segundo os seus próprios critérios, essa rigidez pode ser um fator decisivo. O segredo é começar com aquilo que funciona e, depois, desenvolver gradualmente os conhecimentos especializados e a infraestrutura internos necessários para obter esse nível adicional de controlo onde ele realmente conta.

3. Com o crescimento da computação periférica e dos sistemas distribuídos, que desafios observa à medida que as organizações tentam escalar as suas implementações de Kubernetes em vários ambientes computacionais? Como estão os CTO e as suas equipas a abordar com sucesso a observabilidade e a gestão?

A computação periférica e os sistemas distribuídos introduzem todo um novo conjunto de desafios. A maior dificuldade é manter a consistência. Quando se gerem implementações na nuvem pública, em servidores dedicados e em localizações periféricas, utilizar uma mistura descoordenada de ferramentas e processos pode rapidamente conduzir ao caos — e até criar falhas de segurança. O acesso remoto e a resolução de problemas tornam-se particularmente complexos na periferia, e os CTO com visão de futuro estão a recorrer a soluções que combinam o acesso com uma observabilidade robusta (este é um dos muitos benefícios das ferramentas de observabilidade de dados).

E nem me faça começar a falar do armazenamento — garantir que os dados permanecem acessíveis e no local certo é um verdadeiro desafio. A estratégia vencedora é a normalização. Ao utilizar plataformas de gestão unificadas que automatizam as implementações e disponibilizam monitorização consistente em todos os ambientes, pode simplificar a complexidade e manter tudo a funcionar sem problemas.

4. Muitas organizações têm dificuldades com os conjuntos de competências especializados necessários para as operações de Kubernetes. Como devem os CTO abordar a criação e a estruturação das suas equipas de plataforma? Que padrões estão a observar nas organizações bem-sucedidas?

Contratar verdadeiros especialistas em Kubernetes pode parecer como perseguir unicórnios. A abordagem mais inteligente e prática consiste em criar uma equipa com uma verdadeira vontade de aprender e resolver problemas. Em vez de se concentrarem obsessivamente em credenciais impressionantes, apostem em pessoas capazes de evoluir com a tecnologia. Se juntarem a isso parcerias estratégicas — recorrendo inicialmente a fornecedores de plataformas experientes para obter um impulso inicial e transferir conhecimentos — terão a receita para o sucesso.

Comecem por uma pequena escala, aprendam rapidamente e desenvolvam a experiência interna ao longo do tempo. Não se trata de ter todas as respostas desde o primeiro dia, mas de criar uma equipa capaz de se adaptar e prosperar.

5. À medida que as organizações aumentam a sua utilização de Kubernetes, a gestão de custos torna-se cada vez mais complexa. Que estratégias estão os CTO a utilizar para manter a eficiência operacional enquanto apoiam um crescimento rápido?

À medida que a utilização de Kubernetes aumenta, a gestão dos custos resume-se à previsibilidade e à eficiência. Estamos agora a assistir a um regresso às abordagens locais e híbridas, à medida que mais empresas descobrem as despesas ocultas de uma configuração exclusivamente na cloud — pensem nos custos de saída de dados e nas taxas de serviço que passam despercebidas.

Em vez de escolherem por defeito a cloud pública, a opção inteligente é adoptar uma abordagem estratégica à colocação das cargas de trabalho. Muitas organizações estão a redescobrir o valor dos servidores físicos para cargas de trabalho estáveis e previsíveis, nas quais é possível fixar os custos e evitar surpresas. E, com as ferramentas e a automatização certas, concebidas especificamente para Kubernetes, podem optimizar a utilização dos recursos sem sacrificar a flexibilidade.

6. A segurança nos ambientes Kubernetes continua a evoluir rapidamente. Como devem os CTO pensar na relação entre o seu sistema operativo, a segurança do Kubernetes e a sua estratégia geral de segurança da infraestrutura?

A segurança não é apenas um complemento do Kubernetes; é a espinha dorsal de qualquer ambiente Kubernetes sólido. As ligações profundas entre Kubernetes e Linux podem ser tanto uma bênção como uma maldição, especialmente à medida que os ataques dirigidos a contentores se tornam mais sofisticados. É por isso que muitos CTO estão a abandonar os sistemas operativos de uso geral em favor de distribuições especializadas concebidas exclusivamente para Kubernetes.

Esta mudança reduz significativamente a superfície de ataque e integra os controlos de segurança onde são mais necessários. Pensem nisto da seguinte forma: uma segurança robusta é incorporada desde o início. Automatizem a encriptação ao nível da rede, imponham a gestão baseada em API em vez de se agarrarem ao acesso SSH desactualizado e protejam todos os canais de comunicação com encriptação TLS mútua.

Seguir normas estabelecidas não se resume a assinalar caixas; trata-se de criar uma infraestrutura tão segura quanto ágil.

7. À medida que mais empresas SaaS avançam para modelos de cloud híbrida, que padrões de implementação estão a observar na gestão de clusters e na automatização de implementações? Que abordagens parecem estar a funcionar bem à escala?

À medida que as empresas SaaS adoptam modelos de cloud híbrida, gerir clusters e automatizar implementações em diferentes ambientes pode ser um verdadeiro exercício de malabarismo. Surgiram duas estratégias principais: executar um único cluster para vários ambientes ou implementar clusters separados, adaptados a cada ambiente, todos ligados por uma ferramenta de gestão unificada.

O segredo está em implementações verdadeiramente independentes da infraestrutura. As ferramentas tradicionais para várias clouds falham frequentemente quando se trata de integrar servidores físicos com recursos da cloud. As melhores equipas apostam na automatização e nas operações baseadas em intenções, permitindo que o sistema trate dos pormenores enquanto se concentram no panorama geral.

8. Olhando para os próximos 3-5 anos, como prevê que evolua o panorama da automatização da infraestrutura? Que medidas devem os CTO tomar agora para garantir que as suas estratégias de Kubernetes continuam flexíveis e preparadas para o futuro?

A automatização da infraestrutura Kubernetes está prestes a sofrer uma grande transformação. Falamos de abandonar os antigos scripts de automatização em favor de sistemas que operam com base em intenções — plataformas inteligentes, quase autónomas, que definem o seu próprio rumo com uma intervenção humana mínima. A IA e a aprendizagem automática já estão a transformar a forma como gerimos a infraestrutura, não apenas através da automatização da resolução de problemas, mas também ao repensarem fundamentalmente as operações das plataformas.

A jogada inteligente para qualquer CTO é investir hoje em bases flexíveis e preparadas para o futuro. Escolham ferramentas e plataformas que adoptem princípios declarativos, evitem a dependência de um fornecedor e separem o “quê” do “como”. Dessa forma, quando surgir a próxima grande mudança tecnológica, já estarão na dianteira.

O Kubernetes não vai desaparecer — mas a forma como os CTO o abordam está a evoluir rapidamente. O futuro não consiste em saber quem consegue gerir a maior quantidade de YAML ou criar a plataforma interna mais sofisticada; consiste em saber quem consegue criar algo previsível. Como diz Andrew, as equipas mais inteligentes estão a escolher ferramentas que lhes permitem concentrar-se no que realmente faz avançar o negócio — e não naquilo que o mantém a arrancar.

Por outras palavras, a próxima geração de inovação da infraestrutura poderá parecer muito menos “construir tudo internamente” e muito mais deixar de controlar tudo.