Três coisas que impedem você de adotar o DevOps

Não, você não. Você. Os executivos não estão nem de longe tão entusiasmados com o DevOps quanto aqueles que estão nas trincheiras, e a resposta pode ser encontrada em uma dessas três principais preocupações.

Organizações de alto desempenho não apenas adotaram, mas abraçaram o DevOps. O relatório seminal State of DevOps da Puppet Labs nos mostrou isso nos últimos dois anos e imagino que reforçará esse relacionamento novamente no próximo ano. As organizações estão, de acordo com uma série de pesquisas e estudos do setor, adotando o DevOps. Mas, assim como eles adotaram metodologias ágeis e enxutas de desenvolvimento de aplicativos no passado, adotar nem sempre significa o que pensamos que significa. Descobriu-se que o que as organizações realmente querem dizer com “adotar o ágil” para o desenvolvimento de aplicativos é que uma porcentagem relativamente pequena de seus projetos estava usando o ágil. Isso não significa que eles se arriscaram de verdade e adotaram essa abordagem em todos os projetos.

O mesmo parece ser verdade para o DevOps, onde os entrevistados estão adotando com entusiasmo – e percebendo resultados – mas os executivos em geral parecem ainda estar mornos em relação à abordagem, aumentando apenas dois pontos percentuais em “impacto estratégico” ano após ano – de 15% em 2016 para 17% em 2017, de acordo com nossa pesquisa State of Application Delivery . Embora os arquitetos de nuvem e as funções autoidentificadas como “DevOps” possam estar a todo vapor com suas iniciativas de DevOps, e até mesmo sobrecarregados na produção, os executivos ainda estão atrasados na adoção da abordagem. O que realmente significa que as “organizações” não estão necessariamente aderindo totalmente ao DevOps.

Há três preocupações principais que provavelmente impedem que a liderança de TI e de negócios dê ao DevOps a recepção calorosa que ele merece.

1. Tempo . Projetos internos de TI de qualquer tipo que exijam uma mentalidade de migração – seja do tradicional para a nuvem, do monolítico para o microsserviço, do manual para o automatizado – às vezes são vistos como pouco mais do que uma proposta de perda de tempo. Eles não contribuem diretamente para o crescimento do negócio e, portanto, o tempo gasto em tais projetos pode ser oneroso para as partes interessadas do negócio. Cabe aos que apoiam o DevOps ilustrar aos líderes empresariais um conjunto claro de objetivos e benefícios esperados que surgirão ao embarcar em tais projetos. Seja para economizar custos ou ter uma TI mais responsiva, é importante que as empresas entendam o retorno esperado do investimento para que elas comprem e apoiem o esforço. Um centavo economizado pode ser um centavo ganho, mas um centavo investido geralmente é um centavo ganho. Invista em DevOps agora e as organizações colherão os frutos mais tarde.
    
2. Perturbação.  Nenhum líder de TI quer ser a causa de interrupções nos negócios. Investir em uma iniciativa DevOps agora pode ser prejudicial, principalmente se causar uma desaceleração no pipeline de produção quando todos sabem que você precisa acelerá-lo. Como habilitar a produção para automação e orquestração muitas vezes significa mexer nos sistemas responsáveis pelos negócios do dia a dia, qualquer iniciativa que exija isso pode causar uma interrupção indesejada. A realidade é que confiar em métodos manuais e ultrapassados para provisionar, dimensionar e gerenciar sistemas pode ser a verdadeira ruptura – se não hoje, então amanhã. Uma das características de um ambiente de produção sem atrito é a capacidade de responder sob demanda às necessidades de capacidade e serviços. Isso é algo que se torna cada vez mais difícil de alcançar à medida que a TI se curva sob o peso da crescente demanda causada pelos esforços de transformação digital. Sem risco, sem recompensa. Assumir o risco agora provavelmente envolve menos riscos do que quando seu portfólio de aplicativos cresceu 2x ou mais.
    
3. Bloquear . Um medo comum da liderança de TI é ficar “preso” às escolhas. A boa notícia é que a preponderância de dispositivos e sistemas de rede que oferecem suporte à automação e orquestração são baseados em protocolos e conceitos de padrões abertos, como HTTP, REST e JSON. É aqui que o tempo gasto inicialmente projetando e arquitetando um sistema que aproveite APIs e modelos o máximo possível será recompensado mais tarde. A integração com dispositivos ou sistemas que exigem a recriação passo a passo de comandos emitidos pela CLI por meio de uma API quase certamente levará ao bloqueio. Este é um dos maiores benefícios dos modelos: reduzir a dependência de APIs específicas do dispositivo e do sistema e, assim, limitar sua exposição a apenas alguns comandos que são facilmente migrados para um novo sistema ou aplicativo no futuro.  Certifique-se de que a infraestrutura suporte uma API baseada em REST e, sempre que possível, use modelos para facilitar a extração de sistemas e ambientes posteriormente.

Há outras preocupações, é claro, mas principalmente essas três principais preocupações ressoam em todos os data centers e ao longo do tempo quando se trata de adoção de tecnologia e metodologia. Leva tempo, pode ser perturbador e há uma grande chance de bloqueio. A devida diligência e uma abordagem cuidadosa à implementação, juntamente com uma atitude de investir agora e se beneficiar depois, podem aliviar essas preocupações e gerar uma chance maior de estabelecer com sucesso uma base firme, mas flexível, que não apenas permita, mas acelere a transformação digital necessária para que os negócios cresçam agora e no futuro.