Ao lado de Containers, Microsserviços e Entrega Contínua, DevOps está no alicerce do Cloud Native. Hoje desmistificaremos DevOps e espero acabar de uma vez por toda com essa ideia de que é coisa de infra.

Antes de começarmos, preciso recorrer à sua própria memória recente. Preciso que você faça uma lista mental das empresas e projetos mais famosos do momento, ou aquelas vagas que gostaria de se candidatar, talvez tenha se candidatado, e tudo aquilo que você tem buscado e visto no LinkedIn.

Se você não tem essa memória, sugiro que você vá ao LinkedIn ou sites de vagas e busque as “vagas dos sonhos”. Deixe a imaginação guiar suas buscas, e se permita sonhar com uma vaga com mais skills do que você tem.

Esse meu pedido tem somente uma finalidade. Trazer para o consciente, caso já não esteja, de que não adiante reclamar, espernear, sequer ficar chateado faz sentido. É hora de arregaçar as magas porque DevOps, é apenas mais uma skill do dev. Pelo menos se você quer furar da bolha dos baixos salários e alta concorrência.

A concorrência de quem só coda

Se sua única habilidade é escrever código, você está em uma bolha onde os salários são significativamente mais baixos. Isso acontece porque igual a você, existem dezenas de milhares de outros devs. Quanto mais comuns forem seus skills, menor será seu salário, já que tem muita gente que queira fazer o seu job, possivelmente até melhor que você, potencialmente até cobrando menos.

É uma questão clara de concorrência.

Ao mesmo tempo, alguém terá de realizar o “papel do DevOps”, já que você não tem essa habilidade. Portanto você não é um dev completo que cumpre todas as etapas do desenvolvimento à produção. Você é apenas parte de uma esteira que depende de outras pessoas. Esse é mais um motivo para você ganhar menos.

DevOps é coisa do DevOps?

Definitivamente, DevOps não é um cargo, uma função ou uma pessoa. Mas ok, eu entendo perfeitamente que o mercado criou esse cargo, eu vou abordar isso ainda nesse texto.

DevOps é uma forma de encarar as responsabilidades no ciclo de vida de desenvolvimento e entrega de software.

Manifesto DevOps

Esse é o manifesto DevOps

DevOps não é…

• Uma certificação
• Um papel
• Um conjunto de ferramentas
• Um processo prescritivo

DevOps é…

• Uma filosofia que começa com paixão
• Um movimento cultural, profissional com atitude e valores
• Uma reação à má comunicação
• Sobre como criar visibilidade entre desenvolvedores e operações
• Sobre a relação simbiótica entre dev e ops
• Equipes multifuncionais sobre silos organizacionais
• Produtos não projetos
• Automação sobre documentação (e mais automação… e mais…)
• Sobre a criação de infraestrutura de autoatendimento para equipes
• Saber que um bom software não termina com desenvolvimento/lançamento
• Software que não requer suporte
• Garantir um ciclo de feedback contínuo entre desenvolvimento e operações
• Equipes multifuncionais sobre silos organizacionais
• Criação de produtos que são de propriedade da equipe de entrega
• Saber que um projeto só é finalizado quando é retirado da produção
• Algo que você pode fazer sem fazer ágil

O que queremos alcançar

• Operações e desenvolvimento são habilidades, não funções. As equipes de entrega são compostas por pessoas com todas as habilidades necessárias.
• As equipes de entrega executam produtos de software – não projetos – que são executados desde o início até a aposentadoria

Porque DevOps é tão necessário?

Contexto

Uma das coisas que aprendi no período em que trabalhei na Petrobras era que quem dominava não só como seu código rodava, mas o que estava ao redor dele como infra e banco tinha uma vida muito, mas muito mais serena e tranquila. Tinha uma vida de relativa paz!

Ao longo desses 20 anos eu sequer consigo contabilizar quantas vezes presenciei o desalinhamento entre Infra, Desenvolvimento, Banco e Arquitetura, gerando custos absurdos desnecessários.

Custo por alocação errada de recursos: aplicações precisavam mais do que a infra disponibilizava, porque alguém julgava que a aplicação precisava de X, mas, na verdade, precisava de X+Y ou 2X.

Produtos desenvolvidos sem o conhecimento do próprio consumo de banco de dados, disco, CPU, memória. Faltando de conhecimento de como serviços de infraestrutura como Object Cache, HTTP Cache, Mensageria, poderiam mitigar e resolver graves problemas na experiência do usuário e na redução de consumo de infra.

A quantidade de projetos que vi atrasar porque gente ficou presa em atividades específicas, sem pedir ajuda, tentando resolver o que sequer era competência dela. Coisas bobas como CORS, ou o uso de sessions em memória, causando custos desnecessários.

Em um dos meus últimos projetos no mercado, que diga-se de passagem, foi um fiasco, encontrei um time de uma das maiores seguradoras do país. Sem nenhum conhecimento específico sobre contêineres, orquestração de contêineres, docker, Kunernetes, planejando enorme de implantação on-premise baseada em Windows server. Tudo isso com a intenção de rodar contêineres Linux em produção.

Quantas e quantas vezes você já não viu discussões a respeito da responsabilidade sobre um problema? Infra diz A, dev diz B. E ambos não se entendem, enquanto na realidade, ambos estão certos e errados.

O cargo DevOps

Na prática, com o passar dos anos tentamos suprimir a falta de especialistas no mercado criando cargos para funções mais estratégicas. O que no passado era papel de um desenvolvedor profissional, com o passar dos anos foi fragmentado em diversos cargos. Cada qual foi ficando cada vez mais complexo e profissional.

Assim nasceu:

Arquiteto de Soluções: Estrategista técnico, profundo conhecedor de ferramentas e estratégias que reduzem o escopo de diversos softwares e orquestra a adoção de tecnologias centralizadas (ou não) que reduzirão o escopo de diversas soluções.

Arquiteto de Software: Estrategista técnico, profundo conhecedor da plataforma, capaz de orquestrar a comunicação e decisões técnicas visando otimizar o esforço empenhado no desenvolvimento, reduzindo custos e otimizando a capacidade produtiva dos desenvolvedores.

Arquiteto de Infraestrutura: Estrategista técnico, profundo conhecedor de infraestrutura, capaz de orquestrar a comunicação e decisões de infraestrutura visando entregar os melhores recursos no menor custo, com a maior segurança.

Arquiteto de Banco: Estrategista técnico, profundo conhecedor de bancos de dados, com o papel de prover a melhor estratégia de armazenamento e acesso aos dados armazenados durante o ciclo de vida da aplicação.

DevOps: Operacional, técnico capaz de orquestrar a execução entre os recursos de dev e ops, sabendo lidar com infraestrutura em conjunto com a aplicação. Responsável por pipelines, otimização do processo de criação de recursos, definição de padrões que não ofendam a infraestrutura.

Essas são descrições simplistas, daquilo que originalmente um dia foi papel do dev. Todos esses cargos, hoje, no dia-a-dia, ganharam atribuições mais específicas e mais profundas.

Se você olhar com certo cuidado, verá que estamos diante de muitos conhecimentos distribuídos em diversos cargos/funções. Esse tal desenvolvedor com todos esses conhecimentos, simplesmente não existe. E assim verticalizar essas skills em funções e cargos se fez necessário para que todas essas áreas pudessem ser endereçadas.

O último dos cargos/funções a serem criados no mercado foi o de DevOps e tende a ser a mais controversa.

O que faz o mercado precisar de DevOps?

Na medida que as demandas do mercado mudam, microsserviços ganha força e tração, e a separação rígido de responsabilidades entre Dev e Ops faz cada vez menos sentido. Um ma nova abordagem ganha força.

No mundo Ops, é muito mais comum o convívio com as gambiarras, com a falta de automação. Pelo menos era assim no passado. O dev tem como premissa a resolução de problemas, a identificação de padrões, a busca por reaproveitamento e evitar a todo custo o trabalho repetitivo.

Essas são características que fazem do dev tão especial quando falamos de DevOps, e somando isso à habilidade de escrever código, faz com que DevOps seja um campo muito mais próximo do Dev do que do Ops.

Os novos projetos precisam muito mais de automações, precisam de aplicações que usem muito mais recursos dos mais variados que estão muito ligados a infraestrutura. Há questões que envolvem não só implantação, mas escala, velocidade de entrega e tudo isso em um desenho onde a comunicação custa mais que a execução, com uma taxa de acerto não tão boa assim torna óbvia a necessidade de algo diferente.

DevOps, como citei no manifesto, é uma forma de pensar. Uma forma de encarar as responsabilidades, enxergar o projeto como um produto. E fazer parte de seu ciclo, visando evitar ao máximo a interação humana, promovendo mais automação, gerar mais feedback com observabilidade e gerência de configuração, por exemplo.

É uma resposta para esse novo estilo de software que, agora, depende umbilicalmente desses conceitos.

E por isso DevOps é um dos 4 pilares do Cloud Native. Em conjunto com Microservices, Entrega Contínua e Containers, produzindo um ecossistema completo com as fundações e skills necessários para contemplar as novas arquiteturas, mais distribuídas, mais automáticas, que entregam mais valor, e do ponto de vista do usuário final, não caem, e “beiram o indestrutível”.

Do lado de dentro a gente sabe que não é assim, mas isso é papo para outro post.

No próximo post

No próximo post da série vou abordar como Containers e cloud native andam tão próximos…