Nesse texto irei trazer algumas coisas que demorei a aprender na trilha que segui de desenvolvimento de software, talvez por não ter seguido um caminho mais “tradicional”, ou talvez porque não se vê tantos holofotes/clickbaits sobre esses assuntos para quem escolheu o caminho de transformar café em código.

Quantos blogs sobre a melhor forma de usar a memória na tecnologia X você já viu? Um vídeo sobre melhor estrutura de dados para o problema Y? Alguém falando no passarinho azul que você deveria prestar atenção nas melhorias assintóticas?

Mas quantos falam sobre confiabilidade? Ou sobre maximizar o retorno sobre o investimento? Que te ensinam a transformar o seu ambiente para que todos trabalhem focados em entregar valor?

Talvez o que tenha me levado a ser um programador um cado melhor não foi saber extrair até a última gota de suco que um framewok pode dar, talvez tenha sido algo mais simples, talvez até mais obvio, talvez tenha sido o fato de eu ter aprendido que devemos resolver o problema considerando a perspectiva do usuário/cliente e a perspectiva de quem paga para manter o sistema de pé.

Aqui entra o kit de ferramentas que no início costumamos deixar para trás, e, estranhamente, depois temos um certa resistência em voltar para buscar esse tal kit, ou simplesmente, talvez por conta de como a mídia/mercado lida com ele, não damos a devida atenção, apesar disso, esse kit é o que traz a transformação. Aqui entram as ferramentas que vem com a cultura DevOps, as práticas de SRE e os princípios do FinOps.

A cultura DevOps

Muito se fala em DevOps, mas colocar toda a teoria em pratica não é trivial. Você facilmente verá vagas DevOps que estarão pedindo conhecimentos em alguma FERRAMENTA de CI/CD, FERRAMENTA disso e FERRAMENTA daquilo. Talvez por isso que essa “cultura”, quase que ironicamente, tem ficado distante do mundinho das pessoas desenvolvedoras, onde muitas vezes ainda se joga o pacotinho por cima do muro e o detentor do conhecimento sobre a FERRAMENTA de sustentação que acaba ficando com a carga da operação.

O DevOps até pode ser isso sim, todavia, como cultura, deve ajudar a alinhar pessoas, processos e ferramentas para um foco mais direcionado ao cliente. Como cultura, não deve ser de um time, não deve ser de uma pessoa. Você, todos os dias, pode praticar essa cultura, você pode ser a pessoa que está em busca de aumentar a transparência, a comunicação e a colaboração.

Algumas das principais práticas de DevOps incluem:

• Colaboração: DevOps enfatiza a necessidade de as equipes trabalharem juntas de forma integrada, quebrando silos e promovendo uma cultura de colaboração entre os departamentos.

• Automação: DevOps enfatiza o uso de ferramentas e processos de automação para agilizar o desenvolvimento, teste e implantação, reduzindo a probabilidade de erro humano e melhorando a eficiência.

• Integração Contínua: DevOps promove a integração contínua de alterações de código, permitindo que as equipes detectem e resolvam problemas no início do processo de desenvolvimento.

• Entrega contínua: o DevOps enfatiza a importância da entrega contínua, permitindo que as equipes lancem software com rapidez e confiança.

• Continuous Deployment: DevOps promove o uso de continuous deploy, permitindo que as equipes liberem alterações de código de forma automática e contínua, sem a necessidade de intervenção humana.

• Teste: DevOps enfatiza a necessidade de testes completos durante todo o ciclo de vida do desenvolvimento de software, garantindo que o software seja confiável, seguro e de alta qualidade.

• Monitoramento: o DevOps enfatiza a importância do monitoramento de software na produção, permitindo que as equipes detectem e resolvam rapidamente os problemas à medida que surgem.

• Segurança: DevOps coloca uma forte ênfase na segurança em todo o ciclo de vida do desenvolvimento de software, garantindo que o software esteja seguro e protegido contra ameaças potenciais. (DevSecOps é quase um pleonasmo)

• Aprendendo com as falhas: DevOps promove uma cultura de aprendizado e melhoria contínua, incentivando as equipes a aprender com as falhas e fazer melhorias iterativas ao longo do tempo.

• Melhoria do trabalho diário: DevOps incentiva as equipes a melhorar continuamente seus processos de trabalho diários, buscando maior eficiência e eficácia em todos os aspectos do ciclo de vida do desenvolvimento de software.

Referências:

Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations

The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations

The Phoenix Project: A Novel about It, Devops, and Helping Your Business Win

The Unicorn Project

As práticas de SRE

SRE vai no mesmo caminho de DevOps, dado que o próprio Google inicia o livro com class SRE implements interface DevOps não seria surpresa esse caminho, contudo não se trata de manter FERRAMENTAS de observabilidade ou FERRAMENTA XPTO, tampouco pra ser a operação com uma nova roupagem. SRE emerge das práticas de engenharia para mudar todo o ciclo de vida de desenvolvimento de sistemas (SDLC). No kit de ferramentas de SRE você vai ter o seu usuário/cliente no centro da discussão. Você vai aprender que a esperança não é uma estratégia, então, com isso, você precisa responder a seguinte pergunta:

Com que seus usuários/clientes se importam?

Se você não tem esse resposta, não adianta nenhum código, não adianta nenhuma metodologia ágil hypada. Sem essa resposta é tiro no escuro. Em suma, aqui você vai adquirir ferramentas para construir o projeto confiável e manter-lo saudável em produção.

SLA

Se alguma demanda chegou para ser feita sem que fique claro a volumetria, tempo máximo que uma operação pode ser executada e quantidade de erros máximos tolerados (existem muitos outros SLIs para seus SLAs, mas não é o foco aqui), provavelmente não estamos com um SLA bem definido, ou seja, provavelmente não estamos nos esforçando para ter uma métrica que corresponda, mesmo que de forma imprecisa, a satisfação do nosso usuário/cliente. Sem SLA não estaremos prontos para criar mecanismos de defesa(SLO) para que os problemas não impactem negativamente a receita.

Algumas das principais práticas do SRE incluem:

• Objetivos de nível de serviço (SLOs): defina objetivos claros e mensuráveis para a disponibilidade, latência e desempenho de seus sistemas.

• Orçamentos de erro: Use SLOs para definir orçamentos de erro, que definem o nível aceitável de degradação do serviço que pode ocorrer sem afetar os usuários.

• Automação: Automatize o máximo possível para reduzir o risco de erro humano e melhorar a confiabilidade.

• Monitoramento: Monitore seus sistemas continuamente para detectar e diagnosticar problemas rapidamente.

• Resposta a incidentes: Desenvolva um processo de resposta a incidentes claro e bem documentado para minimizar o tempo de inatividade e mitigar o impacto das falhas.

• Revisão pós-incidente: Conduza revisões completas pós-incidente para identificar as causas principais das falhas e evitar que elas ocorram novamente no futuro.

Referências:

Engenharia de Confiabilidade do Google: Como o Google Administra Seus Sistemas de Produção

The Site Reliability Workbook: Practical Ways to Implement SRE

Seeking Sre: Conversations about Running Production Systems at Scale

Database Reliability Engineering: Designing and Operating Resilient Database Systems

Microsserviços Prontos Para a Produção: Construindo Sistemas Padronizados em uma Organização de Engenharia de Software

Os princípios do FinOps

É uma prática comum no mercado que a gestão do custo da nuvem seja centralizada em uma área. Essas informações de custo são passadas ao setor financeiro, que tenta se manter atualizado sobre o custo dos próximos meses da nuvem.

Assim como na era Dev vs Ops, já ficou claro que essa fluxo não é sustentável, precisamos nos conscientizar que nossas aplicações são (ou deveriam ser) da responsabilidade de quem constrói, lembra “you build it, you run it”?, então por que a responsabilidade sobre custos e de como maximizar o retorno sobre o investimento não deveria ficar com quem desenvolve?

Mudança cultural

Existe toda uma jornada FinOps para ser aplicada, e assim como DevOps, também há uma barreira cultural. FinOps trata de remover silos e bloqueadores, capacitar os times de engenharia para fornecer melhores recursos, aplicativos e migrações com mais eficiência; também traz uma conversa multifuncional sobre onde e quando investir, deixando claro para todos porque estão tomando essas decisões.

Aqui estão alguns dos princípios-chave do FinOps:

• Responsabilidade: Cada equipe e indivíduo deve ser responsável pelos custos que incorrer.

• Responsabilidade: Equipes e indivíduos devem ser responsabilizados por seus gastos e devem ter visibilidade do impacto de suas decisões no orçamento geral.

• Proatividade: é importante identificar e resolver possíveis problemas de custo antes que eles se tornem um problema.

• Eficiência: Otimize os gastos usando os recursos mais econômicos e eliminando o desperdício.

• Transparência: tornar os custos visíveis e compreensíveis para todos na organização.

• Colaboração: promova a colaboração entre as equipes para garantir que os custos sejam gerenciados de forma eficaz em toda a organização.

Referências:

FinOps Foundation — What is FinOps?

AWS Cloud Financial Management

Cost Optimization Pillar — AWS Well-Architected Framework

Extreme programming (XP) [bônus]

XP é uma metodologia ágil de desenvolvimento de software que se concentra na entrega rápida e contínua de software de alta qualidade. A metodologia XP enfatiza que o software atenda às necessidades do cliente e seja desenvolvido de forma eficiente. A metodologia XP já está meio fora de moda, eu sei, mas justamente por isso que escolhi colocá-la nessa lista. Pra tentar mostrar que quase todas as soluções, em algum ponto, passam pelo cliente.

Práticas da XP:

• Cliente presente: O cliente está envolvido no processo de desenvolvimento do início ao fim, trabalhando de perto com a equipe de desenvolvimento para garantir que o software atenda às suas necessidades.
• Comunicação constante: A comunicação é uma parte essencial do XP, com desenvolvedores trabalhando em pares e se comunicando regularmente com o cliente para garantir que os requisitos do projeto sejam compreendidos.
• Desenvolvimento iterativo e incremental: O desenvolvimento é feito em pequenas iterações, com cada iteração resultando em um software funcional que pode ser testado pelo cliente.
• Testes contínuos: A equipe de desenvolvimento escreve testes automatizados para cada parte do código, garantindo que o software seja testado continuamente.
• Integração contínua: As atualizações de código são integradas continuamente ao projeto principal, permitindo que a equipe de desenvolvimento monitore as alterações e corrija quaisquer problemas que surgirem.
• Design simples: O design do software é mantido simples e fácil de entender, com a equipe de desenvolvimento se concentrando em criar um software funcional em vez de recursos complexos.
• Refatoração de código: O código é continuamente refinado e melhorado para garantir sua qualidade e manutenibilidade.
• Propriedade coletiva do código: Todos os membros da equipe têm responsabilidade pelo código, permitindo que qualquer pessoa faça alterações e melhorias quando necessário.
• Entrega contínua: O software é entregue regularmente em pequenos incrementos, permitindo que o cliente teste e forneça feedback sobre o produto em tempo hábil.

Conclusão:

Devemos lembrar que a programação é uma forma de resolver problemas, e não um fim em si. Se ficarmos presos na obsessão pela otimização prematura e pelo conhecimento técnico detalhado, podemos perder de vista o objetivo principal: entregar valor para o usuário/cliente. As práticas DevOps, SRE e FinOps podem nos ajudar a manter o foco nesse objetivo, trabalhando em equipe, criando soluções eficientes e com custos controlados.

Por fim, gostaria de deixar um último pensamento:

“O software é uma arte. É algo que requer habilidade, paciência e dedicação. É um processo contínuo de aprendizado, erro e correção. E acima de tudo, é um processo colaborativo, que exige a contribuição de muitos para alcançar o sucesso.” — Linus Torvalds

Espero ter contribuído com algumas ideias para a sua jornada como pessoa desenvolvedora. Lembre-se sempre de manter o foco no usuário/cliente, trabalhar em equipe e buscar o aprendizado constante. E acima de tudo, não se esqueça de tomar um café de vez em quando para manter as ideias fluindo!