Muitas e muitas vezes me envolvi em discussões sobre responsabilidades sobre serviços de suporte e tudo que está ao redor das nossas aplicações, como Proxy Reverso, API Gateway, Cache Server, Mensageria, Vault, Plataforma e por aí vai.
Afinal, quem é o Owner dessas tecnologias e ferramentas?
Será que são de responsabilidade da galera de Operações?
Spoiler: Essas tecnologias fazem parte do produto, estão nos aspectos não funcionais dele, mas não deixam de fazer parte dele, portando são da equipe constrói o produto. E, portanto, estão muito mais próximos da jornada do Arquiteto do que da jornada de Ops.
Hoje compartilho minha visão e meus argumentos. Esse post é parte de uma sequência que demonstrará como economizei mais de 1 milhão de reais em infraestrutura nos últimos 4,2 anos.
Não há novidades aqui…
Em 2002 quando entrei no mercado, tive como meu primeiro emprego a petrobras. Eu entrei como dev junior em 1° de julho de 2002, completando semana passada 21 anos de carreira profissional como dev.
Logo nos primeiros dias notei a divisão dos times. Um time muito peculiar cuidava dos padrões de desenvolvimento, da arquitetura, e da forma como desenvolvíamos software.
Esse time também gerenciava os servidores não produtivos (servidores que não são de produção).
A equipe de infraestrutura provia hardware, servidor disponível, e updates do sistema operacional, mas era o time de arquitetura que cuidava de toda a configuração das aplicações, serviços e tudo mais que aplicações ASP e mais tarde ASP.NET precisavam.
Desde detalhes do IIS até permissões, libraries instaladas no servidor via COM ou GAC tudo isso em ambientes de Desenvolvimento, Testes e Homologação era responsabilidade da equipe de Arquitetura. Essa equipe era uma equipe que residia do lado DEV.
Nessa jornada até chegar ao time de arquitetura, era óbvio que eu precisava evoluir meus skills de infra. Era necessário entender como nossas aplicações se comportavam, também como otimizar configurações. Ficou claro que era preciso sentir conforto com esses aspectos mais de infra para talvez até conseguir ajudar, pelo menos com tarefas mais operacionais.
Não levou muito tempo, para descobrir que:
Uma vez que você tem domínio e controle
sobre onde e como sua aplicação roda,
você ganha superpoderes.
Conhecer onde sua aplicação roda, permite construir software mais eficiente e robusto, usando melhor os recursos disponíveis, evitando reinventar rodas, evitando gambiarras, entendendo o efeito das mudanças de comportamento decorrente das principais configurações.
Nessa jornada de 8 meses, foi muito fácil perceber que fazíamos coisas erradas, muitas vezes até por direcionamento errado dos seniores da equipe. Contornávamos comportamentos causados pela ausência de configuração específica, por total desconhecimento. Era comum encontrar implementações que reinventassem uma roda qualquer, visto que ao não conhecer bem a plataforma, tentava-se contornar um comportamento padrão.
Gastávamos semanas para entregar algo meia-boca, entretanto, se feito da forma certa, custaria apenas 1 clique, e talvez alguma reunião para explicar a necessidade, no máximo.
O não conhecimento cobra pedágio!
Ops é uma parte chata, que pode se tornar divertida!
Para quem é dev, infraestrutura pode parecer chato. Entretanto, quando você aprende a domar uma tecnologia, de tal forma que se sente totalmente confortável, ao ponto de considerar ridiculamente previsível, entendendo quais parafusos apertar para obter cada comportamento, o jogo muda. O que era chato, se torna um aliado para entregar mais com menos.
Trata-se de entender que, se você domina a tecnologia, você se sente confortável em usar mais dela, em realizar um uso mais profissional, mais profundo. Aquilo que parecia chato, se torna divertido, porque você encontra sentido lógico em cada comportamento diferente, de acordo com cara situação, de acordo com cada configuração.
Lidar com Uptime de servidor, com Redes, detalhes de Disco, é a parte brutalmente chata, e nunca será divertida. Essa é a parte totalmente Ops da solução.
É a parte que delegamos para quem gosta de hardware (infra).
E não somos nós.
A parte divertida, é a configuração do IIS, recursos avançados do Windows. É aqui que nossos skills de dev se conectam aos fundamentos e entregam enorme resultado. É aqui que só um bom dev tem conhecimento para diagnosticar o que melhor entrega resultado para o projeto e para o que quer entregar com sua aplicação. Entender bem o produto, é fundamental.
Vale lembrar que na visão da Microsoft o Windows é o Servidor de Aplicação e seus componentes e recursos, incluindo o IIS, são extensões desse servidor de aplicação.
Nesse paradigma, era importante entender proccess activation, port sharing, setup do windows server, incluindo os principais recursos, extensões e configurações do IIS, incluindo o domínio sobre os app pools.
Embora muitos devs tenham fugido desse know how, esse é um conhecimento que nunca pudemos nos eximir da responsabilidade.
Quem se eximiu, se limitou, e limitou suas possibilidades de atuação e limitou sua capacidade de resolver problemas e ser eficiente no seu trabalho.
Quando evitamos esse conhecimento, abdicamos de sermos especialistas!
Não há especialista em WEB com .NET (no windows), sem esses conhecimentos!
A vida é cruel e simples assim!
Com o Kestrel, ficou mais claro de quem é a responsabilidade por esse conhecimento.
Agora está embarcado no seu projeto .NET, e as configurações estão comitadas no seu GIT, junto com o projeto.
Embora criação do Kestrel, inspirada no NodeJS, tenha nascido em 2014, antes disso, como uma forma de me manter conectado às evoluções da plataforma, eu já hospedava meus blogs e sites em VPS’s Windows. Fiz isso de 2008 a 2013.
Era uma forma de me manter próximo ao windows server o suficiente para não esquecer. Desde a Petrobras em 2003 estava claro que domar o básico do Windows Server e chegar a certo nível de profundidade no IIS, seria útil para a carreira, porque, como disse:
Dev com fluência em infra ganha superpoderes.
Em 2013 fui surpreendido com falhas de segurança nessa stack, e tive meu wordpress invadido. Por descuido, ignorância, ou simplesmente por prazer, o atacante tirou meu site do ar, que virou um peso de papel digital.
Bons ataques mantêm seus serviços funcionais,
de tal forma que passam despercebidos,
como parasitas.
Como eu já contei algumas vezes, ao projetar a nova arquitetura do backoffice do iMusica em 2013, me deparei com a necessidade direta de lidar com os servidores do time que eu gerenciava, e no processo de reestruturação da aplicação precisei de serviços que só podiam ser hospedados no Linux.
Se você se assusta com a ideia de alguém com skill de dev cuidando de infra, calma.
A dinâmica é bem simples:
Ops/Infra cuidava de UPTIME, DISCO, UPDATES, REDE, FIREWALL.
Já a respeito de minha aplicação, serviços de apoio, serviços de suporte, e tudo que minha aplicação precisar, é de minha responsabilidade, é assim que trabalho.
E se você é arquiteto, considere, ao menos por alguns minutos, adotar essa estratégia.
O preço de delegar a gestão e configuração dos serviços que atendem sua aplicação é ter de lidar com decisões tão amadoras quanto importantes, de tal forma que atrapalharão o funcionamento da sua aplicação.
Se você entende que o típico profissional de Ops não conhece com tanta profundidade RabbitMQ, Redis, MongoDB, Elastic, Kibana, Kafka, Kong, Docker, Kubernetes, Postgres. Entende o tamanho do risco.
Talvez já deva ter notado que na maioria das vezes esse profissional de Ops terá seu primeiro contato essas tecnologias, apenas após a solicitação de setup. Isso é um pouco tarde. Ele precisará de alguns dias lendo documentação, lendo blogs, etc para conseguir formular uma visão superficial, míope ainda do assunto.
Muitas vezes ele entenderá o mínimo para construir o ambiente mais básico possível, sem considerar muitos dos aspectos e conhecimentos que só a experiência ajudará.
Experiência não se faz download.
Conhecendo esse comportamento você perceberá o tamanho do risco que está tomando para o projeto e em algum nível para si.
Ao compreender esse risco:
- Ou você aceita o risco e convive com as consequências
- Ou contrata um serviço gerenciado
- Ou contrata um especialista
- Ou assume a responsabilidade
- Ou aborta a utilização da tecnologia.
Eu optei, como uma estratégia de carreira pela estratégia 4.
Na minha visão de mundo, a responsabilidade é MINHA,
e se outro executa, é porque estou DELEGANDO,
mas a responsabilidade continua sendo minha.
Assumir para mim a responsabilidade, me dá a segurança de ter total controle sobre uma das variáveis que mais vi fazer projetos capotarem: Problemas de Clareza, Comunicação e Skill entre Infra e Dev.
Gosto de usar esse skill para ser o cliente “chato”, que sabe exatamente, precisamente, que faz solicitações meticulosas com critérios de aceite específicos e claros. Por saber o que precisa ser feito, como precisa ser feito, porque precisa ser feito, quais os impactos e quais parafusos apertar. Na pior das hipóteses, se necessário, em casos excepcionais, eu mesmo aperto esses parafusos para obter o resultado que eu quero.
A tecnologia precisa trabalhar para mim!
e a recíproca não é verdadeira!
Com essa abordagem consigo projetar e executar meus workloads sem surpresas, sem emoções desnecessárias.
Exige conhecimento e esforço, mas uma fez adquiridos, se torna mais simples.
No Windows sempre que via um profissional de Ops/Infra perdido apertando botões aleatoriamente no IIS “para ver se resolvia”, me doía o coração (para não dizer outro lugar).
Sobre IIS qualquer Arquiteto .NET tinha a obrigação de saber o que acontece com cada flag configurada no AppPool ou no IIS e WebConfig produzia de efeito em sua aplicação.
Já um profissional de Ops, em geral, não tinha esse domínio, simplesmente porque não precisava.
No final das contas tudo se resolvia em Salas-de-Guerra (WarRoom), depois de muito stress, muita gente frustrada, incluindo o cliente e bem provavelmente até o usuário final.
Esse não é um modelo eficiente.
Conclusão
Em suma, a interseção entre desenvolvimento e infraestrutura é crucial para maximizar a eficácia de um software. Quando os desenvolvedores entendem e controlam onde e como suas aplicações funcionam, eles ganham a capacidade de criar soluções mais eficientes, robustas e de melhor desempenho.
Ao abraçar a responsabilidade por aspectos antes deixados para as equipes de Operações ou Infraestrutura, os desenvolvedores podem impulsionar um entendimento mais profundo de como suas aplicações se comportam em diversos ambientes e situações. Isso não apenas ajuda a otimizar o desempenho, mas também economiza tempo e recursos valiosos ao evitar soluções alternativas desnecessárias e reinvenções da roda.
Da mesma forma, estar ciente dos aspectos mais operacionais e de infraestrutura do software proporciona uma vantagem inestimável para qualquer desenvolvedor ou arquiteto. Torna-se mais fácil identificar os problemas mais cedo, prevê-los antes que aconteçam, e entregar soluções mais estáveis e de alta qualidade.
Por fim, não se trata de substituir ou desvalorizar o papel vital que as equipes de Operações ou Infraestrutura desempenham. Ao contrário, trata-se de romper os silos e encorajar uma maior colaboração e compartilhamento de conhecimento entre as equipes de Dev e Ops. Isso, por sua vez, beneficia a todos: os desenvolvedores, as equipes de operações, e, o mais importante, o produto final e os usuários.
Em outras palavras, é hora de abraçar o conceito de DevOps em sua totalidade. Porque, no final das contas, não há “eles” ou “nós” quando se trata de entregar um produto de alta qualidade. Há apenas “nós”.
Excelente conteúdo Luiz, concordo em grande parte do que você expos. Apesar de hoje ainda ser meio “cinza’ essas responsabilidades, estão bem mais claras que no passado.