Lock-in em Cloud Computing

Venho observando que o conceito de cloud computing vem amadurecendo a cada dia. Passamos pela empolgação inicial e já começamos a entender que existem muitas coisas boas, mas que também existem algumas restrições. Quando falamos em nuvens públicas, alguns dos principais receios e questionamentos referem-se a questão da segurança e da disponibilidade dos serviços. A segurança, por exemplo, pode muitas vezes ser endereçada com o uso de nuvens privadas, desde, é claro, que a empresa tenha uma política de segurança aprimorada. Mas, existe um aspecto preocupante nas nuvens públicas que ainda não tem sido considerada com a devida atenção, que é o alto risco de aprisionamento forçado ou “cloud lock-in”.

 O lock-in em nuvens públicas aparece porque cada provedor implementa seu próprio conjunto de APIs e muitas vezes seu próprio banco de dados e ambiente de programação. O resultado é que o usuário acaba ficando aprisonado na nuvem deste provedor, uma vez que o trabalho de mover suas aplicações para outras nuvens não será muito simples e nem será barato. Porque isto acontece? Uma caracteristica diferenciadora do ambiente de cloud computing com relação ao ambiente tradicional é que a infraestrutura em cloud, por si, é programável. Por exemplo, para usarmos os serviços S3 ou SimpleDB da  Amazon usa-se um conjunto de APIs próprias. O mesmo acontece quando usamos o GAE (Google Application Engine) e seus recursos proprietários de banco de dados (BigTable). O problema é que estas APIs implementam acesso a recursos especificos e proprietários e não são padronizados. Migrar de uma nuvem como a da Amazon para a do Google ou do Azure da Microsoft para o Google demandará um belo trabalho de conversão.

 Observamos um fato interessante: quanto maior o nivel de abstração da nuvem, maior seu potencial de lock-in. Ou seja, uma nuvem SaaS oferece maior risco de lock-in que um PaaS e este maior potencial que uma nuvem IaaS. Exemplo prático: o Force.com cria um lock-in bastante intenso pois as aplicações devem ser desenvolvidas na linguagem proprietária do Salesforce que é o Apex, que não está disponivel em outros ambientes de nuvem. Já no GAE, voce pode pegar seu código Java ou Python e usar o programa em outra nuvem, mas caso use (e acaba-se usando) os recursos proprietários como o banco de dados BigTable, tem-se o lock-in.

 O que fazer? Bem, já existe uma alternativa a este aprisionamento, que foi a criação das chamadas Open APIs, como as criadas pela RedHat (Deltacloud, que pode ser acessada em http://deltacloud.org/), Apache (Libcloud acessado em http://incubator.apache.org/projects/libcloud.html) e Zend SimpleCloud API (http://www.simplecloud.org/). Outra proposta é a da OGF (Open Grid Forum) Open Cloud Computing Interface, que pode ser vista em http://www.occi-wg.org/doku.php?id=start). Estas APIs criam uma camada de abstração permitindo que o desenvolvedor não tenha que se procupar com APIs de nuvens específicas. A proposta é que uma OpenAPI se encarregue de fazer automáticamente a tradução para as APIs especificas. As suas limitações são ainda o fato que continua persistindo o problema da interoperabilidade entre as nuvens públicas (uma aplicação rodando na nuvem EC2 da Amazon não fala com a nuvem Azure da Microsoft) e obriga a que o desenvolvedor aprenda este novo conjunto de APIs. Mas, é um bom primeiro passo.

 E o futuro? Creio que o modelo de aprisionamento atual é decorrente de um conceito e tecnologias que estão na sua infância e portanto ainda na fase dos provedores destes serviços buscarem consolidar seu espaço no mercado. Históricamente novas tecnologias e mercados na Internet evoluem da seguinte maneira:

a) Um novo mercado ou tecnologia surge baseado no modelo fechado e proprietário.

b) Por pressão de um mercado em crescimento, começam os primeiros sinais de abertura.

c) Quando o mercado ou tecnologia já está maduro, torna-se aberto (open) ou “open enough”.

 Na verdade, o conceito de aberto tem perspectivas diferentes quando falamos em serviços, como as nuvens públicas e quando falamos em software. A essência de uma nuvem pública é que o usuário está alugando os recursos computacionais de outra empresa, o provedor de serviços em nuvem. Claro que em um contexto destes o usuário não poderá ter 100% de controle e os serviços de nuvem continuarão fechados (infraestruturas, métodos e práticas proprietários).

 Mas, nuvens não interoperáveis serão uma limitação muito grande à própria expansão do  mercado de public clouds. A pressão do próprio mercado e a tendência para sistemas abertos vai obrigar a que no futuro estas nuvens públicas sejam realmente abertas. Será absolutamente essencial permitir interoperabilidade entre todas elas. Uma aplicação rodando no Azure deverá demandar acesso a outra que esteja rodando no GAE ou no EC2, sem limitações.  Portanto, na minha opinião será questão de tempo vermos APIs abertas e a interoperabilidade  entre nuvens.

 Para fechar, vale a pena lembrar a iniciativa chamada Open Cloud Manifesto, que mostra a preocupação do mercado com este risco de lock-in. O Open Cloud Manifesto pode ser lido em www.opencloudmanifesto.org) e se propõe a  aglutinar empresas que oferecem tecnologias e serviços de cloud em torno da especificação de um padrão aberto.

 O manifesto estabelece um conjunto de diretrizes, denominados princípios para nuvens abertas,  que asseguram que as organizações que usarem nuvens computacionais não ficarão restritas a padrões fechados, mas terão liberdade de escolha, flexibilidade e abertura para não ficarem aprisionadas a nenhuma nuvem. Dezenas de empresas já fazem parte deste manifesto, como a IBM, CA e EMC, mas algumas outras como Microsoft, Google e Amazon ainda não acordaram nenhum compromisso com esta proposta. Pena, pois padrões abertos são garantia de interoperabilidade entre nuvens.

Implicações financeiras do SaaS

Esta semana almocei com um amigo, empresário da industria de software. Ele tem uma empresa que desenvolve e comercializa pacotes de software e está muito preocupado com o imenso desafio que é o tsunami da Cloud Computing e SaaS para seu negócio. A conversa fluiu na direção dos aspectos financeiros (afinal, minha formação foi economia e só depois é que fiz o mestrado em ciência da computação) e nas necessidades de transformação que sua empresa irá sofrer.

 Na minha opinião já está claro que Cloud Computing e SaaS irão (aliás, já estão…) transformando  industria de TI e abre novas e desafiadoras oportunidades para empresários e empreendedores. Por outro lado, toda mudança apresenta riscos e a relutância em adotar novos modelos é sempre alta. Explica-se:  de maneira geral não aceitamos mudanças em grande escala com facilidade, sobretudo quando estas mudanças abalam nossas crenças e modelos mentais. Geralmente apenas quando a crise se instala é que as resistências são vencidas. A empresa de meu amigo ainda não está em crise, mas se ele nada fizer, ela inevitavelmente, virá.

 Um dos desafios, o tema principal de nossa conversa, foi como mudar seu modelo de cash-flow sem impactar seus negócios. Hoje quem financia sua operação são seus clientes, quando adquirem licenças perpétuas dos seus pacotes, antes mesmo de implementá-los e usá-los. No modelo SaaS este cash-flow é diferente. Receber pequenos pagamentos mensais ou trimestrais em vez de um polpudo cheque na venda do produto é o principal motivo da mudança do aspecto financeiro de seu negócio. Na prática, mesmo que ele conseguisse receber todas as “prestações” do primeiro ano adiantado, este valor ainda seria bem inferior ao que ele recebe na venda do pacote, pelo modelo atual.

 O modelo SaaS mostra algumas características próprias. Uma delas é o elevado “selling cost” com relação ao faturamento. O “selling cost” é o custo de adquirir um cliente. Analisei rapidamente alguns IPOs de empresas SaaS americanas e vi que o investimento na operação (vendas, marketing, hosting do aplicativo e suporte técnico) para suportar o negócio tende a ser bem elevado, chegando algumas vezes a 2x o faturamento previsto. Um exemplo foi o IPO da Netsuite (www.netsuite.com). O documento mostrou que enquanto o faturamento da empresa tinha sido de 17,7 milhões de US$ em 2004, 36,4 em 2005 e 67,2 em 2006, os seus custos de marketing e vendas tinham sido de 27 milhões em 2004 e 39,2 milhões em 2005. Em 2006 foi menor que o faturamento, mas mesmo assim foi de 53% deste valor. Bem, uma pequena explicação. Este valor alto não significa que o “selling cost” real seja mais elevado que no modelo atual, mas apenas que reflete como o faturamento acontece no SaaS. Por exemplo, no modelo atual, venda de licença perpétua, se a empresa de meu amigo tivesse um vendedor, custando a ele 300.000 reais por ano (claro que é hipotético…) e apenas no Q4 ele conseguisse uma venda de um milhão e meio de reais, o seu “selling cost” como percentual do faturamento do ano será de cerca de 20%. Por outro lado, se for no modelo SaaS  ele teria vendido um contrato de 3 anos, com o pagamento sendo efetuado em 36 parcelas mensais.  O “selling cost” seria então de 240% do faturamento do ano! A razão é simples: apenas uma pequenissima parcela do faturamento seria reconhecido naquele ano. Como muitas despesas são efetuadas antes da chegada de receitas, estima-se que empresas SaaS demandem um tempo muito maior que as empresas tradicionais para se tornarem lucrativas.

Mas, ele não poderá ficar inerte, pois o mercado está demandando a mudança. Tem que agir e planejar desde já como migrar para o novo modelo. Na verdade, a mudança não é apenas de redesenho de produtos, mas de modelo de negócios e cash-flow. A equação financeira tem papel importantissimo e fundamental na transformação para SaaS. Mas, existe o lado positivo. O modelo SaaS tende a gerar cash-flows mais estáveis, menos sujeitos a crises que afetam o ciclo de vendas. Afinal os contratos já estão assinados e o modelo pay-as-you-go é bem mais atrativo para os clientes, principalmente em épocas de crises.

 No fechamento de nossa conversa acordou-se também que ele deverá estudar a criação de um novo modelo de vendas, que enfatizasse uma relação mais duradoura com o cliente e menos focada no transacional e desenhasse novos modelos de remuneração para sua equipe de vendas envolvida no SaaS. Como ele não poderá fazer a transição no estilo “big bang”deverá manter duas operações simultâneas, um para o modelo tradicional on-premise e outra para o SaaS.  Além disso, como o SaaS joga o financiamento da operação do negócio do cliente para a empresa dele, ele precisa repensar seu modelo de desenvolvimento (e hosting) dos pacotes, pois seu custo não poderá ser recuperado pela venda de licenças “upfront”.

 Outra mudança é criar um modelo de atendimento e suporte ao cliente muito mais eficiente que hoje, pois o envolvimento com o cliente passa a ser diário. As alterações e upgrades nos seus pacotes serão feitas diretamente nos seus servidores e podem afetar, em caso de falhas, todos os seus clientes ao mesmo tempo.

 Um comentário final. Todas as empresas de software conseguirão fazer a transição? Na minha opinião, toda mudança mata empresas e cria outras. Isto também vai acontecer com o Cloud Computing e SaaS. Entendo que as empresas que conseguirão fazer a mudança mais facilmente são as que de alguma maneira já atuam forte em serviços. Explicando. A indústria de software pode ser dividida em três grupos: companhias de produtos, companhias de serviços e híbridas. As empresas focadas em produtos tem mais da metade de seu faturamento oriundas exclusivamente da venda de licenças e manutenção de seus produtos. As empresas de serviços obtém a maior parte de sua receita vinda da customização, instalação, integração e consultoria, ajudando os seus clientes a implementarem os pacotes. As híbridas tem um balanceamento entre as duas modalidades de receitas. Cada grupo tem modelos de negócio próprios.

 As empresas de produto tendem a obter rentabilidade mais rapidamente, porque usufruem da economia de escala.  Podem aumentar sua receita sem o correlato aumento substancial de seus custos. Mas, não entendem de serviços…na minha opinião terão dificuldades para se tornarem empresas de serviços, caracteristica padrão do modelo SaaS.

 Empresas mais focadas em serviços, para crescer precisam aumentar sua equipe de suporte e consultoria, que implementa seus contratos de serviços. Mas, estas empresas já estão acostumadas com prestação e serviços e suas peculiaridades, o que irá facilitar signficativamente a futura adoção do modelo SaaS.

SaaS e o direito dos clientes

Recentemente li um documento muito interessante, chamado “Customer Bill Of Rights: Software-as-a-Service”, em http://tinyurl.com/yza2qs3, onde são debatidos os direitos dos usuários de SaaS.

 O modelo SaaS vai ser adotado muito mais rapidamente que os analistas prediziam porque seus impulsionadores são bem atrativos, como menor tempo de implementação quando comparado ao modelo tradicional on-premise (que demanda instalação nos servidores das empresas), ciclos de atualização e inovação mais frequentes e menos dores de cabeça quando dos upgrades, pois todo o trabalho é efetuado nos bastidores, nos servidores do próprio provedor, e não mais nas máquinas dos clientes. Além disso, os seus contratos são por assinatura e não mais de licenciamento, deslocando os capex para opex. E adicione-se a isso a crescente insatisfação dos clientes com as altas taxas de manutenção e upgrades praticadas por muitas das empresas de software. Tudo isso são impulsionadores quase irresistiveis.

 Por outro lado, as empresas de software tradicionais, empurradas pelo mercado, buscam rapidamente criar alternativas SaaS para seus produtos.  Algumas chegaram a demitir seus CEOs por não ter articulado uma estratégia de SaaS. Neste momento, de tempos ainda um tanto pioneiros, surgem inevitavelmente alguns desconfortos e desentendimentos. De maneira geral, a história tem mostrado que poucas empresas da industria de TI conseguem fazer uma transição bem sucedida quando de uma quebra de paradigmas. Por exemplo a maioria dos fornecedores de banco de dados e aplicações dos anos 80 não conseguiram sobreviver à mudança para o mundo relacional e cliente-servidor. Lembram-se da Cincom e seu banco de dados Total ou da Cullinet e seu IDMS? E da McCormack&Dodge, no setor de aplicativos? Pois bem, estamos às portas de uma nova ruptura e muitas das empresas de software que ficaram 20 anos desenvolvendo e aperfeiçoando seus modelos de negócio sob o conceito on-premise terão muita dificuldade para se transformar.

 Por isso este documento de Bill Of Rights vem na hora certa. Embora ainda seja um work-in-progress, põe um pouco de luz no cenário e ajuda, tanto aos provedores quanto aos usuários de SaaS a pensarem um pouco melhor em como fornecerem e contratarem estes serviços. É melhor que o relacionamento entre os provedores de SaaS e seus  clientes comece corretamente, sem os vícios das relações anteriores. Prevenir é melhor que remediar e tentar posteriormente consertar contratos defeituosos.

 Alguns hábitos adotados por algumas empresas de software do modelo on-premise podem contaminar os novos relacionamentos e não devem ser aceitos pelos usuários. Por exemplo, exigências de contratos de confidencialidade que impeçam o usuário de debater ou obter assessoria externa na análise de contratos e politicas de preço praticados pelo provedor. O documento, que merece ser estudado mais detalhadamente, aborda diversas questões importantes. Uma delas é que a essência da relação muda de licença perpétua (on-premise) para “uso perpétuo” (SaaS) e para criar uma relação win-win é necessário validar alguns pontos como:

 a) No modelo SaaS multi-tenancy os provedores detém o código e os usuários são “donos” apenas de seus dados e metadados. Mas, se o provedor sair do mercado? Ou for adquirido por um competidor de sua empresa? Quais são as estratégias de saída que você vai adotar e como impedir o aprisionamento forçado (lock-in)?

b) No SaaS os upgrades e inovações são disponibilizados automaticamente  a todos os usuarios, pois são efetuados na nuvem do proevdor. Mas, o provedor está comprometido (e tem cacife financeiro) para manter um ritmo de evolução e inovação adequado? Estas inovações representarão mudanças contratuais?

c) Quais são as técnicas e procedimentos de disponibilidade e backup implementados pelo provedor?

d) Quais são as práticas de governança adotadas pelo provedor? Ele tem preocupação em estabelecer relações duradouras e não meramente transacionais? É uma relação que incentiva a transparência, debatendo-se de forma aberta eventuais problemas?

 O documento detalha aspectos que o usuario deve esperar de um provedor, em todas as fases de seu relacionamento, que são as fases de seleção do software, deployment, adoção, otimização e renovação ou cancelamento contratual. Sem entrar em detalhes, podemos destacar os seguintes pontos:

 a) Na fase de seleção, é adequado esperar uma politica de “try before buy” e cláusulas bem claras e explicativas de licenciamento e precificação. É de se esperar também que o provedor auxilie  na análise de TCO, disponibilize acesso a comunidades de usuarios (para referências e troca de opiniões isentas) e permita uma “due diligence” quanto aspectos financeiros, legais e de riscos.

b) Na fase de deployment os usuarios devem esperar que seus provedores SaaS disponibilizem por conta própria ou por terceiros treinamento, especialistas e um claro reporte do andamento do projeto de implementação.

c) Quando da adoção, espera-se que o software tenha qualidade adequada, suporte eficiente e cumpra os niveis de serviço contratados.

d) Otimização. De forma similar aos usuários de celulares, espera-se que clientes mais fiéis sejam recompensados e que inovações sejam periodicamente disponibilizadas.

e) e finalmente, na renovação ou eventual cancelamento do contrato, espera-se que o provedor facilite a transição para outro provedor e apague os dados armazenados em seu cloud center.

 O modelo SaaS abe uma oportunidade para clientes e fornecedores de software repensarem seu relacionamento. O modelo on-premise muitas vezes incentiva, por razões comerciais (pressão pelo fechamento da cota do trimestre), a criação de relacionamentos transacionais. O modelo SaaS substitui estas relações transacionais por prestação de serviços onde a relação  win-win é essencial para continuidade do contrato. Os dois lados devem entender e garantir que seus direitos e deveres sejam cumpridos. Novos tempos, nova maneira de se pensar software!

Linux em Cloud Computing

Outro dia estava conversando com um amigo sobre o Linux, sistema que fará 20 anos no ano que vem. O Linux já representa hoje uma força econômica considerável, com um ecossistema estimado em 25 bilhões de dólares. Está em praticamente todos os lugares. Quando fazemos uma pesquisa no Google ou lemos um livro no Kindle é o Linux que roda nos bastidores.

 O Linux demonstrou de forma inequívoca o potencial do desenvolvimento de sistemas de forma colaborativa, que é o cerne do modelo Open Source. Seria praticamente impossível para qualquer empresa de software, sózinha, criar um sistema operacional de seu porte e complexidade. Estima-se que o custo de desenvolvimento de uma distribuição como a Fedora 9, com seus mais de 204 milhões de linhas de código  corresponda a quase 11 bilhões de dólares. Para chegar ao kernel 2.6.30 (mais de 11 milhões de linhas de código) o investimento seria de mais de 1,4 bilhão de dólares.

 Para se ter uma idéia do volume de trabalho em cima do kernel, nos ultimos 4 anos e meio, a média foi de 6.422 novas linhas de código adicionadas por dia, além de outras 1.687 alteradas e 3.285 removidas. Do 2.6.24 ao 2.6.30 a média subiu para 10.923 linhas de código adicionadas por dia. Quem teria cacife financeiro para sustentar, por si, um empreendimento bilionário destes?

 Portanto, o Linux é uma força no presente. É usado não apenas em web servers e print servers, mas a cada dia vemos mais e mais aplicações core das empresas operando em plataformas Linux. A IBM, por exemplo, consolidou seu ambiente de computação interno (seus sistemas internos) em plataformas mainframe System Z, rodando Linux.

 O Linux ainda tem muito espaço para crescer. É bem provavel que vejamos uma migração mais intensa de ambientes Unix como Solaris e HP-UX para Linux, devido a incerteza quanto ao futuro destas plataformas. Qual será o futuro dos servidores Solaris sob a nova administração de uma empresa de software como a Oracle, que não conhece os meandros dos modelos econômicos do setor de hardware?

 E as plataformas baseadas em Itanium? Manter uma linha de processadores demanda muito investimento e é necessário que haja escala suficiente para haver retorno financeiro. Em comparação com a linha Xeon, o Itanium não é um produto de alto volume para a Intel. Embora a Intel não publique o seu volume de produção, analistas de indústria estimavam que em 2007  o ritmo de produção era de  200.000 processadores por ano. Segundo o Gartner, em 2007 o número de servidores Itanium vendidos foi de 55.000. Número muito pequeno quando comparado com os 417.000 servidores RISC (da familia Power da IBM e das demais tecnologias) e os 8,4 milhões de servidores x86.

 Mas, e o futuro? Com as mudanças que já estão acontecendo, como a crescente disseminação da computação móvel e o modelo de computação em nuvem (Cloud Computing), como o Linux se posiciona?

 É uma resposta fácil. O Linux, que não conseguiu muito espaço nos desktops está se posicionando como plataforma dominante na computação móvel, como smartphones, netbooks e tablets. No seu último ano fiscal que se encerrou em 30 de junho do ano passado, a Microsoft pela primeira vez reconheceu em seu relatório para os acionistas que os sistemas Linux para máquinas cliente, basicamente netbooks, da Red Hat e Canonical seriam ameaças ao seu negócio. Anteriormente, só havia reconhecido a ameaça do Linux nos servidores. O relatório está em http://tinyurl.com/kr723z. Também nos smartphones está claro que o sistema Windows, que dominou a era dos desktops não conseguiu decolar na computação móvel, com o Windows Mobile perdendo espaço a cada dia.

 E quanto aos servidores? Nestas máquinas o Linux está altamente alinhado com as tendências de virtualização e  cloud computing. Alguns pontos positivos sobre o Linux chamam a atenção, quando falamos em cloud. Primeiro, o Linux opera em praticamente qualquer plataforma de hardware, o que facilita o provisionamento, alocação e gerenciamento de recursos computacionais em nuvem. Podemos criar desde uma nuvem baseada em plataforma x86 como o Google até nuvens em mainframes IBM, aproveitando o alto  throughput e facilidade de virtualização destas máquinas. O custo de licenciamento é outro fator interessante. Embora existam distribuições licenciadas, um provedor de infraestrutura em nuvem, pelo grande  numero de servidores que deverá dispor (falamos aqui em milhares ou dezenas de milhares de máquinas), poderá adotar, pela escala, versões Linux não comerciais. Virtualização é outro plus do Linux, com diversas tecnologias disponiveis como Xen (base da arquitetura de cloud da Amazon) e KVM.

 Hoje, se olharmos Linux em cloud já vemos seu uso como base tecnológica da nuvem do Google, da Amazon, do Force.com do Salesforce e de startups como 3Tera (recém adquirida pela CA), Elastra e Mosso, entre outros. E com certeza seu uso se alastrará pelas futuras ofertas de nuvens.

Qual será a velocidade de adoção de Cloud Computing?

Fim das férias e de volta ao batente…Retornando ao assunto que me motiva cada vez mais, que é Cloud Computing. O modelo de Cloud Computing é bem recente, com o próprio termo sendo criado há poucos anos, mais precisamente em 2006.

 A velocidade de sua adoção será regulada pelas próprias forças de mercado. De um lado, usuários que estão cada vez mais propensos a reduzir seus custos e melhorar a utilização do seu parque computacional, vêem a computação em nuvem como a melhor alternativa para isso. Os seus impulsionadores são bastante atrativos para serem menosprezados, como  redução dos investimentos em capital (as empresas estão favorecendo cada vez mais o OpEx contra o CapEx), modelo “pay-as-you-go” ou “subscription-based” (típico do SaaS), elasticidade (infraestrutura alinhada com a flutuação da demanda) e maior agilidade na entrega de serviços de TI.

 De outro lado, agindo de forma mais conservadora, os tradicionais fornecedores de TI, que receiam ver suas atuais margens sendo reduzidas. Por exemplo, a margem dos fornecedores de SaaS é bem menor que as margens conseguidas atualmente com o modelo tradicional de licenciamento de software on-premise. Também as margens do “storage online” são bem menores que as obtidas com a venda de sistemas físicos de armazenamento.

 Em princípio, vemos que os mais afoitos em adotar Cloud Computing são pequenas empresas e start-ups sem sistemas legados. As grandes corporações tendem a ficar em espera, observando o cenário, mas fazendo algumas experiências e provas de conceito….Mas, já vemos alguns sinais de mudança no ar, vindo destas grandes corporações. Por exemplo, a Panasonic assinou com a IBM (Lotus Live) um contrato para colocar em nuvem seu ambiente de colaboração e email para seus 380.000 funcionários no mundo todo. Em outro exemplo, a cidade de Los Angeles, nos EUA, contratou o Google para colocar em nuvem o email dos seus 34.000 funcionários. Estes movimentos sinalizam que não são apenas pequenas empresas que estão mergulhando na onda do Cloud Computing. À medida que outras grandes empresas embarquem neste trem, e mais e mais experiências positivas sejam divulgadas, o ritmo tenderá a se acelerar de forma exponencial.

 Quando falamos em provedores dos vários serviços em nuvem, como IaaS, PaaS e SaaS, vemos diferentes doses de entusiasmo. Por exemplo, ao falar em IaaS, temos os “pure play”, como as empresas da Internet como Amazon e Google, que aproveitam seu imenso parque computacional, já gerenciado em nuvem, para prover parte desta capacidade para clientes externos e portanto ansiosos para disseminar o conceito. Mas também temos os provedores de outsourcing, que buscam atualizar seu portfólio de ofertas, mas tentando encontrar o ponto de equilíbrio, para não canibalizar suas ofertas atuais. Em software vemos este mesmo cenário. Os primeiros provedores de SaaS foram empresas criadas com este objetivo, como a Salesforce, enquanto os fornecedores tradicionais ficaram à espera para ver o que ia dar. A IBM é um caso peculiar. É uma empresa que atua no mercado tradicional de TI, obtendo receitas imensas com outsourcing, venda de hardware e licenciamento de software on-premise, mas que consegue, apesar de seu imenso tamanho (mais de 400.000 funcionários no mundo todo), agir com rapidez e se colocar como forte player em novos segmentos. Está sendo assim com Cloud Computing. Sugestão: acompanhem de perto as estratégias e ofertas de Cloud Computing da IBM.

 Na minha opinião, o que veremos nos próximos anos será a operação conjunta dos modelos atuais e o de cloud computing, uma vez que será praticamente impossivel uma grande corporação mergulhar de cabeça em uma mudança estilo Big-Bang. Veremos nuvens híbridas, com parte de aplicações e infraestrutura operando em nuvens privadas e parte em nuvens públicas, e mesmo alguns servidores e aplicações sendo ainda operados da forma tradicional.

 Como se preparar para este novo tsunami? O SaaS, por exemplo, oferece uma liberdade muito grande aos gestores de linhas de negócio que estejam insatisfeitos com os tempos de entrega do setor de TI de suas empresas. Com simples pesquisas aos “application markets” como o AppExchange da Salesforce e mesmo com o desenvolvimento de aplicações mashup, que não demandam pós-graduados para serem escritas, podem, com muita rapidez terem seus anseios satisfeitos. Bypassando a área de TI.

 Mas existe um risco incubado. A adoção livre e irrestrita de soluções em SaaS podem gerar problemas de integração com sistemas legados e mesmo entre si. O que fazer? Impedir  adoção de aplicações SaaS? Nem pensar. O setor de TI não conseguiu segurar a onda do modelo cliente-servidor, que começou nas áreas usuárias e só depois é que foi relutantemente aceito (o mesmo aconteceu com as aplicações web), e não terá cacife para segurar o fortíssimo apelo do modelo Cloud e SaaS.

 A sugestão é criar um modelo de governança que permita gerenciar de forma eficaz as iniciativas de aquisição e gestão de cloud computing, sejam IaaS ou SaaS, que inevitavelmente se espalharão pela organização. O preço de não fazer isso será um TCO mais alto. Haverá um alto risco de milhares de usuários acessando diversas nuvens publicas diferentes com os inevitáveis problemas de  integração e eventuais quebras dos protocolos de segurança e auditoria da empresa. Portanto, as áreas de TI não devem ficar à margem do Cloud Computing. Devem criar politicas de governança de Cloud Computing, explicitando os procedimentos de seleção, aquisição e utlização. Ficar à espera signfica deixar uma bomba relógio ser armada, pois mais cedo ou mais tarde os problemas cairão no seu colo. É muito mais inteligente prevenir que remediar a situação.