Cloud Computing: Status Quo

setembro 12, 2011

Outro dia, almoçando com dois amigos, CIOs de grandes empresas, a conversa girou em torno do tema cloud computing. Eles me questionaram muito do porque cloud está demorando tanto para decolar, uma vez que o termo surgiu em 2007, e nestes cinco anos pouca coisa andou. Conversa vai, conversa vem, chegamos a algumas conclusões e insights interessantes que vou compartilhar aqui.

Está claro que apesar das coisas não estarem indo muito rapido, o conceito de cloud não é mais visto como um hype de mercado, mas como um novo modelo de aquisição, entrega e consumo de recursos de TI (em todas suas variantes, como IaaS, PaaS e SaaS) que provocarão transformações significativas tanto nas empresas produtoras como nas consumidoras de TI.
Cloud não é uma invenção tecnológica, mas seu conceito é construído em cima de tecnologias já provadas há muito tempo, como virtualização, software como serviço (lembram-se do ASP?), intensa disseminação da Internet (todos usam Internet Banking), outsourcing de infraestrutura (até bancos fazem isso) e terceirização dos ambientes de desenvolvimento e testes (muitas grandes empresas já terceirizam intensamente estes processos).

Portanto, cloud é uma mudança no modelo de entrega e consumo de TI, mas não um conjunto de tecnologias e conceitos não testados. Facilita as coisas. Além disso, o sempre presente mantra do “fazer mais com menos” continua presente e as empresas estão continuamente em busca de reduzir e racionalizar seus custos de TI, obter maior flexibilidade e velocidade na obtenção dos recursos necessarios a desenvolver alguma ação de negócios. Cloud é a resposta. Juntando tudo, vemos que mais cedo ou mais tarde cloud vai decolar, pois é realmente uma grande idéia.

Um dos motivos que estão atrasando a decolagem é que ainda existe muita confusão sobre o que é realmente cloud. Tenho participado de dezenas de reuniões e eventos sobre o assunto e vejo, com certo espanto, que muitas empresas ainda não estão bem familiarizadas com o conceito. Existem ainda muitas discussões e divergências sobre o que é realmente cloud. Muitas ainda associam o conceito de cloud exclusivamente ao de cloud publica, ignorando as alternativas de cloud privadas e híbridas. E algumas chegam a afirmar que já estão usando cloud, simplesmente porque virtualizaram alguns de seus servidores. Outro motivo é que, de maneira geral a maioria das empresas tem uma área de TI muito conservadora, sendo bastante reativos a qualquer nova tecnologia ou conceito que cause disruptura no seu dia dia. Geralmente adotam novas tecnologias apenas quando elas já provaram sua eficácia e estão relativamente bem maduras no mercado. Basta ver a relutância com que muitas empresas olham as midias sociais e mesmo o uso de tablets e smartphones para aplicações de negócio.
Contribuindo para isso, a maioria dos tradicionais fornecedores de tecnologia tendem a oferecerem soluções para nuvens privadas, vendendo-as pelos modelos tradicionais de precificação, ou seja, aquisição de ativos pela empresa compradora.

Isto me lembra a situação de um livro que li em 2001 e que me marcou muito: “The Innovator’s Dilemma”, de Clayton M. Christensen. O livro aborda o fracasso de empresas ao se defrontarem com mudanças que causam disrupções nos seus mercados. Analisa empresas de sucesso que não conseguiram inovar na velocidade adequada e ficaram para trás. Cita diversas empresas de renome como Sears Roebuck, e na área de TI nomes outrora famosos como Digital, Data General, Wang e outras.

Uma parte muito interessante do livro é a proposição dos cinco princípios ou leis das tecnologias de disrupção, que ao serem ignoradas enfraquecerão as empresas que atuam nos setores afetados. Estes princípios ou leis são:

Princípio 1: As companhias dependem de clientes e investidores para gerar recursos. Ele observa que as empresas mais bem sucedidas em um paradigma criam mecanismos muito eficientes para abortar idéias que não agradam a seus clientes e investidores e como resultado tendem a não investir em tecnologias de disrupção, que geram oportunidades de lucros menores e que seus clientes não querem, pelo menos inicialmente. Quando eles passam a querê-las, aí é tarde. Outras empresas já dominam o mercado destes produtos.

Princípio 2: Mercados pequenos não solucionam a necessidade de crescimento de grandes empresas. Tecnologias de disrupção possibilitam o surgimento de novos mercados, geralmente pequenos no seu início. As grandes corporações precisam de receitas gigantescas e não conseguem entrar em mercados que geram receitas menores. De maneira geral sua estratégia é esperar até que estes mercados sejam grandes o suficiente para se tornarem atrativos.

Princípio 3: Mercados que não existem não podem ser analisados. Não existe pesquisa de mercado para eles. Empresas cujos processos de investimento demandam a quantificação dos tamanhos dos mercados e dos retornos financeiros, antes que possam entrar em um mercado, ficam paralisadas ou cometem sérios erros de avaliação ao se depararem com tecnologias de disrupção.

Princípio 4: As capacidades de uma organização definem suas incapacidades. O autor observa que as capacidades de uma organização concentram-se em dois fatores. O primeiro está em seus processos e o segundo nos valores da organização, critérios que os executivos e gestores utilizam quando tomam decisões sobre as prioridades. Mas um processo eficiente para um determinado tipo de produto pode ser muito ineficiente quando temos um produto baseado em uma tecnologia de disrupção. Além disso os valores fazem com que as decisões priorizem projetos de desenvolvimento de produtos de alta margem, deixando em segundo plano os de baixa margem, como os que envolvem tecnologias inovadoras.

Princípio 5: A oferta da tecnologia pode não ser igual à demanda do mercado. Apesar de inicialmente poderem ser utilizadas apenas em mercados pequenos, tecnologias de disrupção produzem rupturas porque podem posteriormente ter desempenho plenamente competitivo dentro dos mercados habituais, em comparação com produtos já estabelecidos. O autor observa que o ritmo da evolução dos produtos frequentemente excede a taxa de melhoria do desempenho que os clientes habituais procuram ou podem absorver. Estes produtos apresentam excesso de desempenho. Assim produtos, que apresentam no início características de funcionalidade que estejam próximas das necessidades do mercado atual seguirão trajetórias de melhorias que os fará superar as necessidades dos mercados habituais no futuro, oferecendo desempenho altamente competitivo, substituindo os produtos pré-estabelecidos.

Se enquadramos cloud computing nos princípios acima e como muitas das empresas do setor reagiram ou ainda estão reagindo vamos ver que haverão vencedores e perdedores. Faz parte da vida empresarial…

Mas, na minha opinião pessoal, estamos próximos do ponto de inflexão. Por que? Vejo a cada dia mais interesse pelo assunto. O crescente numero de eventos sobre o assunto demonstra isso. Além disso, muitas empresas já estão adotando virtualização de forma intensa, o que é o primeiro passo na jornada em direção a cloud. Outras já estão acostumadas com outsourcing. Assim, acredito que em 2012 ou 2013 cloud computing vai ser adotado de forma mais acelerada, com as empresas fazendo cada vez mais provas de conceito e implementações piloto.
Estas primeiras experimentações serão a colocação de ambientes de email, colaboração e ferramentas de produtividade em nuvens. Também veremos atividades como ambiente de desenvolvimento e teste, bem como aplicações especificas de BI em nuvens. À medida que os cases de sucesso se espalhem e os resultados obtidos, como maior agilidade e flexibilidade no provisionamento e alocação dos recursos computacionais sejam realmente comprovados, cloud vai ser adotado com mais intensidade. Já veremos cloud nos budgets de muitas empresas a partir de 2012.

Os resultados positivos vão demandar novos projetos e cria-se um efeito virtuoso. Creio que em torno de 2020, ou seja, daqui a dez anos, o termo cloud computing deixará de existir, e sim será apenas computing, pois cloud será o nosso modelo mental de pernsarmos aquisição e uso de TI.

Claro que ainda existirão pedras no caminho. Uma delas é a questão da segurança, privacidade e confidencialidade dos dados, bem como as ainda incertezas juridicas e tributárias, principalmente quando fala-se em clouds publicas com data centers localizados em outros países. Em grandes empresas, principalmente as de setores mais regulados, esta questão torna-se mais séria, pois seus departamentos jurídicos e financeiros tem maior poder de veto dentro da organização.

Por outro lado, se área de TI ficar esperando a computação em nuvem amadurecer para então se mover, poderá perder seu espaço. A chamada “Shadow IT” ou computação invisível torna-se mais forte em ambiente de nuvem. Eu questiono a afirmativa de muitas empresas que dizem que sua área de TI tem total controle sobre o que os usuarios adquirem e acessam em termos de TI. Um exemplo é a proibição de se usar midias sociais dentro da organização. OK, é proibido pelo desktop corporativo mas o funcionário acessa seu Facebook ou tuita algo pelo seu smartphone ou tablet. Na conversa com meus amigos CIOs isto ficou claro. Eles já disseram saber de vários casos (e confessaram, até mesmo dentro de suas empresas) das áreas de negócio cada vez mais adquirirem serviços diretamente via Internet. A questão não é mais tecnológica. Não dá mais para proibir tecnologias que surgem à velocidades mais rapidas que a capacidade das áreas de TI a absorverem, mas de definir claramente politicas e processos de aquisação de aplicações e tecnologias. TI tem que ser aliado e facilitador e não o controlador dos recursos computacionais.

Anúncios

Com a cabeça nas nuvens…

agosto 31, 2011

Há alguns dias participei de mais um evento sobre Cloud Computing. Aliás, no decorrer dos últimos anos participei de incontáveis eventos e reuniões com clientes para debater este assunto. Participei também de vários projetos proof-of-concept. Vi e ouvi muita coisa nestas ocasiões e aproveitei uma caminhada em torno da lagoa Rodrigo de Freitas (moro no Rio) para filosofar um pouco sobre o assunto.

Na minha opinião cloud não é apenas um upgrade tecnológico para os data centers, mas uma mudança de paradigma em como provisionamos e usamos recursos computacionais nos data centers. Hoje provisionamos e utilizamos servidores. Em cloud, o servidor é o data center. Cloud computing implica uma mudança significativa na maneira como vendemos e consumimos produtos e serviços de tecnologia da informação e, apesar de muitos eventos e debates sobre o assunto, ainda paira uma certa descrença sobre seus impactos. Assim, creio que será interessante debater um pouco mais os desafios que as empresas, tanto fornecedoras como consumidoras de tecnologia, terão pela frente.

As decisões de quando adotar cloud (a pergunta “se”, já foi respondida…Cloud será adotado, mais cedo ou mais tarde) demandam uma análise dos benefícios versus os riscos e os efeitos da computação em nuvem na empresa. E a decisão tem relação direta com o grau de maturidade não apenas da tecnologia disponível no mercado, mas da organização e cultura da empresa.

Vamos olhar por exemplo as grandes corporações. Elas são inerentemente complexas e para cloud gerar um valor real deve abranger muito mais que ser uma plataforma para um ambiente isolado, como o de desenvolvimento e testes de aplicações. Este deve ser apenas o primeiro passo e deve estar inserido em uma estratégia maior. O cerne da questão: estratégia de cloud não deve ficar apenas nas mãos de TI, mas deve envolver a organização. Por outro lado start-ups não tem que lidar com sistemas legados e podem entrar direto no ambiente de cloud. Não tem sentido uma empresa começar a operar emulando o modelo atual de sistemas on-premise, instalando hardware e software dentro de casa.

Se olharmos cloud veremos que o atual modelo de entrega de recursos de TI se assemelha ao modo como era a energia elétrica no principio do século passado. As indústrias tinham que construir e manter suas fontes geradoras de energia, que não eram o seu negócio. Hoje a maioria das empresas constróem e mantém seus próprios data centers, mesmo que não sejam seu campo de expertise. O resultado? Muitos data centers são ineficientes. Recomendo a leitura de uma série de artigos publicados em 2008 (mas ainda bem atuais) pelo The Economist em http://www.economist.com/node/12411882. O modelo de computação em nuvem pode, potencialmente, mitigar esta ineficiência, permitindo que recursos como servidores e storage sejam entregues e usados como serviços, assim como energia elétrica. Ora, porque Cloud não pode ser visto como uma utility, como uma concessionária de energia elétrica?
Vamos analisar quais os pontos em comum entre um serviço de utility como energia, água e telefonia, e a computação em nuvem. Quais são as características básicas de um serviço de utilidades, como água, energia e telecomunicações?
Logo no início lembramos da alta dependência do serviço. Não podemos viver sem água ou energia. Basta ver os efeitos de um apagão elétrico na sociedade, os transtornos que causa.
Outra característica é a confiabilidade no serviço. Água, por exemplo; ao abrirmos a torneira nossa expectativa natural é que a água caia. Não se espera que o serviço não esteja disponível.
Usabilidade é outra característica. Uma torneira é muito fácil de usar. Uma tomada só necessita que se conecte o plug do aparelho elétrico. Um celular é algo que uma criança de dois anos sabe usar para fazer uma ligação.
E, outro aspecto relevante é a elasticidade. Pagamos estes serviços pelo que consumimos e sabemos que podemos consumir mais ou menos. Podemos consumir muita energia no verão carioca, com aparelhos de ar condicionado ligados 24 horas por dia, e deixar a casa às escuras quando saimos em férias.
Para o provedor existe uma outra característica relevante que é o nível de utilização. Ele precisa gerenciar os picos e vales pois as demandas dos usuários dos serviços de utility flutuam amplamente no tempo. Se ele mantiver uma infraestrutura configurada para a demanda de pico, vai arcar com um custo elevado. Por outro lado, se a infraestrutura for insuficiente, não irá atender à crescimentos rápidos da demanda.
E quanto aos modelos de negócios? Basicamente as utilities cobram pelo uso (pay-as-you-use), como água e energia, ou por assinatura, como provedores de banda larga, que ofertam serviços ilimitados mediante assinatura mensal.
Mas, como é a TI na maioria das empresas? Bem diferente deste modelo de utilities. Até a questão do pay-as-you-go vai demandar um maior amadurecimento dos processos e cultura. TI é visto muitas vezes como centro de custo e não como gerador de negócios. Não existe billing dos seus serviços entre os departamentos da empresa e muitas vezes nem mesmo existe rateio proporcional à suas demandas.

Cloud computing também afeta as relações entre a área de TI e seus usuários. Vamos recordar um pouco a história recente da computação. TI ganhou importância nas empresas porque a tecnologia demandava expertise para programar e controlar as aplicações. Na época do modelo centralizado, TI dominava 100% das atividades de computação nas empresas. Com a chegada dos PCs, os usuários passaram a ter condições de desenvolver eles mesmos muitas das suas aplicações e o controle abosluto de TI começou a ruir. Muitas aplicações não eram mais escritas pelos técnicos de TI, mas compradas prontas ou escritas pelos usuários em linguagens de alto nível, que abstraiam as tecnicidades. Com o PC, TI passou a ser o coordenador do acervo computacional, mantinha os sistemas corporativos e se responsabilizava pelos processos de segurança, backup etc. Mas não era mais o único desenvolvedor de aplicações.

Este processo está se acelerando com a chegada dos tablets, smartphones e a computação em nuvem. Os usuários podem agora substituir sistemas antes providos pela área de TI por aplicações disponíveis em nuvens publicas. É o processo de desintermediação. TI tem que assumir outro papel: o de coordenar e monitorar o uso de nuvens e até mesmo gerar processos de certificação de que serviços podem ser obtidos de quais provedores de nuvem. De qualquer maneira está claro que a influencia dos usuarios no uso e adoção de computação nas empresas é cada vez maior e TI será obrigado a mudar seu papel de provedor de recursos computacionais para certificador e consultor.

Vamos exemplificar o novo cenário? Hoje, um departamento usuário que demande uma nova aplicação vai requerer de TI a aquisição dos equipamentos, como servidores e banco de dados. O processo de compras e instalação pode levar alguns meses. Mas com cloud ele pode ir direto ao provedor e adquirir na nuvem servidores virtuais e aplicativos SaaS, pagando com seu próprio budget, sem passar pela área de TI. Desta forma ele bypassa os processos e procedimentos de segurança adotados por TI e pode gerar problemas futuros, mas consegue ter resultados de negócio em curtíssimo prazo, o que agrada aos acionistas!

O que TI deve fazer? Entender o cenário e não remar contra, mas assumir o quanto antes seu novo papel neste contexto. E tem muito trabalho pela frente: por exemplo, como agir diante de uma falha em uma nuvem pública? Os usuários não pensam neste assunto, mas estarão dependentes de suas aplicações em uma nuvem que pode sair do ar. O que fazer? Se uma empresa colocar todos seus sistemas em uma nuvem pública, perderá a expertise técnica que detém hoje em sua área de TI, e ficará nas mãos do provedor. Este provedor tem expertise suficiente para responder aos problemas que eventualmente surgirão? Esta é outra questão que TI tem que agir agora: selecionar e certificar provedores de nuvem.

A questão de custos tem que ser analisada com cuidado. De maneira geral olha-se os custos de uma nuvem publica observndo-se os custos de hora de servidor. Mas, os custos de trasmissão de dados? Além disso, à medida que os modelos de serviços de cloud evoluem, novas modalidades de pagamento surgem e o planejamento de capacidade ajuda a identificar qual seria a melhor opção. Não é dificil imaginar no futuro vermos o mercado de provedores de clouds públicas ofertando recursos com preços diferenciados, de acordo com o período do dia ou do mês. Aliás, já vemos alguns primeiros exemplos desta prática, como o modelo spot pricing da Amazon. Neste modelo você faz um leilão para usar recursos ociosos da nuvem da Amazon. Imagine que você queira pagar até 1 dólar por hora de servidor. A Amazon flutua o preço hora de servidor de acordo com a demanda. Vamos supor que o preço de hora de servidor esteja, em determinado momento a 75 centavos de dólar. Neste momento, a Amazon verifica quais usuários querem participar do leilão e quais deles oferecem preços de 75 centavos ou acima. Como voce definiu que pagaria até um dólar, você é um candidato a participar do leilão e eventualmente sua máquina virtual é selecionada e alocada. Ela fica operando até que o preço hora do servidor suba (pelo aumento da demanda) e seu preço de até um dólar fica abaixo do valor. Neste momento o seu servidor virtual é colocado em stand by. Claro que nem todas aplicações podem usufruir desta funcionalidade. Temos, portanto, mais uma atividade que necessita de expertise técnica que a empresa não pode desprezar.

Outros temas que precisam ser bem avaliados quando decidindo adoção da computação em nuvem são as questões que envolvem a segurança, privacidade e aspectos legais. Métodos e processos de segurança mudam a cada vez que o modelo computacional muda. Foi assim quando surgiu o cliente-servidor e muitos dos métodos adotados para ambientes centralizados tornaram-se inúteis. Foi assim quando a Internet passou ser parte integrante dos processos de negócio e os métodos adotados para segurança internos mostraram-se insuficientes e tiveram que ser modificados. Com adoção de cloud computing a história está se repetindo. Temos que repensar muitos dos processos de segurança atualmente adotados.

Um provedor de nuvem publica pode ser alvo de ataques como denial of service (DoS) e este ataque pode ser direcionado a alguns (ou algum) alvos especificos. Ou seja, o ataque não é dirigido ao provedor mas a um dos clientes dentro do provedor. Neste caso, qual é velocidade de reação do provedor diante desta situação?Tem um case conhecido, antigo, de 2009, mas que serve de orientação para casos similares. Vejam em http://blog.bitbucket.org/2009/10/04/on-our-extended-downtime-amazon-and-whats-coming/ . Para questões de segurança em cloud recomendo acessar a Cloud Security Alliance, em https://cloudsecurityalliance.org/ . Recomendo também acessar o site da ENISA (European Network and Information Security Agency) para um relatório muito abrangente sobre segurança em cloud computing, em http://www.enisa.europa.eu/act/rm/files/deliverables/cloud-computing-risk-assessment . Como TI pode se envolver nas questões de segurança em cloud? Por exemplo, analisando os provedores e avaliando se suas práticas de segurança se adequam as políticas de compliance da empresa.

Como vemos, tem muito espaço para TI atuar no mundo da computação em nuvem. Portanto, ao invés de receios, TI deve ver na computação em nuvem grandes oportunidades, deixando de lado atividades que não agregam valor (instalar hardware e sistema operacional) e considerado como centro de custos, para ser visto como facilitador de novas receitas e novos negócios.

Cloud como estratégia de negócios

agosto 22, 2011

A adoção de cloud computing começa a se acelerar no mundo inteiro. Mas as primeiras experiências já apontam que uma substituição completa do modelo tradicional pela computação em nuvem não acontecerá no curto prazo. Por outro lado as razões iniciais que incentivam a adoção de cloud, como redução de custos, começa a ser substituída pela agilidade com que o negócio passa a dispor quando usando este modelo para criar novos e inovadores processos e aplicações.

O modelo de computação em nuvem está apenas começando a impactar as empresas e a própria indústria de TI. Mas ainda desperta desconfiança e muitas empresas aguardam cautelosamente que os “early adopters” mostrem o caminho. É normal este cenário. Afinal, muita coisa se disse sobre o modelo distribuído, que usamos atualmente, e nem tudo prometido aconteceu realmente. Aliás, fazer previsões é sempre arriscado. Tem uma frase emblemática do prêmio Nobel de Física, Niels Bohr que disse “Prediction is difficult, especially about the future”. E volta e meia nos deparamos com previsões furadas, como “Quando a exposição de Paris se encerrar, ninguém mais ouvirá falar em luz elétrica.” (Erasmus Wilson, Universidade de Oxford, 1879) e “A televisão não dará certo. As pessoas terão de ficar olhando sua tela, e a família americana média não tem tempo para isso.” (The New York Times, 18 de abril de 1939, na apresentação do protótipo de um aparelho de TV).

Por que estas coisas são ditas? São pessoas ignorantes? Não, são cientistas e profissionais bem preparados. A questão é que partem de pressupostos errados. Lembro aqui uma histórinha interessante. Em 1886, Gottlieb Daimler tinha acabado de desatrelar os cavalos de uma carruagem e instalar um motor atrás dela. Criou o primeiro automóvel (ou carruagem sem cavalos). A empresa dele se juntou à de Karl Benz e no começo da década de 1900, tentaram prever o tamanho do mercado mundial para estes então fumacentos e barulhentos veículos. Depois de uma análise cuidadosa previram que no próximo século haveria em torno de um milhão de carros em uso no mundo inteiro. Mas, esta previsão, audaciosa para a época, se mostrou totalmente equivocada. Em 2000 haviam mais de 600 milhões de carros no mundo! Era uma previsão de longo prazo, sujeito a intempéries, mas mesmo assim erraram por um fator de mil. Por que? A suposição que usaram estava errada. Eles previram que em cem anos a população mundial de motoristas profissionais seria de cerca de um milhão e esta seria a limitação ao crescimento no uso das carruagens sem cavalo. O pressuposto era que todo carro precisava de um motorista profissional, como na época. Não foi o que aconteceu. Qualquer um pode dirigir um carro.

O mesmo acontece quando olhamos cloud computing pela ótica do modelo atual de TI e nos prendemos a visualizar este modelo como uma simples modernização do outsourcing. Mas, a possibilidade de uma empresa criar novos processos e mesmo negócios sem esperar pelo ciclo tradicional de TI, e mesmo sem maiores investimentos em capital, mas apenas em custos operacionais (opex) abre novos e inovadores espaços a serem explorados. Cloud pode ajudar a transformar o próprio negócio. Portanto, o modelo de computação em nuvem não deve ser visto únicamente pela ótica da tecnologia, mas como um meio estratégico de alavancar novos negócios.

Entretanto, a mudança não ocorrerá por um “big bang”, mas de forma gradual. Existem ainda barreiras no caminho e aspectos legais e de compliance ainda criam riscos para o negócio. Muitos dos provedores não tem soluções completas e as experiências práticas bem sucedidas ainda são cases de mídia. Por outro lado, ficar sentado e esperar as coisas acontecerem pode deixar passar ao largo boas oportunidades de vantagens competitivas. Além disso, falando francamente, os data centers de alguns provedores globais de cloud são muito mais avançados e seguros que a maioria dos data centers das empresas. Então, o que fazer?

Na minha opinião as empresas devem olhar cloud pela ótica da estratégia do negócio e começar a experimentar este modelo. Se a organização já tem familiaridade com outsourcing, cloud passa a ser uma extensão natural de sua TI. O modelo híbrido, onde aplicações on-premise convivem com nuvens privadas e nuvens públicas será o caminho natural para muitas empresas. Expandindo os sistemas atuais para operar em nuvem, mantendo ainda os dados mais sensíveis dentro de casa é um bom caminho. Desta maneira ganha-se experiência e aos poucos descola-se do modelo tradicional e cloud passará a fazer parte do DNA de TI da empresa.

A velocidade de adoção da computação em nuvem vai depender da cultura e do setor de indústria de cada companhia. Existem setores mais regulados e empresas mais agressivas em adotar inovações. Não existe uma receita única e pronta que se adapte todas as organizações. Por exemplo, uma empresa pode começar por colocar a maioria dos sistemas não-ERP em nuvem e com isso, ao mesmo tempo que reduz seu custo operacional, pode conseguir de imediato uma maior agilidade para novas demandas de TI por parte dos usuários. Mas, os resultados não virão apenas com adoção tática de cloud. É fruto de uma combinação da reorganização de TI, de pensar de forma mais ágil (agile development) e não se ater a atividades operacionais básicas, padronizando e automatizando seu ambiente operacional (cloud computing).

Bem, algumas sugestões:

a) Entenda a natureza do modelo de computação em nuvem e como explorar este novo modelo com novas aplicações. Não pensar em usar as nuvens apenas para fazer a mesma coisa que se faz hoje.
b) Pense nuvem arquitetônicamente ou seja, não pense em peças tecnológicas isoladas, mas visualize seu futuro ambiente em nuvem, analisando aspectos de segurança, interoperabilidade e agilidade nos processos de TI.
c) Adote cloud computing como seu modelo de design de aplicações para novos e inovadores sistemas. Mas conserve os dados mission-critical dentro de casa, pelo menos por enquanto.
d) Crie um modelo de governança de TI (politicas, procedimentos e padrões) que englobe cloud e não esqueça de colocar análises de risco nas decisões de usar cloud para as aplicações que requerem certificações como SAS70, HIPAA, etc, e niveis de serviço extremamente rígidos.
e) Não espere que o modelo amadureça. Comece a experimentar em workloads especificos e menos críticos. Embora cloud ainda seja imaturo e primitivo comparado com daqui a cinco ou dez anos, já permite fazermos muitas coisas interessantes. Um exemplo? Que tal BI em cloud? É perfeitamente prossivel construir uma plataforma em cloud pública para demandas de business analytics, provavelmente a uma fração do que custaria construir o ambiente dentro de casa.
f) E finalmente, tenha uma atitude “open-minded” em relação a cloud computing.

Criando nuvens públicas: o que é necessário?

agosto 8, 2011

Recentemente estive participando do evento Cloud Computing & Security, debatendo o panorama atual e futuro da adoção de Cloud. Após a palestra, gravei entrevista que está disponivel no YouTube (http://www.youtube.com/watch?v=1LJXtakcMR4&feature=youtu.be ) onde em cerca de 10 minutos debati algumas questões como os desafios para o Brasil se tornar um pólo atrativo para data centers de cloud, bem como algumas questões ligadas a soberania de dados. Se tiverem tempo, os convido a assistirem ao video.

Cloud Computing tem o potencial de transformar toda a indústria de TI, tanto do lado dos provedores de serviços e produtos, em como dos usuários destes produtos e serviços. Muda de forma significativa a maneira como vendemos e consumimos TI.

A criação de data centers para oferta de serviços em cloud, para o mercado em geral, chamado de public cloud, tem como característica essencial a escala do empreendimento. Para oferecer recursos computacionais a custo baixo, estes data centers tem que dispor de escala adequada para que processos atutomatizados façam diferença em relação aos modelos atuais de provisionamento e alocação de recursos, semi-automatizados. Outras variáveis impactantes são os custos de energia, capacidade de rede (pela concentração de acessos ao data center por milhares de clientes) e tecnologia que automatize ao máximo a sua operação. Quando falamos em escala adequada estamos falando em dezenas ou mesmo centenas de milhares de servidores.

Um tópico importante é a capacidade da rede para/de acesso ao cloud data center. Este pode ser um gargalo, pois ainda no Brasil cerca de 70% da banda larga é de menos de 1 Mbit por segundo. Além disso, a escassez de oferta diminui a possibilidade de oferecer redundância de redes, altamente necessária para garantir uma alta disponibilidade para os usuáios de uma nuvem pública.

O que isto significa? Que criar um data center para oferecer public cloud não é um negócio para qualquer um. Tem que haver um grande investimento inicial em máquinas e facilities e o retorno não aparece no curto prazo. Como a receita vem de serviços por demanda (pay-as-you-go), a empresa tem que ter fôlego suficiente para sustentar os altos investimentos durante algum tempo, até que o break-even seja alcançado.

Outra questão debatida na entrevista foi a soberania de dados, que, inclusive foi tema de um post anterior aqui no blog: (https://computingonclouds.wordpress.com/2011/07/19/soberania-de-dados-em-cloud-computing/) .

Enfim, o assunto ainda gera muito debate, mas é inevitável que é um caminho sem volta. Entender as possibilidades e as restrições do atual ambiente de cloud computing no Brasil é fundamental para que as empresas, sejam elas usuárias ou provedoras de serviços, definam suas estratégias para os próximos anos.

Cloud Computing e a “TI Invisível”

agosto 1, 2011

Um fenômeno muito interessante que ocorre em muitas das médias e grandes empresas é a chamada “IT invisível”, que são as tecnologias e serviços adquiridos pelos usuários das áreas de negócio, com seus próprios budgets, à sombra de TI. Este fenômeno surgiu com o advento do modelo client-server, que permitiu que áreas usuárias comprassem pequenos servidores e aplicativos departamentais, sem que TI soubesse, se acelerou com o advento da Internet e agora vemos potencializado pela computação em nuvem.

Vamos imaginar um cenário hipotético. Um executivo da linha de negócios precisa de um sistema de gestão de frotas. A resposta que ele ouve do CIO provavelmente será: “Não tenho budget para desenvolver este sistema internamente, mas vá ao mercado e selecione um aplicativo que seja adequado e depois volte aqui”. Ele assim o faz. Pesquisa o mercado e seleciona um dentre vários aplicativos. Volta ao CIO, mostra o aplicativo e ouve: “Muito bem, mas o aplicativo roda em Windows e meu ambiente é Linux. Terei que adquirir um servidor, banco de dados e outros softwares que serão necessários para operar o sistema. Além disso, terei que contratar um administrador para este novo ambiente. Tudo isso vai demorar uns 3 meses”. Resultado: ele vai gastar o dobro do planejado e terá que esperar muito tempo, após aportar seu budget para usufruir da funcionalidade oferecida pelo aplicativo na sua empresa.

Outra coisa que ele poderá fazer: buscar aplicativos oferecidos na modalidade SaaS e adquirir um diretamente, bypassando por completo TI. Caso a empresa tenha o CRM da Salesforce ele poderá ir ao AppExchange (http://appexchange.salesforce.com/home) e selecionar um dentre vários aplicativos. Hoje o AppExchange funciona para apenas aplicativos que rodem na nuvem do salesforce, mas nada impede o surgimento de outros mercados, como vemos no setor de aplicativos móveis com Android market, Appstore, etc.

O que o CIO deverá fazer? Lutar contra? Será quase impossível ganhar a guerra, pois o apelo econômico do modelo de computação é extremamente atrativo para ser ignorado e com mais e mais disponibilidade de ofertas em nuvem, os usuários buscarão atender suas próprias demandas passando por cima das barreiras impostas por TI.

A área de TI deve compreender que ela e os usuários tem prioridades diferentes quando adquirindo serviços e produtos de tecnologia. TI se preocupa primeiramente com questões de segurança e compatibilidade do novo aplicativo com o ambiente operacional. Os usuários priorizam a funcionalidade do aplicativo e deixam em segundo plano estas questões “técnico-mundanas”. O atual modelo on-premise cria algumas barreiras, pois mesmo que o usuário adquira um aplicativo de forma independente, muitas vezes TI tem que entrar no circuito para instalar o servidor e seu ambiente operacional. Em nuvem, TI não é necessária. O usuário interage diretamente com o provedor da nuvem e adquire o serviço com cartão de crédito. O acesso a vastos e baratos recursos computacionais como servidores virtuais em nuvens IaaS ou aplicativos SaaS, usando-se um simples cartão de crédito tornam as coisas mais fáceis para o usuário bypassar TI.

À medida que este hábito se espalhar pela organização, teremos uma bomba relógio. Provavelmente muitos destes aplicativos deverão interoperar com outros que estejam em outras nuvens ou mesmo on-premise em servidores gerenciados por TI. Como fazer esta interoperabilidade acontecer? Além disso, até que ponto os usuários se preocuparam com questões como backup ou aspectos legais quanto a privacidade e soberania dos dados?

Portanto, TI não pode e nem deve abdicar da responsabilidade de manter as tecnologias operando de forma segura e sempre disponivel. Mas, na minha opinião o atual modelo de controle de TI, extremamente restritiva, baseado no modelo de aplicativos e recursos computacionais on-premise, terá que ser flexibilizado. Em tempos de midias sociais, smartphones e tablets não dá para esperarmos muitos meses por um aplicativo. A velocidade do negócio exige que TI responda cada vez mais rapido e assim ao invés de lutar contra, TI deverá se colocar como facilitador do processo de adoção da “TI invisível”. Esta já está acontecendo mesmo…

A área de TI deverá liderar o processo de adoção de cloud pelos usuários, propondo critérios e modelos de aquisição de recursos em nuvem, de modo a mitigar riscos para o negócio, aumentar economias de escala e garantir a integração e aderência à regras e legislações do setor. TI deve, na verdade, “legalizar” a “TI invisível” e portanto deverá atuar de forma cada vez mais integrada e aderente às demandas do negócio. Suas prioridades deverão ser as mesmas do negócio.

Soberania de dados em Cloud Computing

julho 19, 2011

Recentemente estive participando de um debate na Comissão de Estudos sobre Informática, Internet e Novas Tecnologias da ABDI (Associação Brasileira de Direito de Informatica e Telecomunicações) sobre os aspectos jurídicos que envolvem Cloud Computing. Entre os diversos assuntos abordados, destacou-se a questão da soberania de dados, principalmente quando usa-se nuvens públicas.

É uma questão de grande importância pois o uso de nuvens públicas muitas vezes pode entrar nas empresas, seja por uma aplicação SaaS ou por IaaS, para suportar projetos específicos e departamentais, sem mesmo o conhecimento da área de TI.

Um agravante é que como uma nuvem é globalmente acessivel, o aplicativo ou os servidores virtuais podem estar localizados em qualquer parte do planeta. Você pode adquirir um aplicativo SaaS sem ter idéia de onde ele estará operando com seus dados.

A questão da soberania de dados aparece como um issue pelo fato que determinados setores de indústria (como financeiro) e mesmo países demandam elevadas exigências de aderência ou compliance com obrigações regulatórias. Alguns exemplos são Austrália (http://tinyurl.com/3aux6qe) e Cingapura (http://tinyurl.com/3vv6no3) que recentemente emitiram diretivas com relação ao uso de cloud por instituições financeiras. Outras legislações ou normas como a Diretiva 95/46/EC da União Européia (http://en.wikipedia.org/wiki/Data_Protection_Directive) colocam algumas barreiras para o armazenamento de informações pessoais de cidadãos europeus em países que não estejam alinhados em termos de proteção legal com a própria União Européia. Um outro exemplo é o US Patriot Act (http://en.wikipedia.org/wiki/USA_PATRIOT_Act) que é visto por determinados países como um inibidor para armazenamento de informações de suas empresas em território americano.

O debate é intenso pois apesar destas restrições ou fatores inibidores, os impulsionadores para a adoção de nuvens públicas são significativos. A experiência nos tem mostrado que a evolução tecnológica evolui mais rapidamente que nossa capacidade de explorá-la e gerenciá-la. E os fatores regulatórios são bem mais lentos, pois eles acabam por regular os hábitos da sociedade. Como ainda não temos respostas que conciliem a oferta de nuvens globais com demandas regulatórias, veremos, na prática, surgirem aos poucos soluções conciliatórias. Um exemplo: provedores de nuvens criando data centers em diversos países do mundo, com a possibilidade do usuário determinar onde os seus dados residirão. Claro que será impossivel para um provedor global abrir data centers em todos os países, mas provavelmente veremos data centers nos principais países e regiões. Uma outra alternativa será vermos os provedores globais desenvolvendo parcerias com provedores locais, de modo a minimizar os efeitos das exigências regulatórias quanto à soberania de dados.

A questão da soberania de dados não será eliminada no curto prazo e talvez nem venha a ser no longo prazo. O que fazer então? Os CIOs não devem ignorar a realidade da computação em nuvem. Assim, se eles não conduzirem o processo poderão ter em mãos algumas bombas relógio, pois as nuvens entrarão nas empresas de qualquer modo. Portanto, desenhar uma estratégia e uma política de adoção de cloud computing será não só sensato, mas obrigatório. O primeiro passo será definir o que será localizado em nuvens públicas e o que ficará em nuvens privadas. Quando a opção de determinados serviços ou aplicações for pelas nuvens públicas, deverá ser explicitado se será necessário que os dados residam no território do país da empresa ou poderão estar em qualquer localização geográfica. Depende de cada serviço, pois nem todos os dados da empresa estão sujeitos as mesmas demandas regulatórias.

A conclusão do debate? Soberania de dados é uma questão importante, mas com uma adequada estratégia de adoção de cloud computing, que envolva a análise de riscos para cada serviço a entrar em nuvem, os problemas e seus efeitos podem ser minimizados ou eliminados. Portanto, a sugestão é ir em frente!

Almoçando Cloud…com sal e pimenta.

julho 4, 2011

Outro dia estava almoçando com um CIO de uma grande empresa que está na reta final para implementar um projeto de nuvem privada. Claro que este foi o prato principal do almoço. Como cloud computing ainda está na infância, existem muitas dúvidas e questionamentos sobre o que é possivel fazer hoje, o que realmente é concreto e o que não é. Acredito que os principais pontos da conversa podem ser compartilhados aqui.

Na minha opinião, cloud computing é uma mudança irreversível, afetando toda a cadeia de TI, dos fornecedores aos consumidores de recursos e serviços. Mas seu efeito a médio e longo prazo ainda são desconhecidos. Por outro lado, este desconhecimento nos obriga a colocar cloud nas nossas estratégias, porque se seu efeito poderá e deverá ser altamente significativo, simplesmente não podemos ignorá-lo.

A estratégia deste CIO é correta. Ele não está lutando contra, mas buscando se posicionar para melhor entender o que é cloud. O seu primeiro passo é iniciar um projeto piloto para tentar colocar um pouco de ordem na confusão do que é cloud hoje. Esta confusão é causada não só pelo simples fato que estamos nos estágios iniciais de uso de cloud, mas também porque muitos fornecedores divulgam suas próprias visões de cloud, muitas vezes conflitantes entre si. Ainda existe muito hype sobre o assunto.

Um ponto que me chama atenção é o foco excessivo no discurso que cloud afeta apenas TI, reduzindo custos, como se fosse uma simples extensão do processo de virtualização. Mas, vejo claramente que em breve veremos pela frente o conceito de “cloud Business” onde “cloud IT” vai não apenas tornar a empresa mais eficiente operacionalmente, mas poderá abrir novas oportunidades de negócio, não possiveis sob o modelo atual de TI. Cloud não deve ser visto como um fim em si mesmo, mas como alavancador de novas oportunidades de negócio.

Na conversa destaquei o fato que, diante deste contexto, ele deveria desde agora debater mais intensamente o conceito de cloud com os executivos de negócio da empresa, não tornando o projeto de cloud um mero projeto de TI. Um futuro “cloud business” será fruto destas discussões. Ele, como CIO, deveria assumir a liderança deste movimento.

Além disso, implementar cloud em sua plenitude mudará de forma significativa a própria área de TI. As mudanças serão graduais e tenho a expectativa que o atual modelo de software on-premise não desaparecerá, mas fará parte do novo mundo “cloudificado”. Na prática o que veremos é um modelo híbrido, com empresas usando recursos computacionais on-premise e nas nuvens. Assim, na minha opinião o debate não deverá ser cloud versus on-premise mas de onde será mais eficiente e adequado para cada empresa prover suas funcionalidades computacionais. Não deve ser um jogo de tudo ou nada, mas de buscar o ponto de equilíbrio. Mas, é inegável que este cenário gera novos desafios para TI, que criou e refinou todo um modelo de governança baseado exclusivamente no modelo on-premise.

Na conversa surgiu também a sempre presente possibilidade das áreas usuárias bypassarem cloud para implementarem soluções específicas de âmbito departamental. É um risco real. Com a crescente opções de ofertas SaaS e Iaas existe a tentação de áreas usuárias, não satisfeitas com a velocidade de resposta de TI, buscarem por si soluções em nuvem. O CIO não vai poder lutar contra, mas deve assumir a liderança do processo, e assim influenciar e coordenar melhor qualquer tentativa desta natureza. Mesmo porque, mais cedo ou mais tarde, os usuarios vão demandar integração dos serviços em nuvens com as aplicações on-premise. Ignorar a situação e deixar que SaaS entre livremente pode, portanto, ser uma bomba relógio.

Como haviamos falado anteriormente nas mudanças que cloud gerará em TI, este tema voltou ao debate. Para mim as mudanças vão se dar em diversos aspectos da relação de TI com o negócio, desde o interface (menos interação face-to-face e mais automatizado), passando por mudanças nos processos de governança e portanto se refletindo na organização de TI, seus skills e modelos de funding. Operar sob o modelo de nuvem obrigará TI a repensar a maneira de como opera e entrega os recursos computacionais aos seus usuarios.

Na minha opinião a tecnologia não é a principal barreira. É claro que muitas tecnologias ainda estão imaturas, faltam padrões de interoperabilidade e surgem os inevitáveis questionamentos de segurança. Mas ao longo dos próximos anos elas vão amadurecer e deixar de serem questionadas. Foi assim com todas tecnologias. Aconteceu com os bancos de dados relacionais, que no início eram considerados ineficientes e inadequados para processamentos transacionais (lembram?). Foi assim com o modelo cliente-servidor e mais recentemente com a Internet se entranhando nas operações do negócio, como no e-commece e Internet banking.

Um dos novos desafios que meu amigo CIO terá pela frente estará na mudança das políticas de governaça e alocação de recursos aos usuarios. A nuvem privada não é ilimitada. É restrita à capacidade computacional da empresa. Claro que aos poucos o conceito de nuvens híbridas vai se consolidar e muitas das limitações impostas pelas nuvens privadas poderão ser mitigadas usando-se também recursos computacionais em nuvens publicas.

A estratégia dele é bem cautelosa. Vai começar com um ambiente controlado (desenvolvimento e teste de aplicações) e depois, pouco a pouco irá ampliando o uso da nuvem.

Lembrei a ele que existe uma curva de aprendizado no uso da nuvem por parte dos próprios usuarios e não apenas pelo pessoal de TI. Os usuarios tem que se acostumar ao novo modelo. Como o interface para provisionar e alocar recursos é simples e fácil, existe a tendência natural de se requisitar excessivamente os recursos. Mas como estes não são infinitos deve existir uma politica de pagamento (chargeback) pelo seu uso. Por exemplo, cada área usuaria poderá ter determinado limite de uso de recursos, que se excedido obrigará a este usuario liberar algum outro para solicitar um novo.

Na prática, ao contrario da imaginação, que diz que com a nuvem não existem limites, quando se fala em nuvens privadas deve ser criado um modelo de provisionamento baseado em controle e restrições. Caso contrario, o excesso de solicitações poderá ultrapassar a capacidade instalada, gerando desconforto e insatisfação. Mas, atenção, TI deverá atuar como coordenador dos recursos e não como seu guardião. O modelo de alocação e funding dos recursos em nuvem deverá ser construído em comum acordo com os usuarios e não determinado unicamente por TI. Uma sugestão é criar um algoritmo de provisionamento e cobrança que leve em conta o valor do recursos solicitado para o negócio. Na minha opinião será criado na base da tentativa e erro, pois não temos ainda expertise e experiencias suficientes em cloud para dizer qual o melhor modelo para cada empresa.

Mas, é claro que ao longo do tempo os beneficios com adoção da nuvem vão se destacar: maior flexibilidade e agilidade para provisionar recursos computacionais. A maior padronização e automatização dos processos de provisionamento e alocação de recursos computacionais reduz a demanda de trabalho manual, deslocando profissionais de TI para tarefas mais nobres e rentáveis para a empresa. A melhor utilização dos recursos implica um melhor relação de custo beneficio destes. O resultado é que a empresa poderá se tornar bem mais ágil e apta a desenvolver novas oportunidades de negócio.

Como a industria de software deve migrar para SaaS (parte 2)

junho 22, 2011

Esta é a segunda parte do post sobre como criar uma estratégia para uma empresa de software adotar o modelo SaaS. A estratégia tem que ser bem pensada, pois se algo der errado, a empresa poderá perder sua janela de oportunidade.
Bom, os principais passos que um empresário de software deve pensar ao iniciar sua jornada são:

Rever e refinar os planos de negócio. É importante rever e refinar continuamente os planos de negócio voltados ao SaaS, incorporando neles as experiências obtidas com a prática. Esta estratégia deve definir se será desenvolvida uma nova solução, a partir do zero, ou se o sistema atual será apenas modernizado. Além disso, a estratégia deve definir se a oferta SaaS será disponibilizada via data center próprio ou de terceiros e neste caso, qual será o parceiro a ser escolhido? A experiência do usuário será a somatória da qualidade do aplicativo + disponibilidade da nuvem ofertada, seja ela própria ou de terceiros. A estratégia deve definir também a velocidade com que a empresa vai adotar e disseminar o modelo SaaS. O time to market é uma variável fundamental. Entrar cedo demais acarreta o risco do pioneirismo, mas uma entrada muito tardia poderá significar perda do market share e do próprio novo mercado criado pelo SaaS. A leitura do livro de Marc Benioff, fundador e CEO da salesforce.com, citado no post anterior ajuda a desenvolver esta estratégia.

Envolver a comunidade de clientes. Muitas empresas de software não criam maiores envolvimentos com seus clientes, concentrando-se mais nos aspectos transacionais dos negócios. O modelo de serviços exige uma nova postura e o relacionamento com clientes é uma variável de extrema importância para a sustentabilidade do negócio. Para muitas empresas de software é um processo novo e ainda desconhecido. A ciência de venda de serviços é diferente da venda de produtos. A própria força de vendas deve estar mais afinada com as questões do negócio e não com tecnologia. Se o aplicativo estiver em uma nuvem, sendo ofertado em SaaS que discussão técnica será necessária?

Criar rede de serviços. O suporte ao cliente e os serviços em torno vão se tornar muito mais importantes que hoje. No modelo on-premise ganha-se pela venda da licença e pelos contratos anuais de manutenção. Em SaaS ganha-se por assinatura ou variações do modelo, como por exemplo, ofertando descontos para que o cliente faça assinatura anual pagando este serviço adiantadamente. Esta é uma maneira bem interessante de remunerar seus vendedores, sem afetar o fluxo de caixa, pois pagar a comissão na assinatura do contrato e receber mês a mês gera um buraco nas contas.

Desenhar estratégia de marketing e vendas apropriada. As propostas de valor embutidas nas campanhas de marketing e vendas, criadas para o modelo tradicional, provavelmente deverão ser refeitas. Por outro lado é importante atentar para o risco de canibalização dos clientes do modelo on-premise que optem pelo novo modelo. A estratégia de marketing deve, ao mesmo tempo, criar um road map de transição dos clientes atuais para SaaS bem como alavancar novas vendas para mercados antes inatingíveis pela oferta atual. Outra variável importante é que a própria Web torna-se um canal de vendas bem mais abrangente, pois muitas vezes o cliente pode adquirir o serviço sem contato face to face. O redesenho do site e uma participação mais ativa em redes sociais devem fazer parte da estratégia de marketing e vendas. Provavelmente, analisando a estratégia de vendas pelo conceito da cauda longa, as maiores contas terão contato direto com a força de vendas ou parceiros e a maioria dos clientes, que fazem a cauda ser longa, adquirirão o serviço via Web.

Criar e/ou participar de um ecossistema saudável. O modelo SaaS embute dentro de si uma rede de parceiros, que envolve desde a hospedagem dos aplicativos à associação com algum provedor de plataforma. Dificilmente alguma empresa de software ou ISV (independent sofware vendor), à exceção dos maiores companhias, terá condições de criar um forte marketplace e ser um “one-stop shopping”. Se não for o caso, o ISV deverá estar associado a algum ecossistema abrangente, que lhe permita crescer no mercado. Além disso, deverá incentivar e fortalecer uma comunidade de desenvolvedores, inclusive open source, que ampliem as funcionalidades de seus produtos. Um exemplo bem sucedido é o AppExchange do salesforce, que implementa uma plataforma onde empresas de software criam e disponibilizam para o mercado seus aplicativos. Na verdade, este projeto do salesforce (force.com) é criar uma platforma que permita que outras empresas (ecossistema) desenvolvam novas soluções complementares e amplie mais ainda as funcionalidade do serviço. Para isso, é importante desenhar o aplicativo como uma plataforma com APIs abertas e o modelo mais adequado para isso acontecer é SOA. Lembram-se do SOA? Pois é, em SaaS ele tem um papel muito importante.

Escolher a tecnologia mais adequada para criar um ambiente multi-tenancy. Embora seja possivel oferecer SaaS sem multi-tenancy baseado apenas em virtualização, é preferivel, na maioria dos casos, adotar um modelo multi-tenancy, devido aos ganhos de escala operacionais que este modelo proporciona. Os custos operacionais para manter SaaS baseado apenas em virtualização, ou seja, multiplas instâncias, são sempre mais altos que manter uma única instância. Soluções baseadas em virtualização geram um desafio e tanto quando for necessário fazer o roll out de uma nova versão para cada instância a ser customizada para seus clientes. Por outro lado, multi-tenancy apresenta duas vantagens importantes: economias de escala e menor custo de manutenção. Mas, é necessário analisar o custo de reescrever a aplicação para operar em multi-tenancy e colocar esta variável nos estudos de ROI. Uma alternativa é começar no mercado SaaS via virtualização, para não perder a janela de oportunidade e ao longo do tempo reescrever a nova versão multi-tenancy. No livro do Marc Benioff esta questão é bem discutida e eles optaram pela modelo multi-tenancy. Mas, é bom lembrar que o salesforce entrou direto em multi-tenancy simplesmente porque não havia versão anterior para ser mantida.

Definitivamente que em alguns anos a indústria de software deverá ter uma “cara” vem diferente da atual e as empresas de venda de produtos de software, lucrativas hoje, provavelmente estarão ganhando dinheiro com outros modelos de negócio, mais focados em serviços de consultoria e integração, ou simplesmente estarão fora do jogo.

Na minha opinião, a problemática técnica do modelo SaaS está bem compreendida, mas as mudanças nos aspectos operacionais, organizacionais e culturais são bem mais complexos e ainda pouco estudados e compreendidos. Um dos grandes grandes desafios, por exemplo, é substituir a cultura comercial do modelo tradicional que enfatiza o processo de vendas a curto prazo pelo modelo de excelência em serviços. Muitas empresas incentivam e pressionam seu pessoal de vendas a alcançar metas a curto ou curtissimo prazo, a qualquer custo, sem muitas preocupações com o “day after”. Os executivos de vendas de sucesso destas empresas também conseguiram seu espaço com este modelo, que lhes é natural. Mas, no modelo de excelência de serviços, a conversa é outra e implica em um mudança cultural e organizacional muito grande.

Além disso, SaaS deve ser encarada como estratégia empresarial e não como uma simples oportunidade de negócios a ser explorada. Abre espaço para a empresa ofertar seus serviços globalmente, não ficando mais restrita a um mercado regional.

SaaS ainda é um modelo que estamos aprendendo. Ser flexível é importante. Ou seja, mude de rota quando necessário, pois não existem ainda muitos casos de sucesso que nos permitam trilhar a jornada em direção ao SaaS com toda a segurança. Erros e acertos farão parte do nosso dia a dia por muito tempo ainda.

Como as empresas de software podem migrar para SaaS (parte 1)

junho 11, 2011

Há algum tempo atrás li o livro “Behind the Cloud: the untold story of how salesforce.com went from idea to billion-dollar company and revolutionized an industry”, de Marc Benioff, fundador e CEO da salesforce.com. recentemente o reli, pelo menos nos pontos que achava mais importantes. Eu recomendo a todos empresários de software que pretendam desenhar suas estratégias de evolução para este modelo. O modelo cloud onde SaaS é uma variação, chegou para ficar e as empresas de software terão que se adaptar, mais cedo ou mais tarde. Todo e qualquer conceito ou tecnologia que traz resultados positivos para seus usuários é adotada, tomando espaço das tecnologias e conceitos então dominantes. O modelo da industria de software atual está claramente em cheque e o modelo SaaS se mostra extremamente atraente. O livro mostra os passos, acertos e erros de criar uma empresa SaaS, sem contar com experiências prévias que mostrem o caminho.

Entretanto, aparentemente SaaS não tem tido toda a aceitação que deveria ter, pelos atrativos do modelo. Mas, é provavel que vejamos uma aceleração rapida nos próximos anos. Recorro como um dos argumentos uma frase de Ray Kurzwell, pesquisador que estuda adoção e evolução das tecnologias, que diz claramente “an analysis of the history of technology shows that technological change is exponential, contrary to the common-sense “intuitive linear” view. So we won’t experience 100 years of progress in the 21st century – it will be more like 20.000 years of progress, at today’s rate”.
Algumas estimativas apontam para um crescimento sistemático no uso de cloud computing. Um relatório da Saugatuck propõe que em 2014 45% ou mais dos novos workloads das empresas já serão operados em cloud. Fala também que 40% ou mais dos novos investimentos em TI das empresas serão direcionados para cloud e que no minimo 25% de todos os workloads rodados estará em cloud. São numeros realmente significativos e que nenhum executivo de empresa usuária ou provedora de TI deve ignorar. Este mesmo relatório alerta que, se em 2013, uma empresa não tiver expertise em cloud já estará claramente em desvantagem competitiva.

Voltando a importância da leitura do livro, imagino que um empresario da industria de software ainda esteja em duvidas de como mudar seu modelo de negócio. Afinal migrar para o mundo SaaS não será uma transição fácil e provavelmente muitas empresas de software estabelecidas, principalmente as de menor capacidade de investimento, ficarão pelo caminho.

Por outro lado, o modelo SaaS operando em uma nuvem IaaS abre perspectivas muito interessantes para novos atores ingressarem no mercado. Não é a toa que uma parcela significativa dos investimentos dos VCs (Venture capitalists) tem sido concentrada, nos últimos anos, em empresas de software estruturadas no modelo SaaS.

Mas, as empresas de software já estabelecidas não poderão ficar inertes. Precisam analisar, desenhar uma estratégia e acelerar seus investimentos neste modelo, ampliando sua oferta de produtos e serviços. Uma possivel estratégia que será adotada por muitas, para acelerar seus processos de transição, será a aquisição de empresas menores, já criadas no modelo SaaS.

Também será grande a possibilidade desta transição provocar uma onda de consolidação entre os ISVs (Independent Software Vendors ou empresas produtoras de software), com os menores sendo adquiridos pelas empresas maiores. Provavelmente veremos um cenário de poucas, mas muito grandes empresas, dominando seus ecossistemas, com empresas menores gravitando em torno de suas plataformas e marketplaces.

A transição para o modelo SaaS não é simples. Os custos de vendas e marketing ainda são muito altos. Como o modelo ainda é novidade para muitos, a maioria dos clientes ainda está testando o serviço pela primeira vez e não existem garantias que ficarão muito tempo. No modelo tradicional a troca de um software é mais complexa e o aprisionamento do usuário é quase uma regra da indústria. Quantos usuários de ERP trocam de fornecedor? No SaaS a barreira de saída é muito mais baixa. Voce poderá trocar muito mais facilmente de fornecedor.

A consequência uma competição mais acirrada e preços menores. Resultado final: margens e lucratividades menores.

Analisando o cenário das empresas de software, podemos identificar alguns desafios importantes que a transição para o modelo SaaS vai acarretar. Aliás, esta transição vai afetar a empresa como um todo, em todos seus aspectos do desenvolvimento de produtos ao processo de comercialização. E, claro, no próprio modelo de negócios. Uma grande barreira para as empresas de menor porte é que durante algum tempo (e este tempo pode ser bem longo), deverá conviver com dois modelos de negocio. E fazer esta transição não é simples, pois cada modelo tem suas próprias peculiaridades e modelos de receita. É um período de investimentos e custos elevados, ao mesmo tempo que sai da obtenção de receitas por licenças (receitas em lote, originadas pelas assinaturas ds contratos de licenciamento), para um modelo de receitas por assinatura, dispersas no tempo.

A decisão de transformar o negócio em SaaS envolve diversas decisões de negócio. Por quanto tempo conviverão os dois modelos? O que vai acontecer com a versão tradicional? Ainda existirá receita no antigo modelo ou estes produtos serão congelados em uma determinada versão? Quem serão os novos parceiros? Como conseguir uma nova rede de parceiros de negócios, com skills em SaaS? Como conviverão os parceiros dos dois modelos? Além disso é importante explorar novas oportunidades de negócio, mas evitar a canibalização das receitas atuais.

A estratégia de migração é crítica. Se o cliente for obrigado a mudar, por que continuaria com seus produtos? São nestas ocasiões que a concorrência se acirra, com ofertas tentadoras. Migrar e ao mesmo tempo preservar a base de clientes é um desafio imenso, que muitas das empresas do modelo tradicional ainda não enfrentaram.

O modelo de negócios SaaS é diferente do modelo de licenças tradicional. No modelo tradicional a lucratividade vem das taxas anuais de manutenção e não necessariamente da venda de novas licenças. No modelo SaaS a receita vem da venda de assinaturas, que em alguns casos se assemelha a venda de contratos de manutenção. Mas, as diferenças começam na escolha dos métodos de cobrança. Por usuário? Por mês? Em alguns casos, pode acontecer também de se cobrar preços baixos pelos aplicativos para incentivar o uso dos marketplaces, que, por sua vez, podem vir ser a principal fonte de receita.

A lucratividade do negócio SaaS depende de três variáveis básicas, muito similares ao do setor de telefones celulares: quanto custa atrair um novo cliente (custo de aquisição), quanto estes clientes renderão com suas assinaturas (ou a receita média por usuário ou ARPU, que significa Average Revenue Per User), e com que frequência os assinantes vão embora e precisam ser substituídos (taxa de rotatividade ou churn rate). As operadoras de celular conhecem bem este jogo.

Nos próximos anos veremos refinamentos e ajustes nos atuais modelos de pagmento baseados em SaaS. Na prática não existe um único modelo, mas diversas alternativas, como cobrança por usuário que acesse o sistema ou com base no tamanho da empresa e no seu faturamento.
Outra alternativa é por produtos processados, onde uma empresa de transporte pagaria apenas pelo número de veiculos gerenciados por um sistema de gestão de frota. Mas, outras empresas, principalmente as que tem forte presença no modelo tradicional de venda de licenças, podem adotar modelos de cobrança hibridos: os usuários que adquirem sua licença no modelo tradicional, tem direito a adquirir componentes ou extensões como serviços, a preços subsidiados e mesmo, em algumas situações, gratuitamente.

Mudar o modelo de receita vai afetar em muito as empresas que estão fortemente entranhadas no modelo de vendas de licença, principalmente as que não obtem receitas de serviços. Elas estão sendo forçadas a imaginar novas formas de resolver suas vulnerabilidades frente a esta novo contexto do mercado. Em alguns casos tendem até a atuar como instituições financeiras e cobrar juros zero de seus clientes. Outras começam a vender seus softwares em componentes menores e preços mais acessiveis.

Além das questões econômicas e financeiras, existem outras variáveis, como a arquitetura tecnológica dos aplicativos. As tecnologias fundamentais para o modelo SaaS são SOA e multi-inquilinos. Relembrando, estas tecnologias permitem que o software tenha maiores facilidades para inserção de novas funcionalidades sem perturbar os demais componentes que já estejam operando sem problemas, permite também oferecer customizações e personalizações sem impactar outros clientes (sem a necessidade do provedor manter diversas versões do software) e facilita a integração com outros serviços, sejam estes legados (nos data centers da empresa) ou aplicativos SaaS residentes em outras nuvens.

Uma variável importante é a questão operacional. Para operar o aplicativo no modelo SaaS será construída uma nuvem própria, com seus altos investimentos, ou será usada a nuvem de algum provedor de infraestrutura ofertada como serviços? Um ISV que não possui experiencia em gerenciar uma nuvem computacional, mantendo um nivel de serviços adequados, corre sério risco de entar em um campo minado. Talvez a melhor alternativa para ele seja usar a nuvem de algum provedor mais experiente. Por outro lado, usar a nuvem de terceiros cria dependências externas, fora de seu controle.

A questão cultural não pode ser subestimada. Um ISV com longa experiência na venda de softwares por licença pode precisar de uma verdadeira transfusão de DNA, para atuar no modelo de software como serviço. Muitas atuam focadas no processo de vendas, deixando em segundo plano as atividades pós-vendas, como suporte e atendimento ao cliente, que chega em alguns casos a serem bem medíocres. O que importa é fechar o contrato da venda. Já o modelo SaaS exige uma permanente ação pró-ativa junto ao cliente e a qualidade dos serviço prestado é um fator de extrema importância, para garantir a receita mês a mês.

Finalmente, temos os aspectos organizacionais. Como os serviços serão oferecidos ao mercado? Uma sugestão é avaliar a possibilidade de criar um nova unidade de negócios, com métricas e estimativas de receitas diferentes dos produtos tradicionais. Esta nova unidade, provavelmente temporária, até que o modelo se consolide, pode ser vista como uma companhia dentro da companhia, mas contando com amplo suporte da alta gerencia. Conflitos devem ser minimizados e deve ser definida uma estratégia que evite a canibalização sem controle dos produtos atuais.

Uma mudança signficativa ocorrerá nos modelos atuais de rotas-ao-mercado, afetando a estrutura de relacionamento com os canais e parceiros. Como o modelo SaaS muda os mecanismos de receita, as fundações dos contratos entre as empresas de software e seus canais também devem mudar.

No modelo atual, o canal adquire o aplicativo e o hardware necessário para operá-lo, geralmente a preços menores, agrega valor por serviços prestados e adiciona sua margem, emitindo então a fatura ao cliente. Muitas vezes o canal fica responsável também pela instalação, manutenção e suporte do aplicativo, bem como pelas suas atualizações. O modelo SaaS muda este processo, pois não existe mais contrato de licenciamento de software, não existe mais hardware a ser adquirido e nem aplicativo a ser instalado. Os relacionamentos entre as empresas de software SaaS e seus canais devem, portanto, serem repensados. Os canais que não agregam valor provavelmnte não sobreviverão neste modelo. Os canais que agregam valor devem se concentrar nos serviços que gravitam em torno do aplicativo e não mais na receita obtida pela venda do software. Deverão se transformar em empresas de serviços.

Em resumo, o que os gestores dos ISVs devem fazer diante deste cenário? Bem, isto vai ficar para o próximo post…

Conhecendo o Hadoop

maio 30, 2011

Volta e meia em eventos sobre Cloud Computing surge o termo Hadoop. Já ouvi em uma palestra que o grande desafio de desenvolver aplicações para Cloud era exatamente a complexidade no uso do Hadoop. O que gera a confusão é que o Hadoop e o MapReduce, do qual ele se originou, vem sendo usado pelas empresas de Internet, que inspiraram o modelo de cloud computing, e que precisam de escala massiva para suas aplicações, como Yahoo, Google e Facebook. Mas dizer que o Hadoop é a base para todo projeto de Cloud, absolutamente não é correto. O Hadoop é usado para aplicações analíticas de dados massivos, que não é o dia a dia das empresas que usam ou pretendem usar cloud computing.

O Hadoop foi criado pelo Yahoo em 2005 e pode ser considerado uma das maiores invenções de data management desde o modelo relacional. Hoje é um dos projetos da comunidade Apache e vem sendo adotado por empresas que precisam tratar volumes massivos de dados não estruturados. Já existe inclusive um ecossistema ao seu redor, mas ainda vai demandar algum tempo para se disseminar de forma mais ampla pelo mercado. Neste post vamos debater um pouco mais o que é e o que não é o Hadoop, seu mercado e tentar visualizar algumas tendências. Quem sabe acertamos algumas?

Mas, o que é o Hadoop? É, na pratica, uma combinação de dois projetos separados, que são o Hadoop MapReduce (HMR), que é um framework para processamento paralelo e o Hadoop Distributed File System (HDFS). O HMR é um spinoff do MapReduce, software que Google usa para acelerar as pesquisas endereçadas ao seu buscador. O HDFS é um sistema de arquivos distribuidos otimizados para atuar em dados não estruturados e é tambem baseado na tecnologia do Google, neste caso o Google File System. Existe também o Hadoop Common, conjunto de bibliotecas e utilitários que suportam os projetos Hadoop. Na pratica, para que o HMR processe os dados, eles devem estar armazenados no HDFS.

O Hadoop é um projeto Open Source, com licenciamento Apache e portanto permite a criação de um ecossistema de negócios baseados em distribuições especificas. E o surgimento de serviços em nuvem, como o Amazon Elastic MapReduce, permite às empresas tratarem dados massivos sem demandar aquisição de servidores físicos. Neste modelo, o usuário escreve a aplicação Hadoop e a roda em cima da nuvem da Amazon.

A base das distribuições Hadoop é a comunidade Apache. Diversas empresas vem contribuindo com código para seu desenvolvimento como a Yahoo, Facebook, Cloudera, IBM e outras. Em torno do código base, surgem as distribuições, como Cloudera (www.cloudera.com) e DataStax (http://www.datastax.com/brisk), que agregam valor com utilitários e serviços de suporte e educação, no mesmo modelo das distribuições Linux. Interessante que a distribuição da DataStax, chamado de Brisk, substituiu o HDFS por um sistema de arquivos distribuidos baseados no software NoSQL Cassandra, chamado agora de CassandraFS.

Mas, em torno do Hadoop (http://hadoop.apache.org/), a comunidade Apache mantem diversos projetos relacionados, como o Hbase, que é um banco de dados NoSQL que trabalha em cima do HDFS. Este banco de dados é usado pelo Facebook para suportar seu sistema de mensagens e os seus serviços de informações analíticas em tempo real. Existe também o Hive, criado pelo Facebook, que é uma camada de data warehouse que roda em cima do Hadoop. Utiliza uma linguagem chamada Hive SQL, similar à SQL, o que facilita sua utilização, pois desenvolvedores acostumados com SQL não encontram maiores dificuldades em trabalhar com o Hive SQL.

Um outro e também muito interessante projeto é o Pig, criado pelo Yahoo. É uma plataforma que permite análises de arquivos muito grandes usando uma linguagem de alto nivel chamada de Pig Latin. Olhando-se o stack de softwares do Hadoop, o Pig se situa entre o Hive e o HMR e é uma tentativa de fornecer uma linguagem de alto nivel para se trabalhar com o Hadoop. Outros projetos menos conhecidos são o Avro (sistema de serialização de dados), o Chukwa (monitoramento de sistemas distribuídos) e o Hama (para computações científicas massivas).

A IBM usa intensamente o Hadoop em diversos projetos, o integrando com outros de seus softwares como o Cognos, criando soluções para tratamento analítico de dados massivos e não estruturados, como o InfoSphere BigInsights, que agrega um conjunto de tecnologias open source como o próprio Hadoop, Nutch e Pig, com as tecnologias próprias da IBM como InfoSphere e ManyEyes. Vejam em (http://www-01.ibm.com/software/data/bigdata/). A IBM também desenvolveu uma variante do HDFS chamado de IBM General Parallel File System (GPFS), que pode ser visto em http://www-03.ibm.com/systems/software/gpfs/.

OK, e quem usa Hadoop? Existem os casos emblemáticos como Facebook, Yahoo, Twitter e Netflix (na nuvem da Amazon), mas também já começamos ver seu uso em ambientes corporativos brick-and-mortar. Recentemente uma pesquisa mostrou que pelo menos umas 20 empresas da lista da Fortune 1000 assumiram publicamente que usam Hadoop de alguma forma. A adoção do Hadoop em aplicações analíticas corporativas como as ofertadas pela IBM vão ajudar na sua disseminação. Só para lembrar, quando a IBM anunciou seu apoio ao Linux, em 2001, o Linux passou a ser visto sob outra ótica pelo ambiente corporativo.

Nem todo usuario de Hadoop demanda uma escala massiva de dados ao nivel do Facebook ou Yahoo. Mas empresas com razoavel volume de informações não estruturadas, como bancos, varejo, empresas aéreas e outras vão encontrar no Hadoop uma boa alternativa para o tratamento analítico dos seus dados. Vejam alguns exemplos em ftp://public.dhe.ibm.com/common/ssi/ecm/en/imb14103usen/IMB14103USEN.PDF.

O Hadoop ainda está nos primeiros passos de sua evolução e disseminação pelo mercado. Mas, tenho certeza de que em poucos anos ele será bem mais conhecido e utilizado. Uma pesquisa pelo termo Hadoop no Google Trends já aponta um crescimento significativo no interesse pela tecnologia, como podemos ver em http://www.google.com/trends?q=hadoop . Na minha opinião vale a pena investir tempo estudando a tecnologia. Um dos problemas com o Hadoop é realmente a sua complexidade de uso, demandando desenvolvedores altamente qualificados. A sua curva de aprendizado é bastante ingreme e praticamente inexiste gente habilitada para usar o Hadoop adequadamente. Bem, temos aí uma boa oportunidade para as universidades inserirem seu estudo e prática em seus cursos de ciência da computação…Uma sugestão para quem quer estudar Hadoop mais a fundo: acessem http://www.ibm.com/developerworks e pesquisem pela keyword Hadoop. Vocês vão encontrar milhares de artigos muito interessantes.

Nuvens privadas: começando a jornada em direção à cloud computing

maio 24, 2011

Quando se fala em computação em nuvem geralmente nos vem a cabeça as nuvens públicas como as oferecidas pela Amazon ou Google. Mas a aplicação das ideias, tecnologias e approaches destas nuvens publicas em nuvens privadas, internas à uma empresa, pode ser uma boa alternativa. Existem muitas organizações, que por questões de cultura ou premidas por aspectos regulatorios não podem entrar direto em nuvens publicas, mas tem como opção o uso de nuvens privadas. Uma nuvem privada é, na verdade, a implementação do modelo de computação em nuvem dentro de uma empresa.

Com uma nuvem privada a empresa pode usufruir de varios dos beneficios do modelo de computação em nuvem, como obtenção de recursos computacionais self-service por parte de seus usuários. Claro que ela tem que investir no seu data center e nas tecnologias que permitem a construção do ambiente de nuvem, como catalogos de serviços e softwares de gerenciamento automático de provisionamento e alocação de recursos computacionais. Mas, por outro lado, pode começar a entender o funcionamento do modelo e ajustar aos poucos seu modelo de governança para em algum tempo no futuro adotar nuvens publicas.

De maneira geral as empresas que optam por nuvens privadas são empresas de grande porte, que já tem um investimento alto em TI e mantem adequadas politicas de governança e segurança. O modelo de nuvem privado mais adotado tem sido o de IaaS, que na minha opinião é bem natural, pois não deixa de ser uma evolução do proprio processo de virtualização que estas empresas já vem adotando.

As justificativas para adoção de uma nuvem privada são econômicas (redução de custos) e qualidade dos serviços, com maior agilidade no atendimento às demandas dos usuarios por recursos computacionais.

A redução de custos é provocada pela padronização e automação dos serviços de TI. Com padronização e automação reduz-se os custos operacionais, liberando-se o staff de funções banais para atividades de maior valor agregado. Além disso, com automação, obtem-se uma maior utilização dos ativos computacionais, aproveitando-se melhor o parque computacional já instalado. Um subproduto interessante da padronização e automação é a possibilidade de mudar-se a relação entre TI e os seus usuarios, criando-se politicas mais visiveis e adequadas de chargeback.
Mas, cloud computing é basicamente IT-as-a-Service e portanto é absolutamente essencial que a qualidade dos serviços em nuvem prestados por TI seja superior ao modelo atual. Com uma nuvem privada abre-se oportunidade de TI criar catalogos de serviços e seus respectivos SLA. A automação tambem reduz os erros causados por intervenções manuais e libera o pessoal de TI para atuar mais focado no atendimento aos usuarios que nas atividades de pouco ou nenhum valor agregado, como alocar espaço em disco ou reservar horas em servidores.

Um outro benefício palpável é a agilidade que a nuvem oferece à organização. A nuvem privada abstrai os recursos computacionais dos usuarios, que não tem que se preocupar onde e como as aplicações rodarão. TI, por sua vez, abre espaço para os usuarios serem mais inovadores e arriscarem mais em novos produtos e serviços.

Um ponto importante é que a nuvem privada não vai existir isoladamente e portanto mais cedo ou mais tarde a empresa vai adotar nuvens hibridas, que são ambientes onde aplicações estarão parte on-premise e parte em nuvens privadas. Ou mesmo parte on-premise, parte em nuvens privadas e parte em nuvens publicas. É uma longa jornada e o planejamento para este provavel cenário deve ser desenhado desde o incio. As questões de segurança que são a principal preocupação hoje, passarão a segundo plano, uma vez resolvidas. O questionamento principal, neste cenario, sera a interoperabilidade: como conviver e coordenar ambientes multiplos, com aplicações em nuvens privadas, publicas e on-premise, tudo ao mesmo tempo?

Temos pela frente bons desafios…E é melhor começarmos a enfrenta-los já. A computação em nuvem não é uma promessa, mas uma realidade e quem não começar a desenhar suas estratégias de adoção vai perder o trem.

Insights de 110 projetos reais de implementação de Cloud

maio 11, 2011

Volta e meia nos deparamos com pesquisas sobre adoção de Cloud Computing. Entretanto, a maioria deles se concentra na opinião de executivos ou representantes da indústria. Não olham realmente o dia a dia de quem está com a mão na massa.

Recentemente a IBM realizou uma pesquisa diferente, coordenada pela IBM Academy of Technology, concentrando-se em quem esteve ou está envolvido com projetos de cloud em diferentes clientes: os arquitetos e engenheiros de software. O projeto gerou um relatório muito interessante chamado “Cloud Computing insights from 110 implementation projects” que pode ser acessado em http://tinyurl.com/5sb6pzt.
O relatório descreve como os arquitetos implementaram projetos reais de clouds e como os clientes estão vendo sua adoção, do ponto de vista de quem está diretamente envolvido com os projetos de implementação.

Vamos resumir algumas das suas conclusões, mas recomendo a leitura do relatório na íntegra.
a) Como as nuvens são implementadas? A pesquisa mostrou que apenas metade das implementações obedeceram a uma estratégia de cloud, enquanto a outra metade consistiu-se de iniciativas isoladas, sem objetivos claros e bem definidos. Também ficou claro que a maioria dos projetos atuais ainda são projetos piloto, de âmbito bem localizado. Ainda são poucas as iniciativas de escopo empresarial. Mas, na verdade, como cloud ainda é novidade, a maioria do clientes começa sua jornada com projetos experimentais, para obter experiência e desenhar de forma mais adequada ações mais amplas. Um bom ponto de partida para uma experimentação é criar uma nuvem privada para o ambiente de desenvolvimento e testes, pois desta forma minimizam riscos de segurança (ambiente de certa forma isolado) e obtém ganhos significativos e palpáveis, para seguirem m frente com novos projetos.
b) Adotar o modelo de nuvens vai obrigar revisões nos processos de governança de TI. Este foi o sentimento geral das empresas que implementaram projetos piloto.
c) Na pesquisa identificou-se que 70% das iniciativas eram de nuvens privadas e apenas 30% de nuvens públicas. Existe, claro a ressalva que os projetos eram em grandes clientes, que geralmente começam sua experimentação por nuvens privadas. Se a pesquisa fosse realizada em clientes de menor porte, é provável que a relação fosse inversa. Obteve-se uma informação interessante: nas nuvens privadas o predomínio dos projetos foi de IaaS, seguido de PaaS. Já nas nuvens publicas o SaaS dominou o cenário, secundado por projetos de IaaS.
d) Observou-se também que os clientes sentem que cloud é um movimento irreversível e que em dois a três anos muitos sistemas críticos estarão rodando em nuvens. Entre as aplicações mais citadas como as próximas a entrarem em nuvem são business analytics, colaboração e Web.
e) A leitura do relatório deixa claro que os próximos desafios, após a desconfiança da segurança for vencida, serão as questões de integração e interoperabilidade entre nuvens diferentes e entre aplicações on-premise as que rodarão em nuvens.
f) Um ponto imporatnte e decisivo para o sucesso da adoção da cloud computing é a padronização de imagens. Isto abre espaço para demandas de novos recursos de gestão baseados em ITIL, como image management.

Vemos que ainda existem inibidores para uma maior adoção de computação em nuvem. Segurança aparece em primeiro lugar. Mas, nos projetos avaliados pela pesquisa, como o modelo de nuvem adotado foi de nuvem privada, as questões de segurança são minimizadas. Afinal, a nuvem está operado dentro do firewall e das politicas de segurança da própria empresa.
Por outro lado, os projetos demonstraram claros benefícios. Embora custo tenha sido um dos apelos iniciais, a flexibilidade que a nuvem oferece para os usuários é hoje o seu principal atrativo. A velocidade com que as demandas por recursos e facilidade de TI, que eram medidas em semanas, passam a ser feitas em minutos. Isto abre novas oportunidades para criar aplicações inovadoras em tempos muito mais curtos e facilita experimentações de novos produtos e sistemas.

O relatório também aponta algumas tendências como:
a) O modelo de pay-as-you-go, tipico das nuvens publicas, também deverá ser adotado nas nuvens privadas, com acordos entre IT e as linhas de negócio.
b) Mesmo as grandes empresas vão adotar nuvens publicas com maior intensidade, gerando nuvens híbridas, com parte de aplicações rodando em nuvens privadas e parte nas nuvens públicas. Novamente vem à luz a questão da integração e interoperabilidade.
c) Governança do ambiente em nuvens é um desafio a mais, pois muitos processos devem ser revistos. Extensões e adaptações das disciplinas do ITIL são esperadas. Podemos citar como exemplo image management como uma nova e importante disciplina e modificações em service design, service strategy, service operation, service transition, service operation e service improvement.
d) os aplicativos tenderão ser cada vez mais multi-tenancy. Hoje são no-multitenancy e devem exigir esforço imporante por parte dos fabricantes de softwares, bem como demandarão novos skills dos desenvolvedores nas empresas.

Enfim, analisando o relatório podemos chegar a algumas conclusões, que gostaria de compartilhar com vocês:
a) Comecem a jornada em direção a cloud por projetos piloto, identificando e implementando workloads mais adequados à este modelo. É um processo gradual, com a experiência sendo adquirida ao longo do tempo, com a evolução dos projetos.
b) Mudanças na organização e nos processo de governança de TI serão necessárias.
c) Tenha uma estratégia para adoção de cloud e não tente implementar projetos simplesmente para experimenatr o modelo, sem ter os proximos passos bem definidos.
d) Existem obstáculos, como imaturidade e complexidade de algumas tecnologias para implementação de nuvens privadas, mas que serão resolvidos ao longo o tempo. Tambem os receios de segurança com nuvens publicas tenderão a ser minimizados.
e) O uso de cloud computing vai se acelerar de forma significativa nos proximos dois a três anos.

Road map: da virtualização para Cloud Computing

maio 2, 2011

Há poucos dias gravei um webcast com o iMasters, sobre Cloud Computing. A idéia foi debater com mais detalhes enfoques práticos de como implementar cloud e o título, sugestivo foi de “Da virtualização para Cloud Computing: um road map prático”. O vídeo, com cerca de 85 minutos de duração, pode ser visto em sua íntegra em http://www.videolog.tv/video.php?id=646119 .

Cloud computing, embora muitos talvez ainda não tenham percebido, tem o potencial de mudar de forma radical a indústria de TI, afetando tantos os produtores como os consumidores de produtos e serviços. Da mesma forma que o modelo cliente-servidor provocou um choque sísmico na indústria de TI, criando novas empresas como Oracle e Microsoft, eliminou outras como Digital e Control Data, que não souberam compreender a mudança. O mesmo acontecerá com a indústria de TI atual. Novas empresas estão surgindo e outras ainda surgirão, enquanto algumas, tradicionais, podem até mesmo desaparecer.

O modelo de cloud se baseia em três pilares básicos: virtualização, padronização e automação. Em consequencia surge a possibilidade de se requisitar e obter os recursos de TI por meio de portais self-service.
No webcast abordei em mais detalhes os beneficios obtidos com este modelo, bem como os riscos a que toda novidade se expõe. Também mostramos um road map que orienta as empresas a desenharem sua jornada em direção à computação em nuvem. E um item que mereceu certo destaque foi onde debati as “lessons learned”, uma coletânea de erros e acertos que envolveram dezenas de projetos de implementação de Cloud Computing em todo o mundo. Vale a pena investir hora e meia (é um longo tempo, eu sei…) porque o tema está cada vez mais no centro das telas dos radares das empresas.

Mas, gostaria de fazer alguns comentários adicionais ao webcast. Primeiro, embora já se fale muito no assunto, ainda vejo um certo desconhecimento quando se mergulha nos detalhes. Ou seja, quando nos deslocamos do conceito para a prática. Uma nuvem deve ser vista sob duas dimensões: pelo seu nivel de abstração (IaaS, PaaS e SaaS) e pelo modo como estes serviços podem ser entregues: nuvens públicas, privadas e híbridas, com aplicações em nuvens privadas e outras em nuvens públicas. Estas diversas formas de vermos a computação em nuvem se traduz em formas diferentes de, por exemplo, implementar mecanismos de segurança. Em nuvens publicas, os mecanismos de segurança tradicionais não se aplicam de forma adequada. Observei em um recente evento de segurança que muitos profissionais de segurança ainda não estavam compreendendo as diferenças entre nuvens privadas e públicas e apontavam os mecanismos de segurança usados hoje no modelo on-premise como válidos para nuvens públicas. Eventualmente, com poucas modificações podem ser adotados em nuvens privadas, mas discordo de sua aplicabilidade nas nuvens públicas.

Outro ponto que me chama atenção é que os modelos IaaS (Infrastracture-as-a-Service) e SaaS (software-as-a-Service) são razoavelmente compreendidos, mas PaaS (Platform-as-Service) ainda está meio nebuloso. Talvez possamos resumir seu conceito como “middleware as a service in the cloud”. Mas, atenção, não significa simplesmente colocar um middleware tradicional do modelo on-premise em uma nuvem IaaS. Se você ainda necessitar de uma boa e velha licença de software tradicional, você não estará adotando o conceito de serviços. Será apenas um software hospedado em um provedor de IaaS. Mas se o middleware for disponibilizado como serviço, o termo estará correto.
Na minha opinião o melhor exemplo de PaaS é o force.com criado pela salesforce.com e adotado como definição padrão pelo NIST, órgão de padrões do governo americano.

Outro aspecto que chamo a atenção é que nem sempre o motivador para adoção de cloud será redução de custos. Em uma nuvem privada, por exemplo, a agilidade e a flexibilidade para atender novos serviços é o principal atrativo, embora a empresa ainda tenha que dispender muito dinheiro com seu ativo de hardware e software. Claro que existe potencial de redução de custos pela padronização e automação, que diminui os custos operacionais, mas agilidade na obtenção de novo serviços de TI está se tornando o principal driver para sua adoção. Pensem nisso.

Uma nuvem privada introduz um novo meio para TI interfacear com seus clientes (portal self-service com um catálogo de serviços padronizados) e uma nova maneira de entregar estes serviços (automatizado, sem interferência do pessoal de TI, deixando a cargo do próprio usuario o que e quando usar os serviços). Estas mudanças demandam um novo modelo de relacionamento entre TI e seus usuários e em ultima análise, como os proprios usuários desenvolvem seus negócios. Portanto a adoção de uma nuvem privada requer mudanças na organização, processos e modelos de custeio e negócios de TI. A empresa desloca seu foco de TI da ótica de tecnologias e ativos (servidores e softwares) para serviços. É um processo gradual, que deve começar por uma área relativamente isolada (como desenvolvimento e testes) e aos poucos se expandindo para o ambiente de produção.

E quanto a adotar uma nuvem publica? Se a empresa não tiver sistemas legados, será bastante simples. Começa do zero em um ambiente de nuvem, sem necessitar de comprar servidores e softwares. Mas se existir um legado?
De maneira geral, para empresas que já dispõem de TI, identifico três motivadores para adoção de nuvens públicas:
a) sistemas legados obsoletos estão impedindo o crescimento do negócio,
b) os recursos de TI estão subdimensionados e não suportam crescimento da demanda, e
c) a empresa vai lançar novos serviços e não quer manter o modelo tradicional on-premise, pois cloud faz mais sentido para ela.

A escolha do provedor de nuvem pública não pode ser feita de maneira simplista. Entre os quesitos de avaliação, como grau de segurança e disponibilidade que ele oferece, um item que deve ser validado é como você conseguirá interoperar os sistemas que estarão na nuvem com os legados, on-premise? Esta interoperbilidade é fácil ou vai demandar esforço para escrever novos códigos acessando APIs específicas?
Não esqueça que muitas vezes você terá que operar um software, como um banco de dados, tanto na nuvem como suportando aplicações on-premise. Você poderá expandir a licença on-premise para também operar o software na nuvem, sem gastos excessivos?

Enfim, estamos ainda dando os primeiros passos nesta longa jornada e pouco a pouco vamos acumulando mais e mais conhecimento. Talvez o webcast ajude um pouquinho nesta compreensão.
abraços

Padrões em Cloud Computing

abril 29, 2011

Entrevista sobre padrões em Cloud Computing: http://www.ticmercado.com.br/ticmercado.php/?edi=116&tabs=tab1

Validando provedores de IaaS

abril 18, 2011

Nas últimas duas semanas estive envolvido em uns 3 ou 4 eventos sobre Cloud Computing. É um assunto que ainda gera muita discussão. É inevitável, pois cloud é uma revolução na maneira de se entregar e consumir TI. Se esta nova maneira de se ver TI fosse compreendida de imediato, não seria uma revolução.
Destes eventos, vou tirar uma pergunta que me foi feita e trabalhar em cima dela. A pergunta foi: “Como posso escolher um bom provedor de nuvem de infraestrutura, IaaS?”.

É um ponto interessante. Embora existam diversos provedores de IaaS, alguns nacionais e outros globais, à despeito das similaridades quando se olha os seus prospectos de marketing, eles não foram criados de forma igual e nos detalhes mostram-se totalmente diferentes entre si.

Cada provedor de IaaS foi desenhado e arquitetado para atender mercados de escalas e características diferentes. Assim, alguns se propõem a atender grandes empresas, altamente exigentes em termos de niveis de serviço e compliance à aspectos regulatórios, enquanto outros buscam atender empresas de pequeno porte, menos exigentes quanto a estes aspectos. Os seus data centers também são desenhados com esta escala em mente. Para atender a algumas centenas de clientes um data center terá características diferentes de outro que deverá suportar alguns milhões de clientes. Os objetivos de negócio também são diferentes, o que vai se refletir nos investimentos e capacidade financeira de cada provedor.

A escala do provedor tem um reflexo imediato na flexibilidade e nos preços oferecidos por ele ao mercado. O provedor deve previamente investir em uma determinada capacidade computacional, capacidade esta que será oferecida ao mercado. Ou seja, ele tem que fazer um investimento upfront para entrar no mercado. Se seus clientes tiverem um ticket médio muito pequeno, ele precisará de muito fôlego financeiro para subsidiar o negócio até que suas ofertas IaaS sejam lucrativas. Além disso, a sua escala também influencia o grau de elasticidade que ele poderá prover. Por exemplo, se seus clientes não variarem muito em termos de consumo computacional e estiverem próximo dos limites de utilização do seu data center, qualquer aumento de demanda necessitará de mais investimentos e a velocidade do atendimento será mais demorada. Nestes casos ele provavelmente nem poderá garantir que 100% dos recursos provisionados serão realmente alocados. Por outro lado, provedores com excesso de capacidade e clientes com variação de carga significativa, poderá oferecer preços diferenciados de acordo com a demanda.

Os data centers dos provedores também merecem uma atenção especial. Algumas empresas globais tem condições de criar vários data centers, com controles de segurança extremamente sofisticados. Outras, sem esta capacidade de investimento, poderão dispor de um data center mais vulnerável a ataques ou mesmo a situações de indisponibilidade.
Os servidores destes data centers também não são os mesmos. De maneira geral, um serviço de IaaS é baseado em servidores de base Intel ou AMD, com sistemas operacionais Linux e/ou Windows. Porque este assunto nos interessa? Ora, dependendo do processador, ele poderá ou não ter recursos de virtualização embutidos no hardware, o que melhora o desempenho dos servidores virtuais. Verifique também se os servidores e clusters que compõem o data center tem componentes redundantes, como “dual power supplies” ou “dual network interfaces cards” (NICs). O nivel de disponibilidade oferecido pelo provedor é afetado por estas características.

Outra tecnologia a ser observada é a de virtualização. De maneira geral encontramos hipervisores VMware, Xen, Hyper-V e KVM. Se você estiver preocupado com performance um estudo mais detalhado poderá mostrar qual hipervisor será mais adequado para o nivel de desempenho e disponibilidade esperado para suas aplicações. Dependendo da tecnologia de virtualização e da expertise do provedor voce poderá ter diferentes niveis de disponibilidade. O pior é a queda de um servidor físico derrubando todos os servidores virtuais que rodam nele. A partir daí, será interessante analisar como o provedor garantirá a disponibilidade: ele poderá automáticamente remover o servidor vitual de um servidor físico indisponivel para outro, sem afetar a operação dos usuários? E qual será o custo deste nivel de disponibilidade?

Como falamos em disponibilidade, devemos entrar no assunto disaster recovery. Se o data center ficar indisponivel, existe data center alternativo para continuar a operação do provedor? Em caso positivo, em quanto tempo o data center alternativo poderá começar a operar?

Outro ponto é o grau de automação e velocidade de atendimento do provedor à solicitações de provisionamento do usuário. Se o processo de provisionamento do provedor ainda demandar processos manuais, o atendimento poderá levar algumas horas. Já um provedor que ofereça recursos automáticos de provisionamento e interfaces self-service poderá atender as demandas em poucos minutos.

Um aspecto importante é o SLA (Service Level Agreement). Na seleção do provedor considere os niveis de serviço desejáveis e selecione apenas os que puderem, de forma comprovada, oferecerem tais acordos. Importante colocar nos contratos as penalidades pelo não cumprimento destes acordos. Considere que o nivel de serviço de uma aplicação hospedada em provedor de IaaS público passa pela rede, seja esta Internet (pelo qual nem sempre se tem controle) ou por uma rede privada, onde o acordo tem que ser fechado com o provedor da nuvem e o da rede. Nos acordos verifique se existe alguma cláusla referente a ataques DoS (Denial-of-service), pois existe a sempre presente possibilidade de um provedor de nuvem pública ser atacado por crackers. Afinal, ele concentra em seu data center centenas de empresas diferentes.

Então…qual o melhor provedor? Depende das necessidades de cada empresa. Algumas demandam um nivel de exigência que as limitará a selecionar um provedor de escala global. Outras, não demandam tais exigências e podem conviver com um provedor que não ofereça niveis muito elevados de disponibilidade e flexibilidade.

Politica Cloud First do governo americano avaliza potencial de Cloud Computing

abril 12, 2011

Recentemente li com atenção o documento “Federal Cloud Computing Strategy” (http://www.cio.gov/documents/Federal-Cloud-Computing-Strategy.pdf) publicado em fevereiro deste ano pelo CIO do governo americano.
O documento, embora apresente uma visão macro, serve de orientação para órgãos de governo de quaisquer países, inclusive o Brasil e como tal pode ser visto como um roteiro de implementação de cloud computing por órgãos governamentais (de qualquer esfera) e empresas privadas.

Segundo o documento, o setor de TI do governo americano é caracterizado por baixa utilização de seus ativos, sistemas duplicados, fragmentação na demanda de recursos, ambientes diversos e de dificil gerenciamento, etc. Na minha opinião a mesma situação ocorre em praticamente todas organizações complexas, como órgãos de governo e empresas privadas de grande porte.
O documento mostra também que do budget de 80 bilhões de dólares/ano, pelo menos 25% ou 20 bilhões podem ser alvo potencial de deslocamento para o modelo de cloud computing.

A estratégia adotada pelo governo americano é chamada de “Cloud First Policy”, ou seja, a primeira opção é o modelo em nuvem e apenas se o modelo não for adequado, a implementação de um novo sistema poderá ser no atual modelo computacional. Um texto oficial do governo explicita claramente: “ Jeffrey Zients, the federal government’s chief performance officer, announced…that the Office of Management and Budget will now require federal agencies to default to cloud-based solutions whenever as secure, reliable, cost-effective cloud option exists”. Na minha opinião é um significativo aval quanto à potencialidade e aplicação da computação em nuvem.

O documento analisa os benefícios e os riscos potenciais do ambiente de computação em nuvem e utiliza a definição de Cloud Computing do NIST (National Institute of Standards and Technology) “Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction”. O NIST também define os modelos de service como IaaS, PaaS e SaaS, e os modelos de entrega como private, community, public e hybrid. Caso queiram ver o documento do NIST acessem //csrc.nist.gov/groups/SNS/cloud-computing/cloud-def-v15.doc.

Um capítulo interessante é o “Decision Framework for Cloud Migration”, que aborda o processo de migração em três etapas:
1) Select. Identifica que serviços podem ser transferidos para cloud computing e quando podem ser movidos. Passa pela determinação do que ele chama de “cloud readiness” ou seja, qual o grau de preparação que o órgão ou empresa se encontra para migrar para cloud;
2) Provision. Busca garantir critérios de interoperabilidade entre aplicações e serviços nas nuvens com os que continuam on-premise, bem como contratos e acordos de nivel de serviço com os provedores de nuvem; e
3) Management. São as recomendações de monitoração e gestão das nuvens. Um ponto importante é a recomendação de reavaliação periódica dos provedores.

Outro capítulo que chama atenção é o que lista exemplos bem sucedidos de implementação de cloud em órgãos de governo. Infelizmente não são muitos, mas mostra o potencial de uso da computação em nuvem. Aliás, o governo americano criou recentemente um ambiente de aplicativos à la “AppStore” chamado de Apps.gov (http://www.info.apps.gov/) onde os órgãos do governo podem obter recursos em cloud, de IaaS a SaaS.

Na prática o documento, embora não entre em detalhes, é um bom modelo que orienta órgãos de governo e empresas privadas no processo de adoção de cloud. Um ponto que chama atenção é a abordagem de cloud, não se prendendo apenas a redução de custos, mas como plataforma que impulsiona agilidade e inovação no setor público. Claro que redução de custos é importante, tanto que cloud faz parte da estratégia de consolidação dos 2100 data centers do governo americano. Mas, na minha opinião uma abordagem focada em redução de custos induz naturalmente aos executivos a olharem TI como commodity, como o jornalista Nicholas Carr definiu em seu instigante livro “Does IT Matter?”. Olhando cloud como plataforma para inovação, nossa leitura é que embora certos aspectos de TI sejam comoditizados (infraestrutura, por exemplo), existe ainda muito espaço para inovação que será potencializada pelo ambiente em nuvem. Outro aspecto legal do documento é que embora seu público alvo sejam os CIOs, ele pode ser usado pelos próprios CIOs como ferramenta de apoio no convencimento dos demais executivos a adotarem cloud como estratégia de TI da empresa.

O documento não entra em detalhes de como por exemplo, identificar quais as aplicações mais adequadas para migrarem para nuvem, que poderá demandar algum apoio externo (consultoria), mas é um primeiro e importante passo na jornada em direção à computação em nuvem. Entretanto, o governo americano, através do NIST deverá publicar até o fim deste ano um documento denominado “Cloud Computing Technology Roadmap” (http://tinyurl.com/3quxh7v) que abordará os aspectos técnicos em maior profundidade.

Debatendo um pouco mais Cloud security

abril 6, 2011

A cada vez que o assunto Cloud Computing surge em uma reunião, a questão da segurança aparece em primero lugar. Sendo assim, nada mais natural que eu volte a falar deste tema.
Neste post vou abordar os provedores externos de infra-estrutura em nuvem, os provedores de IaaS.

No caso dos provedores de IaaS o primeiro lembrete é que eles não são iguais. Ou seja, cada provedor, apesar das aparentes similaridades dos recursos de segurança quando olhamos superficialmente a questão, oferece, ao nos aprofundarmos na análise, niveis de segurança bastante diferentes.

É inevitável. A experiência, capacitação e poder financeiro por trás do DNA corporativo de cada provedor vai se traduzir em diferentes processos de gestão de segurança. Um provedor de hosting voltado a pessoas físicas e pequenas empresas, que se lança como provedor de cloud, não tem a experiência acumulada de uma outra empresa que há anos se dedica a terceirizar serviços de outsourcing a empresas extremamente exigentes quanto à segurança, como bancos e operadoras de cartões de crédito.

Alguns exemplos: Qual o nivel de controle de segurança física e gerencial oferecido pelo provedor nos seus data centers? Existem tecnologias adequadas para mitigar os efeitos de ataques DDoS (Distributed Denial-of-Service)? Quais os recursos oferecidos pelo provedor para deteção de intrusões? Quais os recursos oferecidos para garantir o isolamento das máquinas virtuais de diferentes clientes que compartilham os mesmos servidores físicos?

Outro aspecto que deve ser analisado nos provedores externos é a questão do IAM (Identity and Access Management). Sugiro validar se e como os funcionários do próprio provedor acessam as máquinas virtuais dos clientes. No caso de funcionários do provedor terem acesso, para atividades operacionais como debug ou atualização de patches, este acesso é auditado e rastreável? No caso de acesso pelos clientes, o provedor tem procedimentos que garantam que apenas os usuários autorizados acessam as máquinas virtuais destes clientes?

Além disso, o discurso comercial pode induzir algumas confusões adicionais. Muitos provedores argumentam que por possuirem um nivel de auditagem SAS 70 Type II serão absolutamente seguros. Não é verdade, pois o SAS 70 não revisa a eficácia dos processos e controles de segurança, mas apenas checa se tais procedimentos existem e se estão documentados. Outra confusão aparece quando se analisa o provedor perante requerimentos como o Sarbanes-Oxley Act (SOX). Muitas vezes o provedor apenas cumpre parte dos requerimentos e pode acontecer que tais partes não estejam à altura do nível de compliance de sua empresa. Assim, não basta saber que o provedor está compliance com SOX ou PCI DSS (Payment Card Industry Data Security Standard). É necessário que você verifique com cuidado se o nivel de compliance dele é adequado às suas necessidades.

No final das contas, apesar do provedor oferecer processos e controles de segurança adequados, sua empresa é a responsável final pela segurança. No caso de infra em nuvem (IaaS), não esqueça que estamos falando de servidores virtuais e o controle de acesso lógico aos aplicativos e dados é de responsabilidade dos usuários da nuvem e não do provedor. O que significa tudo iso? Simples. A responsabilidade pela resiliência da infra em nuvem é compartilhada tanto pelo provedor como pelos seus clientes. O provedor tem que garantir a resiliência do data center e dos servidores. Os aplicativos são de responsabilidade da empresa.

Assim, como mensagem final, avalie cuidadosamente os provedores, filtre os discursos comerciais e analise em detalhes os processos e controles de segurança oferecidos.

Da virtualização a Cloud Computing

março 28, 2011

Em um dos últimos eventos sobre Cloud Computing um gestor de TI me disse que já usava computação em nuvem há bastante tempo. Me interessei, pois sempre busco casos de sucesso ou insucesso. Os de insucesso são muito interessantes, pois aprende-se muito com os erros…Questionado, ele me disse que já havia virtualizado quase todos os seus servidores. E? Sim, isso mesmo, na opinião dele, virtualizar os servidores significava já estar na computação em nuvem. Infelizmente, tive que frustrá-lo e mostrar que uma simples virtualização não é computação em nuvem. É apenas o primeiro passo, desde que exista uma estratégia para chegar lá. Se a virtualização for o objetivo final, não vai se chegar na computação em nuvem. Cloud Computing demanda mudanças nas arquiteturas tecnológicas, processos de governança, modelos de funding e relacionamento com os usuários e clientes.

Muitas empresas adotaram a virtualização com o objetivo de consolidar seus servidores e reduzir seus custos de hardware e energia. Ou mesmo evitar a construção de um novo data center, pela proliferação de servidores físicos. Entretanto, logo descobriram que passar, por exemplo, de 100 servidores físicos para 50 servidores, mas com 300 ou mais servidores lógicos virtualizados criava imensos problemas de gestão, com consequentes aumentos de custos.

Minha sugestão para ele foi dar os passos seguintes. A virtualização abstrai as aplicações da infraestrutura e pode ser a base para a construção de uma estratégia de cloud computing. Os passos seguintes devem ser a padronização e automatização do ambiente computacional. É um processo gradual.

Com um ambiente virtualizado podemos nos concentrar nas melhorias operacionais, criando mecanismos que permitam um provisionamento e alocação de recursos de forma mais rapida e automática. O usuario poderá ele mesmo requisitar os recursos computacionais, via um portal de acesso. Claro que neste estágio teremos que repensar os processos burocráticos e manuais que adotamos hoje. Quando uma requisição de servidores deixa de passar por um administrador humano e passa a ser automático, via portal self-service, e o tempo de provisionamento deixa de ser de duas ou três semanas, e sim de apenas alguns minutos, os processos devem ser revistos.

A adoção da computação em nuvem deve seguir uma estratégia bem definida. De maneira geral uma grande empresa começa por uma nuvem privada, de modo exploratório, com casos bem definidos e restritos. Um bom exemplo é o ambiente de desenvolvimento e testes. É uma boa maneira de se começar a colocar em prática a computação em nuvem. As lições aprendidas serão muito úteis quando da disseminação do modelo em nuvem para outros contextos, como o de produção.

A computação em nuvem provoca a revisão do relacionamento data center-usuário, inclusive permitindo uma visão mais exata do consumo de recursos e consequentemente abrindo espaço para uma revisão dos processos de funding da empresa. O modelo self-service abre novos desafios sob a perspectiva de segurança e gestão. Por exemplo, em um ambiente de teste em nuvem, todo e qualquer desenvolvedor poderá alocar um servidor virtual ou existirão regras claras de quem poderá alocar tais recursos?

Muito bem, começamos a explorar uma nuvem privada. Próximo passo provavelmente será adoção de nuvens híbridas, com algumas aplicações e serviços rodando em nuvens públicas. Surgem novos desafios, que vão da segurança à integração. Como interoperar uma aplicação que está em uma nuvem privada com outra que esteja em uma nuvem pública?

Porque pensar em nuvens híbridas? Muitas vezes será necessário lidar com periodos de pico que não justificam a aquisação de ativos (servidores), que se tornarão ociosos a seguir. Um exemplo? O próprio ambiente de desenvolvimento e teste poderá passar por períodos de pico extraordinários e de curta duração. Permitir que ele se expanda temporariamente para uma nuvem pública faz com que não seja necessário adquirir novos servidores.

Outro ponto que devemos analisar é que muitas aplicações e serviços poderão rodar sim, em nuvens públicas, desde que satisfaçam os critérios de segurança e governança corporativa. Neste caso, o modelo hibrido torna-se constante. Na minha opinião, a maioria das empresas de médio a grande porte irão, nos próximos anos, caminhar para este modelo.

Neste ano já vemos uma aceleração signficativa de uso da computação em nuvem. De forma exploratória, é verdade, mas à medida que formos aprendendo a usá-la e sentirmos seus beneficios, a velocidade de adoção será bem mais acelerada. Algumas estimativas apontam que cerca de 2/3 das grandes empresas já estarão usando, nos próximos anos, em maior ou menor grau, nuvens privadas. Nuvens híbridas serão o passo seguinte e logo após perderemos o medo de usar nuvens públicas.

Portanto, os gestores de TI estão diante de um futuro que já começa a se fazer presente: a empresa na computação em nuvem ou seja, o mundo pós-virtualização. A pergunta que se faz é: estamos preparados?

Segurança em Cloud: debatendo um pouco mais

março 21, 2011

Em palestras e reuniões sobre Cloud Computing o tema que se sobressai é segurança. Na verdade a questão segurança e o receio diante de uma novidade é comum e sempre aconteceu. Quando, no início dos anos 90 do século passado o assunto era adoção do modelo client-server o questionamento era similar. O mesmo quando começou-se a se falar em comércio eletrônico e era grande o temor de se liberar o uso de cartões de crédito pela Internet. Hoje, o tema segurança também permeia as principais discussões sobre liberação ou não do uso de smartphones e mídias sociais nas empresas. Enfim, é uma discussão natural diante de qualquer novidade e na minha opinião bastante salutar. Posteriormente, à medida que adoção de cloud computing se disseminar, ou seja, após vencermos os receios quanto à segurança, os assuntos que nortearão os eventos e debates sobre cloud passarão a ser integração (como integrar aplicações em clouds diversas e com aplicações que não estejam em cloud) e mais à frente ainda, teremos os debates sobre governança.
Mas, como hoje o tema mais proeminente é segurança, vamos explorá-lo um pouco mais neste post.

Métodos e processos de segurança mudam a cada vez que o modelo computacional muda. Foi assim quando surgiu o cliente-servidor e muitos dos métodos adotados para ambientes centralizados tornaram-se inúteis. Foi assim quando a Internet passou ser parte integrante dos processos de negócio e os métodos adotados para segurança internos mostraram-se insuficientes e tiveram que ser modificados. Com adoção de cloud computing a história está se repetindo. Temos que repensar muitos dos processos de segurança atualmente adotados.

Entretanto, ao se falar em segurança em cloud, temos que separar nuvens públicas das privadas. Além disso, as politicas e consequentemente os métodos e processos de segurança adotados diferem de empresa para empresa, pois a tolerância à riscos é diferente em empresas e setores diversos. Em nuvens privadas, as politicas de segurança são as já adotadas pela empresa, claro que atualizadas para o novo modelo. Em nuvens públicas, a política de segurança fica subordinada aos métodos e processos adotados pelo provedor da nuvem.

Claro que a preocupação com segurança é primordial para o sucesso de qualquer provedor de nuvens públicas e eles, pelo menos, os que tem capital intelectual e financeiro suficientes, implementam processos, métodos e tecnologias que reforçam a segurança. Além disso, muitos buscam passar por auditorias externas como SAS 70 (http://en.wikipedia.org/wiki/SAS_70) e certificações oficiais como ISO 27001 (http://en.wikipedia.org/wiki/ISO_27001). Nos EUA e Europa também buscam compliance com FISMA (Federal Information Security Management Act (http://en.wikipedia.org/wiki/FISMA) para projetos junto ao governo americano, Payment Card Industry Data Security Standards (http://en.wikipedia.org/wiki/PCIDSS) para operações que envolvem cartões de crédito e European Data Privacy Directives para operações com empresas européias.

Por outro lado, empresas menos tolerantes à riscos optam por adotar nuvens privadas para seus sistemas críticos, usando nuvens públicas apenas para aplicações que não implicam em riscos para negócio.

Na verdade a adoção de cloud acontece quando o valor percebido pelo novo modelo excede a percepção do seu risco. Cloud deve ser adotado não apenas por redução de custos, mas pela velocidade e flexibilidade que permite a empresa inovar e criar novos produtos e serviços suportados por TI.

Adotar cloud significa rever seus processos, métodos e tecnologias de segurança. Para ficar mais claro devemos dividir a questão segurança em diferentes aspectos como proteção e privacidade dos dados, garantia de integridade dos sistemas (controle de acesso e vulnerabilidades), disponibilidade, facilidades de auditoria e compliance com as regras do setor de negócio em que a empresa esteja inserida. A análise destes pontos é que vai definir o ritmo de adoção de cloud e se a nuvem será privada, pública ou mesmo híbrida. Por exemplo, no quesito auditoria, os processos SAS 70 não estão plenamente preparados para computação em nuvem e já se trabalha no SSAE 16 como seu substituto (http://ssae16.com/).

À medida que o conceito de cloud evolui, novos processos e tecnologias de segurança surgirão e veremos um circulo virtuoso. Estas novas tecnologias trarão mais confiança no uso de cloud, o que aumentará sua disseminação e com mais disseminação, mais novas e inovadoras tecnologias de segurança surgirão, fazendo girar o círculo.

Também, como sinal de amadurecimento do mercado, começamos a ver os primeiros esforços na definição de padrões de segurança, que permitam classificar de forma consistente as soluções de segurança oferecidas tanto pelas nuvens privadas, mas e principalmente pelos provedores de nuvens publicas. Recomendo a leitura dos papers “Security Guidance for Critical Areas of Focus in Cloud Computing”, publicado pela Cloud Security Alliance (https://cloudsecurityalliance.org/csaguide.pdf) e “Cloud Computing Security Risk Assessment”, publicado pela ENISA (European Network and Information Security Agency), em http://www.enisa.europa.eu/act/rm/files/deliverables/cloud-computing-risk-assessment.

Aos poucos estas iniciativas ajudam as empresas analisarem mais detalhadamente o que pode ou não ir para uma nuvem pública ou privada e mesmo comparar os niveis de segurança oferecidos pelos diversos provedores de nuvens públicas. O resultado final é que pouco a pouco a computação em nuvem vai quebrando barreiras e se disseminando pelo mercado.

Quando adotar cloud?

março 10, 2011

Em uma recente reunião com executivos de um cliente, onde ficou decidido que irão adotar o modelo de cloud computing, surgiu a questão: quais os principais desafios para colocar as idéias em prática?
Algumas das dúvidas que foram debatidas são, de maneira geral, comuns a maioria das empresas e portanto vamos compartilhá-las aqui.
Adotar cloud computing não é uma simples questão de implementar um sistema de virtualização. Aliás ainda existe muita simplificação, com empresas implementando virtualização e afirmando que estão implementando cloud computing. A fórmula para cloud computing é virtualização + padronização + automação. Virtualização é apenas o primeiro passo da jornada.
Alguns dos desafios que os gestores de TI vão enfrentar nesta jornada em direção a cloud computing envolvem desde o ritmo, intensidade e abrangência do uso de cloud até mudanças na própria estrutura e organização de TI, com novos skills e responsabilidades, mudanças nos modelos de governança e definição de budgets, e relacionamento com clientes internos e provedores externos.

O primeiro passo é considerar cloud como estratégia de TI, como foi a mudança do ambiente centralizado para o cliente-servidor há uns 15 anos atrás. As empresas que ignoraram o modelo cliente-servidor e insistiram em se manter por tempo demasiado no ambiente centralizado, tiveram que correr atrás do prejuízo. Lessons learned. Portanto a atitude de TI frente à computação em nuvem deve ser pró-ativa e não reativa.

TI deve identificar onde a adoção de cloud poderá trazer maiores e mais rápidos benefícios para a empresa, inclusive pensando “out-of-the-box”, criando novas oportunidades de geração de receita para a organização. Assim TI deve estar bem identificado com as demandas do negócio e as potencialidades da computação em nuvem.

Mas, idéias para serem concretizadas precisam de um impulso financeiro. A adoção de cloud deve ser substanciada por uma análise bem detalhada de ROI (return on investment), TCO (total cost of ownership) e o valor de oportunidades para processos ou produtos inovadores. Deve ficar claro que quando falamos em cloud computing estamos falando de diversos serviços em nuvem como IaaS, PaaS e SaaS, que estão em diferentes estágios evolutivos. SaaS já está em operação há bastante tempo, mas PaaS está dando seus primeiros passos agora. Isto significa que muitas vezes os custos e os riscos do pioneirismo devem ser embutidos nos estudos para sua adoção.

O ritmo e abrangência da adoção de cloud na empresa depende muito da sua cultura de inovação e risco. Empresas mais avessas à riscos devem começar com serviços de cloud já maduros como SaaS, em aplicações que ofereçam o minimo de risco para o negócio.

A estratégia de disseminação pode e deve ser gradual. Um exemplo de road map foi o definido pelo CIO do governo federal americano em um recente documento (http://www.cio.gov/documents/StateOfCloudComputingReport-FINALv3_508.pdf) onde ele explicita:
. By September 2011 – all newly planned or performing major IT investments acquisitions must complete an alternatives analysis that includes a cloud computing based alternative as part of their budget submissions.
. By September 2012 – all IT investments making enhancements to an existing investment must complete an alternatives analysis that includes a cloud computing based alternative as part of their budget submissions.
. By September 2013 – all IT investments in steady-state must complete an alternatives analysis that includes a cloud computing based alternative as part of their budget submissions.

Não conheço pesquisas formais, mas de maneira geral há um consenso que de 10% a 40% das aplicações que rodam on-premise nas empresas podem migrar para cloud em curto espaço de tempo. É papel de TI identificar quais destas aplicações fazem sentido migrarem para cloud, o ROI desta migração e os prazos para que isso aconteça.

Finalmente, existe um desafio que ainda não está sendo devidamente ponderado: o gerenciamento e monitoramento dos recursos em cloud. A computação em nuvem muda de forma significativa a maneira como os recursos de TI são adquiridos e utilizados. De maneira geral, pelos menos nos próximos anos, veremos ambientes hibridos nas empresas, com sistemas rodando on-premise em servidores dedicados, outros rodando em nuvens privadas e outros em nuvens públicas. Gerenciar, monitorar e garantir a interoperabilidade deste ambiente complexo não é e nem será uma tarefa simples. A área de TI passará a ser aos poucos de exercer funções de gerenciadora de ativos a gerenciadora de relacionamentos com os provedores de nuvens. Novos skills e funções devem ser adquiridos como cloud services architects. Os modelos de governança devem ser ajustados para a flexibilidade, elasticidade e caracteristicas self-service do ambiente de nuvem.

O resumo da ópera é que a transição para a nuvem vai exigir bastante planejamento. Voltando no passado, se olharmos os então CPDs que mantinham sistemas centralizados e compará-los com os data centers de hoje que rodam sistemas Web e cliente-servidor em centenas ou milhares de servidores, veremos imensas diferenças. E as diferenças entre estes data centers de hoje e as nuvens de manhã serão iguais ou maiores. Portanto, devemos começar a planejar este novo cenário a partir de hoje.