O Gartner representa o ciclo de adoção de uma nova tecnologia utilizando o “Hype Cycle” da figura abaixo.
Se tivéssemos que colocar um ponto nesse gráfico para representar Cloud Computing, eu diria que estamos no “Vale das Desilusões”. A grande maioria das empresas que eu converso está presa em um projeto de Cloud Computing, que outrora prometia ser o Nirvana da TI (Pico de Expectativas Infladas) e que agora é um projeto demorado, custoso e de resultados duvidosos.
Mas nem tudo está perdido! Se seguirmos o gráfico, vamos chegar no Platô da Produtividade! Mas é claro que antes temos que passar pelo Aclive do Esclarecimento e para isso é essencial entender porque tantas empresas tem dificuldades em implementar Cloud Computing!
Para começar, muitas vezes o próprio objetivo não está claro. Projetos de Cloud devem existir com um objetivo claro e específico, em geral aumentar a agilidade da TI para o usuário final, o usuário das áreas de negócio, das áreas clientes da TI! Claro que outros objetivos secundários podem existir, como: redução de custos; garantir transparência financeira; aumentar a confiabilidade, entre outros. Mas todos devem estar claros e com métricas de sucesso bem estabelecidas.
Outros motivos também comumente encontrados incluem:
1. Foco apenas em uma das camadas, em geral na parte de servidores ou máquinas virtuais: Como Cloud tem uma ligação grande com virtualização, é comum que o time responsável por esta área acabe liderando o projeto de Cloud. Isso faz com que o projeto não tenha força para cobrir outras áreas, como storage ou rede e faz com que sua abrangência fique limitada!
Exemplo: empresas criam portal de Cloud que consegue fazer o deploy automatizado de uma VM, mas todos os demais processos, como criação de rede, regras de firewall, storage, monitoração, entre outros continuem sendo feito de forma manual.
Resultado: Para o cliente da TI, que precisa de toda a infraestrutura e não apenas de uma máquina virtual, o resultado do projeto de Cloud é de pouca ou nenhuma relevância, já que não diminui o tempo total de provisionamento, e nem aumenta a agilidade.
2. Achar que cloud é apenas como produto: Claro que uma boa solução técnica ajuda e muito, mas está longe de ser suficiente. Cloud é um conjunto de 3 Ps – Produto, Pessoas e Processos. Sem as pessoas com o conhecimento certo nas posições certas e sem um processo ajustado, o ganho com projetos de Cloud será sempre limitado.
Exemplo: Empresas com processos que incluem controle de endereços IPs via planilha, atualizações manual de DNS, ou longos processos de aprovação que exigem questionários sofisticados mesmo para mudanças mais simples.
Resultado: A empresa passa meses – talvez anos – tentando customizar produtos para aderir aos seus processos e no final descobre que, assim como no item anterior, o projeto não cumpre seu objetivo de aumentar a agilidade para o usuário.
3. Montagem errada do catálogo de serviço: Catálogo de serviço não é algo novo ou algo exclusivo de Cloud, mas esse é um item tão importante, que eu preciso subdividir em 2 categorias:
a. Empresas que ainda não tem um catálogo formal estabelecido. Trabalham sempre para atender a última demanda do usuário, e cada requisição é algo customizado. Imaginem um restaurante se cada cliente que entrasse pedisse um prato que ele inventou... parece um exemplo ridículo, mas muitas vezes a relação entre TI e usuários ocorre dessa forma! Como consequência, o time da cozinha fica sobrecarregado, e um prato que demoraria 15 minutos para sair, leva 8 horas... :)
b. Empresas que tem um catálogo, mas que não sabem a aderência dos itens desse catálogo a uma arquitetura de Cloud. Quão pedido é um item do catálogo e quão fácil é automatizá-lo são perguntas essenciais que precisam ser respondidas! Por exemplo, será que compensa gastar meses desenvolvendo um fluxo de automação para provisionar uma LPAR, sendo que TI recebe 1 ou 2 requisições desse tipo no ano? O gráfico abaixo dá uma sugestão de como as empresas deveriam decidir quais produtos do catálogo serão migradas para Cloud.
4. Complexidade da infraestrutura: Por diversos fatores as empresas chegam a uma infraestrutura de TI complexa, com diversos fornecedores e produtos diferentes. Esse modelo cobra o seu preço, quando precisamos inseri-lo dentro de uma arquitetura de cloud que precisa ser ágil e automatizada. Muitas vendors de cloud, colocam em suas apresentações slides maravilhosos, aonde a solução deles consegue se conectar a tudo e automatizar tudo. Mas enquanto não inventam uma ferramenta que transforme PPT em realidade as empresas que adquirem essas ferramentas descobrem que ainda precisam investir centenas ou milhares de horas de consultoria e de funcionários para poder criar os fluxos que irão conseguir automatizar a sua infraestrutura complexa... e muitas vezes o resultado é frustrante.
Aqui é onde cloud se conecta com outro termo que tem ganhando muita força: SDDC (Software-Defined Data Center), que através da abstração do plano de controle promete habilitar uma gestão mais simples de todos os principais componentes do data center (servidores, rede e armazenamento), mas isso é assunto para outro dia.
