Os principais mitos sobre DevOps

O DevOps, com seu foco na combinação de desenvolvimento, testes, implantação e operação, tornou-se rapidamente uma espécie de “garoto-propaganda” para a entrega rápida de aplicativos. Alguns argumentam que DevOps é atrasado, uma vez que o sucesso do negócio depende claramente da entrega rápida de inovações baseadas em serviços de software de alta qualidade.

Como qualquer coisa relativamente nova, ainda há muita discussão sobre o tema – algumas das quais podem ser úteis, outras nem tanto. Antes de mergulhar de cabeça em DevOps, é importante conhecer alguns mitos e equívocos comuns. Como esses:

– DevOps é para descolados

Tenho um amigo que é um ótimo desenvolvedor. Ele pode escrever qualquer coisa de C++ em JavaScript para o Rails. Ele também tem 56 anos e calvície. Como eu, ele começou em operações de TI, trabalhou com virtualização anos antes de se assumir uma posição mais “mainstream” e ainda se lembra de linguagem de programação assembly.

Ainda que a gente acredite no que lê sobre DevOps, é um equívoco pensar que o problema de códigos suspeitos inseridos nas operações convencionais (que, então, colapsam) pode ser resolvido apenas com uma nova safra de profissionais mistos: um tipo de indivíduo com “quebra de silos”, dirigido para desde a configuração automatizada até a simulação de código de produção.

Um conselho: antes de procurar um novo talento em DevOps, reveja as habilidades inexploradas de recursos existentes, dentro do contexto de seus objetivos. Mesmo que meu amigo não se refira exatamente sobre DevOps, ele simboliza o movimento – ou seja, ele é um operador que pensa como um programador e um programador que entende a necessidade de melhoria em tudo o que desenvolve. No entanto, ele não é o problema, pelo contrário, a cultura rígida e a estrutura organizacional que impõem “cada habilidade dentro de uma caixa” é que impedem que seu conjunto de habilidades não seja totalmente aproveitado.

– Um movimento para governar tudo

É espantoso saber como as pessoas atraídas para o DevOps menosprezam qualquer conjunto de melhores práticas já estabelecidas. De repente, ITIL, COBIT e indicadores balanceados de desempenho viram “um favor”, com os DevOps engrossando o coro que proclama que tudo isso já não possui um lugar no mundo moderno e por isso deve ser descartado.

Conselho: não seja pego pela modinha. Você investe em qualquer conjunto de melhores práticas para acelerar e melhorar os serviços que entregados e suportados. Enquanto o DevOps está fundamentado no pensamento ágil, entregar continuamente os processos de gerenciamento de serviços de TI necessários para garantir a resiliência e estabilidade continua a ser mais crítico do que nunca. Portanto, não basta olhar para onde eles competem, mas como eles devem e podem se complementar.

– É um movimento tecnológico

Há diversos materiais técnicos de qualidade escritos sobre DevOps, com muitos termos novos a considerar – como “infraestrutura-como-código” e “antifragile”–, todos suportados por uma nova gama de produtos e técnicas. Contudo, muitas vezes o velho ditado é esquecido: “automatizar processos ruins apenas resulta em um processo ruim mais rápido”. Então, ser simplesmente a loja de desenvolvimento de aplicativos mais rápida, que possui novas ferramentas, não significa nada se o produto não atenderá às expectativas de negócios ou clientes.

Conselho: Olhe para as ferramentas que você tem e como elas estão sendo usadas. Por exemplo, se o gerenciamento de desempenho de aplicações é controlado pela equipe de operações. Mas e se os desenvolvedores pudessem efetivamente utilizá-lo para instrumentar códigos, simular o comportamento de desempenho e determinar melhor os requisitos de capacidade antes da produção? Agora não isso não é apenas uma ferramenta para monitoramento, é uma forma de colaboração para reduzir defeitos e melhorar a qualidade.

Lembre-se também de focar em velocidade e agilidade – assim, examine recursos que ajudem a montar aplicações viáveis rapidamente ??utilizando o feedback do cliente para testar hipóteses. Com isto em mente, aceite que aplicações acabadas podem ser completamente diferentes do que o previsto inicialmente. Por isso, reveja e esteja preparado para mudar métodos de planejamento de projeto, gestão de produtos, financiamento e implementação.

– Nosso negócio está imune

Muitas organizações afirmam que os princípios da DevOps não se aplicam porque eles terceirizaram operações ou não possuem uma função de desenvolvimento de aplicações. Outros supõem que, porque eles estão fabricando produtos ou entregando serviços ao governo, qualquer movimento com base na condução contínua de mudança não tem lugar em um mundo que “não está quebrado, então não conserte”.

Um conselho: olhe para os negócios primeiro, e depois para a TI. A Nike, por exemplo, não está nesse negócio porque só fabrica tênis – ela realmente vende uma experiência fitness (dispositivos portáteis).

Independentemente da plataforma de infraestrutura ou metodologia de desenvolvimento, essas empresas reconhecem que estão no negócio de software. Elas usam software para criar novos modelos de negócios, reforçar suas marcas e entregar novos serviços inovadores.

E enquanto pudermos chamá-la de entrega DevOps, lean, ágil, contínua ou qualquer outra denominação, eles são profissionais de empresas reais, adotando técnicas que outros ainda veem como contra intuitivas, como a experimentação e o design interativo e incremental, e acima de tudo aprendendo com o fracasso.

– DevOps vai mudar o mundo

Com tanto hype, é melhor ficar alerta. Independentemente de melhores práticas, metodologia ou movimento, as taxas de sucesso de projetos de desenvolvimento de aplicações não melhoraram muito em 20 anos. Apesar de 2012 representar um divisor no sucesso de projetos, 61% deles ainda foram desafiados ou falharam completamente, de acordo com o manifesto Standish 2013 do Grupo CHAOS.

Conselho: o DevOps trata-se de cinco coisas: pessoas, pessoas, pessoas, pessoas, e, ah, pessoas. Então, antes de entrar pela primeira vez no mundo do DevOps, reveja a cultura, processos e métricas que apoiam as suas equipes. Por exemplo, se a sua equipe de operações tem sido historicamente recompensada em interromper lançamentos de aplicações, então algo está definitivamente errado e nenhuma quantidade de desenvolvimento ágil irá ajudar. Da mesma forma, DevOps não vai ajudar muito se seus desenvolvedores não saírem do escritório para ouvir os clientes.