Planejamento de Capacidade em Cloud

O assunto Coud Computing ainda gera muito debate. Em um recente evento me perguntaram se uma empresa que usa nuvens públicas ainda precisaria fazer planejamento de capacidade, uma vez que, em tese, os recursos computacionais disponíveis passariam a ser inesgotáveis. Quando for necessário mais recursos, disse a pessoa, bastaria solicitar seu provisionamento ao provedor da nuvem.

Mas, vamos pensar um pouco. Vamos imaginar que um provedor de cloud seja como uma empresa de utilities, como uma operadora de celular. Em tese, basta irmos a uma loja da operadora e comprar uma linha. É verdade, mas volta e meia somos desagradavelmente surpreendidos com problemas de sobrecarga, o que nos gera diversos inconvenientes, como falhas ou interrupções na ligação. Nem sempre é possivel a uma opradora manter uma capacidade maior que a demanda. Existem momentos e locais em que a demanda é maior que a capacidade.

Voltemos ao provedor de cloud. Ele tem que fazer um grande investimento para criar seus data centers e óbviamente que precisa recuperar seu investimento e gerar lucratividade. Pode acontecer que em determinadas situações o provedor não tenha capacidade suficiente para acomodar mais pedidos e manter o mesmo nivel de serviço. Para garantir sempre um atendimento instantâneo ele teria que sustentar uma capacidade em excesso (overprovisioning), que convenhamos, é bastante custoso. Na prática ele vai provavelmente operar como outros provedores de serviços comumente operam, que é vender mais do que a capacidade suportada, esperando que nem todos a requisitem ao mesmo tempo. Quem faz isso constantemente são empresas aéreas, com sua prática de overbooking.

Existe um agravante. Recursos computacionais como servidores e storage podem ser rapidamente adquiridos pelo provedor para atender a uma demnda crescente, mas largura de banda de rede é muito mais demorada para ser ampliada. É um gargalo em potencial.

Assim, os recursos não são infinitos. Os provedores precisam fazer estudos de planejamento de capacidade para definir que capacidade poderão ofertar ao mercado. E quanto aos usuários? Bem, a empresa que vai usar clouds públicas deve estimar quanto de recursos serão necessários, inclusive para fazer as contas de quanto terão que pagar. O custo de hora de servidor virtual é barato, mas os custos de transmissão de dados tendem a ser bem mais caros.

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 estudos de planejamento de capacidade. Para maiores detalhes do modelo spot pricing vejam //aws.amazon.com/ec2/spot-instances.

Que conclusão chegamos? Planejamento de capacidade ainda é necessário. Ao usar uma nuvem pública você não faz estudos para adquirir computadores físicos, mas deve planejar quanto de recursos computacionais demanda e estimar quanto custarão estes recursos virtuais. E se vale a pena pagar por eles…

ITIL e Cloud Computing?

Outro dia, em uma animada discussão sobre Cloud Computing surgiu a questão: em tempos de cloud, modelos de gestão de TI como ITIL, ainda tem validade?
Os ambientes operacionais de TI tendem a cada dia a se tornarem mais complexos e diversificados. Novas aplicações, usando tecnologias de “dynamic programming languages” como PHP e Perl, mash-ups e mídias sociais são criadas muito facilmente. Muitas das aplicações nem dependem mais de desenvolvedores profissionais, tal a facilidade com que podem ser escritas. O resultado é que a demanda por mais e mais serviços de TI tende a aumentar exponencialmente. O modelo de cloud computing pode ajudar muito na luta contra esta pulverização de serviços. Mas…

Antes de mais nada vamos lembrar que Cloud Computing é o resultado prático de aplicação da fórmula virtualização + padronização + automação. Virtualização é o primeiro passo. A padronização permite criar templates de serviços que podem ser solicitados pelos usuários via um portal, e a automatização cria o ambiente self-service, dinâmico e elástico como proposto pela computação em nuvem.

Com o modelo de computação em nuvem o usuário não precisa ser um expert para requisitar um serviço, podendo fazer isso via um portal. Mas os serviços prestados pela nuvem precisam ser medidos e avaliados, de modo que seja possivel definir-se e monitorar-se os SLA (Service Level Agreements). É absolutamente necessário, para uma operação eficiente da empresa, que os serviços de TI (em nuvem ou on-premise) sejam gerenciados, em todo o seu ciclo de vida, passando-se pelos conhecidos processos de change management, incident management, performance management, etc.

A adoção do framework ITIL enfatiza a padronização de processos de TI, essenciais para implementar e monitorar o delivery dos serviços, sejam estes fornecidos pela próprio data center ou por uma nuvem pública. Na prática, na maioria das empresas veremos ambientes híbridos, com parte dos serviços sendo oferecidos por nuvens privadas, sejam estas operadas no próprio data center (ou hospedadas em data centers de terceiros) e parte por nuvens públicas.

Todos os benefícios esperados pelo uso de cloud (agilidade, flexibilidade e redução de custos) podem ser desperdiçados se os processos de gestão não estiverem adequados. Claro que a operação de uma IaaS em uma nuvem publica está a cargo do provedor, mas a gestão de quanto da infraestrutura usar (e quanto pagar) deve ser gerenciada pela empresa. Assinar uma nuvem publica é como a assinatura de uma linha de celular. Se não houver monitoramento de seu uso, podemos ser surpreendidos com uma conta milionária…Além disso, a padronização dos processos permite definir claramente de quem é a responsabilidade pelas operações na nuvem. O provedor de uma nuvem IaaS oferece a infraestrutura virtual, mas quem fica responsavel pelas operações de backup e restore? Quem fica responsável pela gestão de segurança e controle de acesso?

Outra variável da equação cloud computing é a automatização. Para termos um ambiente altamente automatizado e self-service, devemos ter processos bem definidos. Imaginem todo e qualquer funcionário da empresa podendo resquisitar um servidor virtual (nuvem píublica ou privada) para quaisquer atividades, até mesmo pessoais…Os serviços a serem oferecidos, quem deve ter acesso a eles e os limites para seu uso são parte do processo de gestão da nuvem.

A facilidade com que se obtém acesso a nuvens públicas, aumenta a prossibilidade de gestores das linhas de negócio contratarem diretamente serviços em nuvem (Iaas ou SaaS, por exemplo). O resultado do crescimento desordenado de serviços em nuvem pode levar a problemas de fragmentação de sistemas, falta de integração entre aplicações e é claro, ineficiência e aumento de custos.

Assim, as empresas que estão adotando cloud devem colocar a gestão de seu ambiente de TI (interno ou terceirizado) como pré-requisito. Frameworks como o ITIL colocam a empresa em um nivel de maturidade suficiente que as permita obter os beneficios da computação em nuvem.

Discutindo SaaS

2011 começou corrido. Logo na primeira semana uma conversa com um CIO de uma grande empresa sobre Cloud Computing e SaaS. O assunto esquentou bastante ano passado e neste já começamos a ver as primeiras ações concretas. A conversa é bem emblemática das principais dúvidas que ainda persistem sobre o tema e acho que vale a pena compartilhá-las aqui.

A primeira questão que apareceu na reunião e que volta e meia surge nas discussões sobre SaaS é se realmente este modelo reduz os gastos da empresa com software. Na minha opinião, o modelo SaaS tende a reduzir os custos iniciais porque não demanda investimentos prévios em licenças e infraestrutura de suporte como eventuais aquisições ou expansões de hardware para acomodar o novo sistema. Além disso, o SaaS tenderá a se manter mais econômico ao longo do tempo, uma vez que observamos que o modelo tradicional constantemente demanda um upgrade significativo (da versão x para uma versão y) e estes upgrades muitas vezes representam de 30% a 40% do custo inicial da aquisição do software. Não existem estes custos de upgrade no SaaS. Outro ponto que favorece o modelo SaaS são os custos de suporte, uma vez que no modelo on-premise devem ser adicionados aos custos totais, os custos dos profissionais que suportam o hardware e o banco de dados.

Outra pergunta que apareceu na reunião é se realmente um sistema SaaS é mais fácil e rápido de implementar que um sistema on-premise equivalente. O SaaS tem a vantagem de não haver necessidade de se dispender tempo em instalação e configuração do sistema e dos componentes agregados, como um novo servidor. Mas, uma parte substancial do tempo de implementação de um sistema aplicativo depende do seu nivel de intervenção nos processos de negócio da empresa. Nesta etapa não existem maiores diferenças entre um SaaS e um on-premise.

Uma terceira dúvida foi como integrar sistemas SaaS com os legados, que operam na modalidade on-premise. Esta é uma variável importantíssima. Dificilmente uma corporação de médio a grande porte fará uma migração total para SaaS de um dia para o outro, e mesmo tenho dúvidas se conseguirá fazer esta transformação em um futuro previsível. Portanto, integrar SaaS e on-premise é um aspecto fundamental da estratégia de SaaS e deve ser visto com bastante cuidado. A integração pode ser simples, com uploads e downloads de e para a nuvem via processos batch, ou em tempo-real, via Web services. Esta última opção pode gerar alguns problemas de performance uma vez que as transações viajarão pela Internet. Mas, se os SLA permitirem eventuais variações de performance causados pelo elemento externo e incontrolável (Internet), tudo bem…

Na prática, à medida que mais e mais experiências concretas com SaaS se disseminem, os receios tendem a diminuir e o modelo vai se disseminar mais rapidamente. Por outro lado, os gestores de TI não devem ficar alheios à entrada dos sistemas SaaS nas empresas. Pela facilidade com que se contrata e se opera um sistema neste modelo, os executivos de negócio podem ficar tentados a bypassar a área de TI e começar a usar os sistemas SaaS diretamente. Mas, em algum momento será necessário integrar o sistema SaaS com os sistemas legados. Além disso, alguns SaaS, como o salesforce permitem a criação de aplicativos add-on, através de uma plataforma própria (como o Force.com, que é um exemplo típico de PaaS). Escrever estes novos aplicativos vai demandar desenvolvedores profissionais e a área de TI deve estar preparada para esta demanda.

2011 vai esquentar bastante em termos de SaaS. Os profissionais e gestores de TI devem estar antenados com este movimento. Minha recomendação a aqueles para os quais ainda “a ficha não caiu” é que deixem de ser observadores e passem a liderar sua adoção nas empresas.

Compliance em Cloud: alguns pontos importantes

À medida que torna-se mais conhecido, o modelo de Cloud Computing atrai mais atenção, mas um dos seus desafios ainda não resolvidos é a questão da compliance. Andei pensando um pouco sobre este assunto e gostaria de compartilhar algumas idéias com vocês.

A disseminação dos serviços de nuvem muitas vezes esbarra nos aspectos regulatórios. Algumas leis nacionais, como o Patriot Act dos EUA, afetam a privacidade dos dados e cria limitações para empresas estrangeiras usarem provedores de nuvens com data centers localizados nos EUA. O Patriot Act dá poderes ao FBI de exigir de qualquer organização o acesso a seus dados, bastando para isso identificar que a informação é pertinente a uma investigação autorizada. O texto completo do Patriot Act pode ser visto em http://epic.org/privacy/terrorism/hr3162.html.

Ao usarmos os serviços de determinados provedores globais de cloud computing, que não divulgam onde nossos dados estão armazenados, podemos estar sujeitos a legislações locais que conflitam com nossos objetivos de compliance. Por exemplo, empresas européias não armazenam seus dados em data centers localizados no teritório americano porque o Patriot Act conflita diretamente com as demandas de privacidade como definidas pela sua legislação (EU Data Privacy Initiative).

Outro ponto importante é que embora cloud seja um modelo de outsourcing, a reponsabilidade final pelo compliance é da empresa que usa o serviço em nuvem e não do provedor da nuvem. E dependendo da camada de serviços em nuvem contratados, o grau de responsabilidade e controle pode variar bastante. Por exemplo, ao contratar um serviço de IaaS, o provedor só pode assumir a responsabilidade de garantir a integridade e compliance do data center e das suas plataformas de hardware e software básico. Por outro lado, este provedor não tem como conhecer as aplicações dos seus usuários e portanto não pode garantir o compliance dos dados destas aplicações. O controle da aderência ao compliance é exclusivamente do usuário. Já ao contratar SaaS, o provedor deve assumir a responsabilidade pelo compliance, uma vez que o usuário não tem nenhum controle sobre o aplicativo. Mas em ambos os casos, o usuário é o responsavel legal pelo compliance e portanto deve garantir que seus provedores estejam aderentes, para evitar eventuais problemas jurídicos.

Um exemplo? Imaginemos que o usuário deva estar aderente à regulação PCI (Payment Card Industry Data Security Standards) e contrata um serviço em nuvem. Se a modalidade contratada for IaaS, o provedor deve garantir apenas o compliance da infraestrutura. O compliance do aplicativo é por conta do próprio usuário. Mas se a contratação for para SaaS, o provedor deve oferecer compliance também na camada do aplicativo. Mas o usuário deve se assegurar com evidências que o provedor está realmente compliance.

Outra questão ainda em aberto é se a legislação um país alcança outros territórios. Por exemplo, debate-se se o Patriot Act alcança data centers localizados em território fora dos EUA, caso estes data centers sejam de propriedade de empresas americanas.

O que fazer diante destes questionamentos? Ignorar cloud não é a melhor alternativa. Indiscutivelmente que cloud vai entrar nas empresas. Portanto, a melhor alternativa é estudar o assunto e colocar o jurídico da empresa analisando a questão. Analise cuidadosamente os aspectos de privacidade, jurisdição, facilidades de auditoria externa e investigações forenses, período de retenção dos dados por questões legais e possibilidade de verificação dos processos. É importante selecionar bem os provedores de nuvem e trabalhar de forma colaborativa com eles na questão do compliance.

Analisar bem o nivel de compliance dos provedores é essencial. Vamos olhar, por exemplo, as ofertas em nuvem da Amazon. Lendo seu agreement (http://aws.amazon.com/agreement/) observamos alguns aspectos interessantes:

a) Seção 4.3 diz expressamente “We are not responsible for any unauthorized access to, alteration of, or the deletion, destruction, damage, loss or failure to store any of Your Content or other data which you submit or use in connection with your account or the Services.”.
b) Seção 7.2 expressa: “We will have no liability to you for any unauthorized access or use, corruption, deletion, destruction or loss of any of Your Content or Applications.

Observe que estas salvaguardas por parte dos provedores são relativamente comuns e não apenas por parte da Amazon. Assim, analise os provedores de nuvem quanto ao seu grau de compliance e suas certificações, e se estão estão aderentes às demandas de sua empresa. Os profissionais de segurança da informação e de auditoria devem ser convocados para ajudar a garantir o nivel de compliance desejado. A Amazon via seu serviço de EC2 não garante aderência adequada? Armazene seus dados lá de forma criptografada. Ou então, crie uma private cloud hospedada em uma nuvem publica. Alguns provedores permitem isso.

Enfim, sempre há o que fazer, mas não deixe que as dúvidas e receios quanto ao uso de cloud impeçam você de seguir em frente.