Quando fazemos parte de um time, seja na área técnica, comercial ou administrativa, é comum que encontremos barreiras entre os setores. O time comercial, por exemplo, faz uma venda que muitas vezes é considerada inviável para entrega na área técnica, já essa última, por sua vez, prioriza a qualidade da execução de modo que vai contra alguns deadlines e promessas feitas no momento da venda.
Com isso acabamos vendo estratégias da gerência para evitar esses tipos atritos dentro da própria companhia e claro, no departamento de T.I não é diferente.
A constante batalha entre o time de desenvolvedores e o de operações é conhecida por quase todos que trabalham nestas áreas. Os desenvolvedores querem produzir a melhor aplicação possível nem sempre se preocupando com a estabilidade do app e sua manutenção, o que acaba frustrando o time de operações que é responsável pelo deploy e sustentação.
Assim, para resolver esse tipo de conflito, é que surge a cultura DevOps, uma ideologia que visa mitigar esses problemas que encontramos entre desenvolvedores (Dev) e administradores de sistemas (Ops).
O termo foi usado pela primeira vez no evento Velocity durante a palestra on-line de John Allspaw e Paul Hammond, realizada em 2009. Essa cultura lida sobre como quebrar barreiras e é algo que precisar ser implementado nas empresas o quanto antes. Apesar de ser uma filosofia, ou seja, um mindset que deve fazer parte de todo profissional, em um primeiro momento se torna necessário montar um time de profissionais DevOps. Esse time fica responsável por desenvolver práticas e serem os primeiros a usarem ferramentas que foram criadas em cima dessa metodologia, como:
- Jenkins, Travis e AWS CodeBuild, quando falamos de deploy.
- Puppet, Ansible e AWS System Manager, quando falamos de configuração.
- Docker, OpenStack e AWS CloudWatch, quando falamos de monitoramento.
Aliás, não é atoa que nessas três categorias existem exemplos de ferramentas da AWS (Amazon Web Services). Quando falamos de DevOps, a AWS geralmente é líder em qualidade e número de ferramentas para atender as demandas. Claro que isso não desqualifica outras nuvens, como a Azure, da Microsoft, e a GCP, do Google, mas o mercado tende a preferir a Amazon quando o assunto é DevOps.
A própria nuvem é, de certo modo, um paradigma que abraça o DevOps. Ter à sua disposição um set de ferramentas escaláveis, de fácil manutenção e uso, pagos sob demanda e com elasticidade é algo que beneficia todos os setores de uma empresa e todas as etapas de desenvolvimento de uma aplicação.
Como a carreira em DevOps é relativamente nova, a desconfiança e o desconhecimento surgem em torno do profissional, principalmente quando a empresa anuncia que vai contratar alguém daquela área.
Então é bom lembrar que DevOps não significa que a pessoa que trabalha na operação vai ser demitida e o Dev vai assumir tudo sozinho. Não se trata de “NoOps”, já que os (as) profissionais continuam com seu relevante papel na rotina corporativa.
Em suma, o papel de um DevOps é semelhante ao de um maestro em uma orquestra, mas a diferença é que ele também precisa “tocar o instrumento”, ou seja, “colocar a mão na massa” sem medo de perder sujar as mãos. Isso porque o objetivo é fazer o trabalho fluir.
Por Pedro Guth
