Indiscutível que a computação em nuvem já é realidade e não mais tendência. Cada vez mais, as empresas tenderão a reduzir os investimentos em hardware e data centers, deslocando esses recursos para o desenvolvimento de software. Nas grandes corporações, veremos a predominância do conceito de nuvens híbridas e, nas pequenas e médias, as nuvens públicas tenderão se tornar o modelo dominante. Claro, isso não vai acontecer de um dia para o outro, mas é um fenômeno que tende a acelerar. Provavelmente no final da década nem falemos mais em cloud computing, mas sim apenas computing. Cloud será nosso modelo mental de pensarmos no uso e na entrega de recursos de TI.

Essa mudança do modelo computacional vai afetar em muito a maneira como a área de operações e infraestrutura de TI pensa e age.  Tradicionalmente, o foco tem sido a estabilidade do serviço. A TI boa é aquela da qual ninguém reclama… Mas o cenário de negócios está cada vez mais desafiador, e a velocidade das mudanças e transformações, muitas de ruptura, estarão colocando em cheque o tempo de reação atual da TI. Em tempos de cloud, no qual em vez de semanas podemos alocar recursos em minutos, devemos pensar de forma diferente. Os tempos de reação devem ser muito menores e devemos pensar em “cloud speed” como nosso novo referencial de tempo. Velocidade de entrega passa a ser um critério de extrema importância.

O ciclo de vida de uma aplicação, da sua concepção à entrada em produção, deve ser repensado. Hoje, como o foco é estabilidade e qualidade, e não velocidade, os processos acabaram se tornando burocráticos, com muitos controles que mitiguem eventuais riscos à estabilidade e minimizem impactos na operação. Em consequência, novos sistemas e mesmo novas versões de sistemas demoram tempos que são questionados quando analisados sob a ótica da “cloud speed”.

De maneira geral, adotamos os frameworks ITIL e COBIT para garantirmos a qualidade dos produtos de software que entram em produção. Esses frameworks não são inerentemente complexos, embora muitas empresas adotem processos excessivamente burocráticos e demorados para o sistema avançar no seu ciclo de vida. Por outro lado, o conceito de DevOps pode ser uma alternativa bastante atraente para aceleramos os tempos e conseguirmos avançar na “cloud speed”.

Importante: acelerar o processo não significa desprezar qualidade e estabilidade. O grande desafio é encontrar o ponto de equilíbrio entre os extremos.

Um caminho é diferenciar os diversos sistemas que são desenvolvidos por uma empresa. Existem os sistemas básicos, que a literatura está chamando de “system of records”, que têm baixa tolerância a riscos, mudam com pouca frequência e, caso saiam do ar, podem causar severos danos financeiros ao negócio. Um exemplo típico são os ERP ou similares (um sistema de reserva de passagens aéreas), que devem ser altamente estáveis. Práticas bastante formais de controle de qualidade são essenciais para esses sistemas. Mas lentidão não é inevitável para sistema complexos. A adoção de SOA e interfaces via APIs bem definidas permitem uma velocidade de mudança muito rápida, mesmo para sistemas de grande porte. Em uma arquitetura em que os serviços são isolados uns dos outros e seu único e exclusivo ponto de contato são APIs, estas podem ser mudados sem causar impactos nos demais componentes. Mesmo em sistemas complexos. Um exemplo é a Amazon.com, que praticamente a cada 30 segundos coloca uma mudança no ar, sem que os usuários sintam a modificação. Para isso, eles têm como obrigatoriedade que todo e qualquer componente do sistema interaja com outros exclusivamente via APIs. Vejam neste link.

Mas existem também sistemas que apresentam maior tolerância a riscos e eventuais falhas. No cenário competitivo de negócio, muitas vezes será necessário colocar no ar um sistema muito rapidamente, para aproveitar uma janela de oportunidade. Embora não se aceitem falhas catastróficas, eventuais pequenas falhas são aceitas em troca dos imensos benefícios do time-to-market. Estamos falando de apps para dispositivos móveis que devem ser desenvolvidos e modificados muito rapidamente, para se ajustarem à velocidade da dinâmica do mercado. Esses apps devem ser baseados no conceito de DevOps. Também aplicações web podem entrar nesse modelo, pois a frequência de modificações e ajustes nas interfaces e funcionalidades com os clientes devem ser rápidas. Por exemplo, com o uso de tecnologias como TeaLeaf, podemos identificar falhas de concepção e ajustar rapidamente os modelos de navegação dos sites às demandas dos próprios usuários. Se a proposta de mudança tiver que passar por um longo e demorado ciclo, da mesma forma que um system of records, perder-se-á oportunidades de negócio.

Nos apps móveis, surge também o conceito de MVP (Minimum Value Product), que se propõe a colocar no ar um app com funcionalidades básicas e evoluí-lo em períodos curtos. Falamos em evoluções semanais ou até em períodos menores.

Esse cenário muda a maneira como TI encara o desenvolvimento de sistemas e obriga a uma maior colaboração entre os profissionais que desenvolvem os sistemas e os que os mantêm em produção. Deixam de ser áreas isoladas e em alguns casos conflitantes. DevOps é um modelo no qual desenvolvimento e produção atuam em conjunto. A pergunta é: toda aplicação precisa estar 100% uptime? A resposta é: precisamos encontrar um meio termo para termos a agilidade necessária e uma estabilidade adequada ao risco inerente a cada aplicação.

Adotar o modelo de pensar “cloud speed” significa repensar o atual modelo de desenvolvimento e entrega à produção. Classificar as aplicações de acordo com sua características e necessidades de estabilidade e agilidade. Adotar métodos ágeis e o conceito de DevOps são fundamentais, mas também é essencial revisar os processos atuais para aceitarem conceitos MVP e sistemas “cloud speed”. A TI boa não é só aquela da qual ninguém reclama, mas aquela que inova.