“Ops” agora é trabalho para todos

No mês de julho marcou o Sysadmin Appreciation Day. Portanto volte-se para o sysadmin mais próximo e mais querido e não deixe de agradecê-lo pelo trabalho que fazem.

“Ops já acabou“.
“Sysadmins? Isso é tão old school“.
“Todas as equipes de engenharia têm automatizado suas operações“.

Muita gente adora dizer que o Ops está morto. E, com certeza, podemos definir “Ops” como todos os tipos de operações desagradáveis, muitas das quais devem ser eliminadas. Mas isso não seria inteligente nem particularmente útil.

Para Charity Major, Engenheira de Software,

“O ‘Ops’ representa a constelação das habilidades técnicas, práticas e valores culturais de uma organização em torno de sistemas de design, build, escalonamento e manutenção. Ops é o processo de entregar valor aos usuários. E Ops é também onde a dura realidade casa perfeitamente com a teoria“.

“Em outras palavras, Ops é como fazemos as coisas. Não é opcional. Você entrega software, você faz ops. Simples assim. Se o negócio é o ‘porquê’ e o dev é o ‘o que’, Ops é o ‘como’. Estamos todos interligados e todos nós participamos e compartilhamos das competências uns dos outros“, afirma ela, com propriedade, como veremos abaixo.

Como era

Há 20 anos, os engenheiros Ops foram chamados de “sysadmins“, e passamos nosso tempo cuidando com ternura de alguns servidores preciosos. E então veio o DevOps com tudo. O DevOps significa muitas coisas para muitas pessoas, mas uma coisa que inquestionavelmente significava para muitas pessoas costumava ser: “Querido Ops: aprenda a escrever código“.

Foi uma transição difícil para muitos, mas foi uma coisa inequivocamente boa, pois os sysadmins precisavam dessas habilidades! A complexidade estava aumentando rapidamente. Já não era mais possível completar tarefas sem automação, então era mesmo necessário aprender a escrever código. Não era opcional.

Como é hoje

Passaram-se entre 10  e 15 anos desde o início da era da automação, e já estamos bem nos primeiros anos de sua substituição: a era dos sistemas distribuídos.

Considere as tendências predominantes em infraestrutura: containers, schedulers, orquestradores. Microsserviços. Armazenamento de dados distribuídos, persistência poliglota. A infraestrutura está se tornando cada vez mais efêmera e “combinável”, levemente acoplada a redes com perdas. Os componentes estão diminuindo em tamanho enquanto se multiplicam em unidades, por ordens de grandeza em ambos os sentidos.

Em seguida, do lado do cliente: tomemos o celular, por exemplo. A explosão combinatória de (tipos de dispositivo * firmwares * sistemas operacionais * aplicativos) é um salto quântico em complexidade por conta própria. Misture isso com a estratégia de cache distribuído, consistência final, armazenamento de dados que dividem o cérebro entre cliente e servidor, a IoT e a terceirização de componentes críticos para fornecedores externos (que são efetivamente black boxes) e começamos a compreender porque somos todos engenheiros de sistemas distribuídos no presente e futuro próximo.

Toda essa mudança exige outro mindset e abordagem. O dev não está apenas escrevendo código: está construindo sistemas. Os sistemas distribuídos exigem um foco muito maior na operabilidade e na resiliência. Em comparação com os antigos monólitos gerenciados por monitoramento e automação, os novos sistemas exigem novos pressupostos, tais como:

• Os sistemas distribuídos nunca estão “acima“; Eles existem em um estado constante de serviço parcialmente degradado. Aceite a falha, projete para a resiliência, proteja e encolha o caminho crítico;
• Você não pode segurar todo o sistema em sua cabeça; viver ou morrer é algo que dependerá do rigor de suas ferramentas de instrumentação e observação;
• Você precisa registrar e descobrir serviços robustos, de balanceamento de carga e contrapressão entre cada combinação de componentes;
• Você precisa aprender a integrar serviços de terceiros; muitas funções principais serão terceirizadas para equipes ou empresas com as quais você não tem visibilidade ou influência direta;
• Você deve testar na produção, e precisa fazer isso com segurança; você não pode rodar uma cópia de teste em um enorme sistema distribuído.

O que todos esses tópicos têm em comum? São todos características de uma ótima engenharia de operações. E também não são opcionais. Em outras palavras: “Caros engenheiros de software: é tempo de aprender Ops também“.

“Ops” agora é trabalho para todos

Se a primeira onda de transformação DevOps centrou-se no nivelamento de equipes Ops escrevendo código, a segunda onda virou o jogo. Um dev simplesmente não pode desenvolver software de qualidade para sistemas distribuídos sem dar a devida atenção à sua operação, manutenção e capacidade de debug. Não se pode projetar softwares modernos sem um pezinho que seja no Ops.

Esta transformação está bem encaminhada, e a evidência está em todos os lugares – muitos dólares investidos em ferramentas “Ops for Devs“, e o amadurecimento do consenso de que os devs devem compartilhar a visão de engenheiros de software que aparecem em conferências tradicionais de Ops. Até porque o “Ops for Devs” chegou para ficar.

Isso é uma coisa boa! Foi bom para o Ops aprender a escrever código, e é bom para os desenvolvedores aprenderem a possuir seus próprios serviços. Todas essas mudanças levam a um melhor software, e a um acompanhamento mais apurado também, bem como práticas mais robustas em face de uma complexidade ainda explosiva.

Fonte: opensource.com

Gostou do conteúdo? Tem alguma dúvida? Entre em contato com nossos Especialistas Mandic Cloud, ficamos felizes em ajudá-lo.