Importante iniciar com a observação que algumas generalizações realizadas nesse artigo são apenas generalizações e não descrevem e nem poderiam descrever a realidade de um setor como um todo. O mesmo aviso serve para as hipérboles utilizadas no texto.
A consolidação das práticas de operações de software, como DevOps, SRE e Platform Engineering, estabeleceu um caminho de convergência mais claro para as ferramentas e arquiteturas de software.
Essa direção das ferramentas parece ter criado uma linha de chegada ou um alvo para várias organizações, mas para equipes que não atingiram um certo grau de maturidade tecnológica pode criar a ilusão da melhoria imediata.
A melhoria imediata é justamente a ideia de que existe uma ação ou ferramenta específica que, acima de qualquer dúvida, vai levar a uma situação de melhoria instântanea. É como se existisse um caminho direto para resolver o problema de cabeamento desse poste, ignorando as circunstâncias que o criou.
A melhoria contínua pode intimidar enquanto a melhoria imediata pode atrair
Apesar de todos os avanços da engenharia de software nas últimas décadas, a ideia e o processo de melhoria contínua ainda pode assustar uma série de organizações. O crescimento da maturidade tecnológica e o ganho cultural de equipes, resultados do processo de melhoria contínua, acabam sendo vistos como empecilhos para a entrega em certos cenários.
Muitos profissionais de software não compreendem que paradigmas como orquestração de contêineres, cloud e CI/CD foram desenvolvidos ao longo do tempo, resultado de tentativa e erro. Os referidos paradigmas são frutos de aprendizado para encontrar um caminho que melhorasse um cenário complexo por meio de novas abstrações.
Nesse cenário de abstrações, organizações podem ser levadas ao erro e comprarem a ideia que certas ferramentas ou caminhos de outras organizações são fundamentais para o seu próprio sucesso, mesmo sem existir a complexidade que tornou necessária aquela escolha.
Dessa forma, a ideia de melhoria imediata acaba sendo uma estratégia muito mais atraente para as equipes, pois não exige a mudança de cultura, nem a mudança de processos. É a diferença de uma competição de maratona para uma corrida de velocidade do atletismo. Apesar da ação mecânica ser basicamente a mesma, o processo é completamente diferente.
Ser DevOps não é apenas possuir uma pipeline de implantação
Essa questão, apesar de parecer trivial para quem está ambientado, costuma ser uma das grandes ilusões de melhoria imediata. Ter uma esteira de implantação não é suficiente para nomear equipes como DevOps.
Toda a ideia das esteiras de implantação é algo explorado antes mesmo da consolidação do termo DevOps. A famosa obra Continuous Delivery (Humble e Farley) já anunciava, em 2010, alguns princípios que entrariam na cartilha da cultura DevOps como automação, testagem frequente, colaboração entre as equipes e responsabilização pelos processos.
Mesmo assim, é comum encontrar o anti-padrão de organizações que possuem esteiras de implantação, mas zero colaboração entre as equipes e as até mesmo a necessidade de acompanhar manualmente execuções automatizadas de processos de implantação.
Esse cenário, na obra de Humble e Farley, já não seria considerado Continuous Delivery e mostra fraca aderência a cultura DevOps. Sem a devida maturidade tecnológica, automações não só falham em remover o risco de erros, mas introduzem novos tipos de risco.
Portanto, ser DevOps exige uma transformação cultural alcançada com a maturidade tecnológica do processo de melhoria contínua, que permite compreender os fluxos, documentar as automações e criar a cultura de responsabilização pelos processos. É difícil conseguir isso de uma forma imediata.
Estar na nuvem não é ser Cloud Native
Aqui, temos outro ponto que parece óbvio, mas que vira um ponto de tensão para muitas organizações - especialmente aquelas que migraram para nuvem recentemente ou estão em processo de migração.
Estar na nuvem é um processo relativamente fácil, considero até mais fácil do que sustentar uma infraestrutura própria atualmente. Migrar para nuvem exige algumas manobras, mas mesmo nesse cenário ter serviços funcionando é relativamente simples com uma maturidade mínima de processos.
Apesar disso, aproveitar os benefícios que costumam ser vendidos por um provedor de Cloud (escalabilidade, confiabilidade, segurança e outros) costuma exigir uma certa adaptação. Tal adaptação é bastante resistente a ilusão da melhoria imediata, pois tende a ser um processo bem iterativo e não uma mudança imediata de paradigma.
Pegar um monolito e jogar na nuvem em um container com a expectativa de ser Cloud Native com todos os acessórios de fábrica é uma das principais ilusões da melhoria imediata. O software não nasce Cloud Native e planejamento é necessário para essa mudança.
Observabilidade não é criar dashboards para a plataforma
Desde que a engenharia de observabilidade começou a ganhar força nas discussões da comunidade, principalmente de SRE, ficou evidente o grande desafio técnico e cultural de processos de observabilidade. Talvez de todos os itens mencionados até agora esse seja um dos que requer maior maturidade cultural de uma organização.
Monitorar uma plataforma, até certo ponto, é relativamente simples, visto que a maioria dos provedores de Cloud já possui algumas integrações básicas para tipos primitivos de monitoramento.
Entretanto, a engenharia de observabilidade surgiu justamente porque a ideia de monitoramento não era suficiente para contextos complexos. A ilusão da melhoria imediata com dashboards é um dos principais pontos cegos de engenharia de observabilidade, não é incomum encontrar plataformas passando por problemas, mas que os dashboards sequer conseguem captar algo errado - incidentes são notificados pelos próprios usuários.
Engenharia de Observabilidade requer aprendizado contínuo, além da necessidade de manter um grau mínimo de colaboração entre os times para conseguir adequar a infraestrutura e o software para um patamar de maior observabilidade.
A observabilidade, até o momento, não é plug-and-play e necessita passar pelo processo de melhoria contínua para se alcançar os objetivos desejados.
O veneno do Argonauta
Algo que a melhoria imediata costuma esconder é a necessidade de rever ideias e processos. A engenharia de software também é vítima de ciclos de hype, mas a melhoria contínua impõe a obrigação de dar dois passos para trás quando for detectada uma direção errada ou um passo maior do que o desejado.
Uma das ferramentas no seu ciclo de hype no mundo de Ops é o Kubernetes. Uma fantástica plataforma de orquestração de container, inspirada no Borg - projeto interno da Google para resolver seus problemas de operação. É inegável que se trata de um dos maiores feitos de engenharia do mundo de operações nas últimas decadas, mas definitivamente não é a chave-mestra para todas as plataformas.
Organizações que nunca cogitaram a clusterização passaram a adotar a ferramenta na expectativa de que leve ao caminho do sucesso em Operações, mais uma face da melhoria imediata. Kubernetes possui fascinantes casos de uso e muitas histórias de sucesso de simplificação de operações, mas requer uma série de cuidados.
Algumas organizações podem fazer uma utilização extremamente básica do Kubernetes - o que por si só causa a reflexão sobre a necessidade da ferramenta como um todo, enquanto outras organizações podem necessitar até de criptografia na rede interna do cluster. Um único tamanho ou única cor de cluster não irá resolver o problema de todas as plataformas.
Em mais de uma ocasião já recomendei a desativação de cluster Kubernetes pelo simples fato de estar introduzindo mais débito técnico do que valor para a plataforma. Acredito que ainda farei isso mais vezes no futuro.
Acreditar que a criação e utilização de um cluster, sem um processo de melhoria contínua, irá imediatamente resolver problemas técnicos e culturais é uma das maiores armadilhas referentes ao k8s.
Alguns casos que compartilham reflexões próximas: O motivo de não usarmos Kubernetes, Kubernetes não combinou com a gente e quem saiu do Kuberentes e o motivo.
A diferença do remédio para o veneno é a dosagem.
A importância da maturidade tecnológica e cultural
A busca da melhoria, sem a respectiva maturidade tecnológica e cultural, pode levar a um aumento significativo de complexidade. Isso porque a ilusão de que ferramentas e práticas de ponta podem ser adotadas sem um processo gradual de adaptação e aprendizado acaba colaborando para o surgimento de problemas e incidentes.
Portanto, a melhoria de plataformas raramente - para não dizer nunca - vem de soluções rápidas, mas de um compromisso contínuo com a evolução tecnológica e cultural. Tal compromisso é algo construído diariamente em equipes e plataformas, através de um processo iterativo de aprendizado, adaptação e refinamento.
O elo mais fraco de uma plataforma é o ser humano que a constrói, pois é uma das poucas partes que não podemos definir com código. Ainda.