Reflexões para 2015…
Com o benefício da retrospectiva 20/20, tenho que me perguntar como eu — e mais outros CIOs — nos iludimos por tanto tempo pensando que o hardware era barato. Nos velhos tempos, deixaríamos grupos funcionais diferentes na companhia se apaixonarem por aplicações individuais de negócios, cada qual com seus próprios requisitos exclusivos de hardware e arquiteturas de middleware. Como as despesas de hardware sempre foram a menor parte fracionária de qualquer aquisição de um sistema principal, nós continuamente aumentamos o hardware para nos proteger contra possíveis problemas de desempenho do sistema. Para ser totalmente franco, realmente não fazíamos gestão de capacidade porque não queríamos saber a resposta: todos nós sabíamos intuitivamente que os nossos servidores e storages eram significantemente subutilizados.
Quando os provedores de nuvem pública começaram a disponibilizar infraestrutura de TI on-demand em uma base "pay-as-you-go" (pague apenas pelo que utilizar, em tradução livre), acordamos de nossos devaneios e percebemos que essas novas opções on-demand logo iriam substituir nossas operações in-house com sua eficiência e confiabilidade. Então, começamos a atuar como provedores de nuvem pública dentro de nossas empresas. Estabelecemos a lei com nossos clientes de negócio e informamos qual hardware e arquiteturas de middleware ofereceríamos e não ofereceríamos suporte. Dissemos a eles: "Se não for executado em uma de nossas arquiteturas padrão, você não pode comprar".
Então tivemos o dia do acerto de contas com os nossos diretores financeiros (CFOs). Tivemos que admitir que todos aqueles hardwares que eles nos permitiram comprar na última década estavam apenas "sentados" no data center, funcionando abaixo de 50% da capacidade em qualquer dia – exceto o mainframe, claro. Dissemos a eles que se apenas nos deixassem comprar capacidade antes da demanda no futuro, e evitar compras adicionais vinculadas a aquisição dos sistemas principais, poderíamos alcançar taxas muito mais altas de retorno em nosso hardware de TI. Nós tivemos apenas que concordar em começar a preparar relatórios sobre a utilização da capacidade em troca da nova política de aquisição.
É incrível quanto tempo gastamos com questões de segurança pública nas nuvens naquela época. Agora, migramos rotineiramente para provedores de nuvem pública para lidar com tipos específicos de cargas de trabalho (workloads). Caracterizamos os requisitos de segurança de cada workload de computação e usamos a criptografia adequada ou técnicas de "aliasing" de dados para garantir a segurança dos dados que estão passando para os provedores externos. Embora algumas formas de dados sejam muito sensíveis para jamais deixar o data center de nossa empresa, essas decisões de alocação de workload agora são controladas através de processos de provisionamento automatizado. Nós não temos debates filosóficos sobre o que pode e não pode ser passado por fora do firewall. Resolvemos este problema há muito tempo atrás.
Há dez anos, levaria de três a seis semanas de reuniões, e-mails, avaliações de hardware, e negociações de preço apenas para obter um conjunto de servidores disponibilizados para um grupo de desenvolvimento. Em 2010, usando configurações padrão e scripts automatizados em um ambiente virtual, os CIOs poderiam obter esses mesmos servidores funcionando em qualquer nuvem pública ou privada, em três a quatro horas. Hoje, podemos fazer isto em questão de minutos. Ter scripts padrão e automatizados prontos para prover diferentes tipos de servidores (como desenvolvimento, QA, web ou aplicações) na nuvem não apenas economizou grande quantidade de esforço de equipe, mas também manteve o negócio flexível.
Atualmente, gerencio uma plataforma híbrida de computação em nuvem composta por infraestrutura interna e on-premise e uma coleção de provedores de terceiros que uso em uma base "quando necessário" para lidar com workloads de computação específicas. Quando você pensa a respeito disso, não é diferente do jeito em que temos usado parceiros estratégicos de offshore outsourcing para ajudar a desenvolver e manter muitas de nossas aplicações de negócio.
Após o susto do bug do milênio, no final dos anos 90, passei cinco anos aprendendo como virtualizar minha aplicação e desenvolver equipes, alavancando recursos de TI situados na Ásia e no Leste Europeu. Passei os últimos cinco anos fazendo a mesma coisa com a minha infraestrutura, misturando o uso de ativos in-house e ativos externos para atender as necessidades dos meus clientes com o custo mais eficaz possível. Depois de tudo, acho que a história se repete.
É bom sabermos que fomos espertos o suficiente para mergulhar na onda da computação em nuvem ainda em 2010, ou nunca teríamos tido a flexibilidade e recursos exigidos para alavancar a explosão em aplicações de mobilidade que tem ocorrido nos últimos cinco anos. Na verdade, nós ainda estaríamos gastando 60% de cada dólar de TI "mantendo as luzes acesas" para os nossos sistemas de negócio herdados.
De volta a 2010, eu teria um ano bom se eu fosse capaz de entregar dois a três grandes novos aplicativos de negócios e produzir em grande escala os lançamentos trimestrais e mensais necessários para o "ninho de ratos" de sistemas legados que eu tinha de manter. Eu me vi competindo com desenvolvedores da Apple e Android que estavam produzindo 10 mil novos aplicativos por trimestre. É o mesmo tipo de história que a computação em nuvem. Desisti de competir com esses desenvolvedores de dispositivos móveis e, em vez disso, me tornei um deles. A minha equipe começou a desenvolver muito mais serviços de negócio granular que poderiam ser entregues em plataformas tablet com muito mais frequência. Na realidade, nossas equipes de desenvolvimento de aplicativos evoluíram para pequenas equipes internas de vendedores de software como serviço (SaaS), misturando serviços granulares para melhorar a produtividade de nossos usuários finais e responder às ameaças competitivas para o nosso negócio.
Começamos a usar versões de SaaS das nossas aplicações de negócio padrão no período de 2005 a 2010. Nossos usuários ficaram satisfeitos com a rápida introdução de novas funcionalidades providas pelos fornecedores de SaaS, e ficamos encantados com os custos inferiores relativos aos sistemas legados. Nos últimos cinco anos, nós mesmos nos tornamos provedores de SaaS. A maioria das aplicações que utilizamos na empresa hoje é apenas mashups de vários serviços de negócio. A maioria dos usuários não sabe se um determinado serviço está sendo entregue a partir de nosso sistema de ERP, de suporte ao cliente, e-commerce etc. Limitam-se a subscrever os serviços que precisam para fazer seus trabalhos. Não tentamos mais empurrar funcionalidade neles. Eles só extraem o que querem e precisam, e depois compartilham de forma mais ampla entre diferentes equipes funcionais e grupos geográficos do que jamais fizemos antes.
Uma das grandes vantagens da computação em nuvem para a nossa organização é que ela liberou uma grande quantidade de tempo que usávamos para gerenciar o hardware. Redirecionamos esse tempo para gerenciar os dados e informações que alimentam as nossas aplicações de negócio, e isso teve um impacto muito maior na eficácia das nossas operações comerciais cotidianas.
Vivemos em um mundo hoje que é radicalmente diferente do mundo que existia há apenas cinco anos. Nós não gastamos mais 60 centavos de cada dólar de TI na manutenção de aplicação, operações de data center, despesas com instalação etc. Em vez disso, gastamos no fornecimento de novos serviços de aplicação e novas formas de "limpar dados" para os nossos usuários finais. A equipe de TI está realmente muito mais feliz — ela percebe que estamos gerando valor real para nossos parceiros de negócios e não apenas correndo freneticamente tentando manter um monte de hardware e software subutilizados. Nós também estamos muito perto de alcançar o estado mítico de "alinhamento da TI e negócio" que ainda aparece nos tópicos mais pesquisados do Gartner para 2015.
Agora, se pudessem apenas construir uma xícara de café mais quente no meu tablet …
*Mark Settle é chief information officer (CIO) da BMC Software.
- Mark Settle, da BMC Software
