Empresas estão cada vez mais se voltando para o DevOps para apoiar as suas transformações digitais
No começo, havia o código, e os desenvolvedores eram responsáveis por tudo. Eles criaram a lógica e a mantiveram em execução nos servidores, mas isso mudou com a expansão e a diferenciação das equipes. Alguns profissionais permaneceram com o código (devs) e outros acabaram cuidando das máquinas (ops).
Atualmente, graças à nuvem e à ascensão dos microsserviços, o software se tornou uma constelação de dezenas e até milhares de componentes rodando em máquinas separadas. Cada um é tecnicamente independente, mas todas essas máquinas devem trabalhar juntas.
A principal tarefa da equipe de DevOps é fornecer toda a orquestração desses aplicativos multifacetados. Eles podem não lidar com a profundidade da arquitetura do software, mas mantêm as peças em funcionamento.
A função é relativamente nova, com responsabilidades que não estão claramente definidas e conjuntos de habilidades que ainda estão em evolução.
Alguns profissionais de DevOps abrangem diversas tarefas, executando uma mistura de programação e operações. Felizmente, muitas equipes estão descobrindo que manter todos os servidores funcionando é suficiente. À medida que mais organizações recorrem ao DevOps para apoiar as suas transformações digitais, é importante ter uma visão clara sobre o assunto.
Confira algumas verdades ocultas e conceitos errôneos que têm sido amplamente divulgados.
Muitos pensam que o DevOps não faz programação – e eles estão certos. As funções divergiram, e grande parte do trabalho de lidar com bytes e estruturas de dados hoje é atribuído a desenvolvedores que vivem em um mundo diferente. Estrategicamente, faz sentido isentar os programadores da responsabilidade de manter tudo em funcionamento, porque as suas mentes estão perdidas no meio de toda a abstração. Mas os membros da equipe de DevOps ainda precisam escrever trechos de código e pensar abstratamente sobre estruturas de dados ocultos. Manter tudo funcionando requer inúmeras linhas de comando, mas que geralmente podem ser coletadas e simplificadas.
Leia também na IT Trends
Mesmo que os profissionais de DevOps não escrevam códigos, eles acabam gerenciando os programadores – e isso geralmente dá muito trabalho. Cada desenvolvedor está criando algo novo e deseja colocar o seu contêiner em produção imediatamente. O código funciona sem problemas? Eles acham que sim. Mas tudo isso pode desabar? Garantir que os desenvolvedores não atrapalhem é trabalho o DevOps.
Quando o software era monolítico, os programadores tinham todo o controle. Agora que os aplicativos geralmente são divididos em dezenas ou mesmo centenas de microsserviços, o DevOps é responsável por quão bem eles são executados. Sim, ainda existem arquitetos e programadores que tomam decisões sobre a maneira como os serviços são vinculados, mas os profissionais de DevOps são responsáveis por como eles são vinculados, o que os torna uma peça cada vez mais importante do quebra-cabeça.
Os provedores de nuvem eram inteligentes quando avaliavam as suas máquinas em centavos por hora. Mas os centavos aumentam conforme o número de instâncias da nuvem cresce e as horas passam. Há 720 horas em um mês de 30 dias e, portanto, uma máquina que custa apenas US$ 1 por hora custará US$ 8.760 em um ano. De repente, comprar o seu próprio sistema começa a parecer mais barato. Após receberem faturas chocantes, algumas equipes estão buscando auditores de DevOps para o trabalho de vasculhar as máquinas, procurando maneiras de economizar dinheiro. Eles examinam as decisões e barram as ideias que extrapolam o orçamento.
O trabalho de gerenciar serviços em nuvem é dificultado pelo fato de a equipe de DevOps frequentemente possuir apenas algumas alavancas que podem ser utilizadas. Depois que os programadores confirmam o código e constroem os contêineres, o trabalho da equipe de DevOps é colocá-los em execução. Se estiverem lentos, podem tentar adicionar mais CPUs virtuais ou mais RAM.
Uma das questões mais profundas é que os computadores estão sempre encobrindo os seus erros. Certa vez, herdei uma coleção de contêineres que travavam a cada poucas horas. Talvez tenha sido uma falha na conexão com o banco de dados. Talvez tenha sido um parâmetro mal configurado. Eu nunca descobri a resposta. O Kubernetes teve a gentileza de inicializar outra instância, respondendo a consultas e executando o seu trabalho. Foi um belo exemplo de arquitetura à prova de falhas, mesmo que estivesse uma bagunça por dentro.
Às vezes, embaixo da superfície, os contêineres e instâncias estão desestruturados. Mas enquanto os usuários e os clientes estão desfrutando do trabalho, geralmente acaba sendo mais fácil ignorar toda a demolição virtual.
Podemos mexer com todo o código interno, mas no final, todos os dados encontram um lar no banco de dados. Os bancos de dados clássicos permanecem como o sol em torno do qual o código orbita. É a única fonte da verdade. Se a equipe puder mantê-lo em funcionamento, todo o trabalho está praticamente feito. Os usuários podem tolerar DIVs desalinhados ou novos layouts estranhos, mas não bancos de dados corrompidos.
Uma vez auditei o código para uma equipe que estava usando os melhores e mais recentes pacotes do Node.js., atualizando incansavelmente a sua pilha para permanecer na vanguarda. Mas o banco de dados tinha mais de 10 anos. Ninguém queria mexer com isso.
O nível de instrumentação disponível hoje pode ser incrível. Podemos sentir os dados subirem através das várias peças de software como um marinheiro sente o vento.
Conforme a carga dos pods diminui e flui, sabemos que tudo está funcionando corretamente (ou não). Se estivermos encarregados de um aplicativo de comércio eletrônico, seremos os primeiros a saber quando os descontos entrarão, porque a carga para essa parte do aplicativo aumentará. Mas a instrumentação pode nos dizer muito.
Os números resumem a tensão e o tempo de resposta do componente, mas não podem nos dizer o porquê. Essa questão é deixada para os programadores, que são os profissionais que entendem o que está acontecendo dentro dos componentes. Eles são capazes de isolar os bugs e encontrar soluções.
Alguns líderes empresariais podem desejar que haja uma equipe de tecnologia onisciente e onipotente, capaz de entender absolutamente todos os aspectos. Existem alguns super-humanos por aí, mas muitas vezes é melhor trabalhar para encontrar uma maneira fácil para o DevOps e os programadores colaborarem.
Os computadores podem ser máquinas completamente lógicas, nas quais o código evolui de maneira previsível e determinística. Todo bug acontece por uma razão. Poderíamos percorrer os arquivos de log e examinar o código, mas quem tem tempo? Assim como parece que 90% dos problemas de suporte técnico podem ser resolvidos com o ciclo de energia do dispositivo, grande parte do DevOps envolve executar a mesma tarefa. Ah, claro, usamos palavras como “contêineres” e “instâncias” e temos painéis intermináveis para monitorar o que está acontecendo, mas, no final das contas, muitas vezes é mais simples seguir em frente e, como sugeriu Iris Dement, deixar o mistério acontecer.
