carro barato Follow

Assim como Web 2.0, outro termo usado o tempo todo é Cloud Computing. Muita gente usa para designar muitas coisas. Outro termo usado como sinônimo – mas não sendo exatamente a mesma coisa – é Web Services (não o padrão XML), que na realidade não é nada novo, é o que antigamente chamávamos de ASPs (Application Service Providers). Exemplos disso são serviços como Basecamp para gerenciar projetos sem que a empresa precise gastar em manutenção ou mesmo seu Webmail favorito. São serviços online onde você paga para não precisar se preocupar com infraestrutura. É um tipo de outsourcing de serviços. Esta semana o Google causou um pequeno furor ao lançar sua resposta a Cloud Computing: o Google App Engine. Vocês podem ver um review do Techcrunch aqui. Mas o que é Cloud Computing? Antes de mais nada, vamos explicar os termos mais usados no mercado:Nós, que somos desenvolvedores, em algum momento vamos querer colocar nossa aplicação em produção. Eis quando chega a parte mais cabeluda do processo: Deployment! Existem várias opções. Primeiro vejamos sobre software: Comprar uma aplicação comercial. Casos de commodities como Exchange Server. Você precisa de um pacote de software para sua empresa, existem diversos no mercado. Você escolhe, compra, instala e começa a usar. Você pode comprar uma aplicação onde você o usa como quiser, ou aplicações maiores que vendem em regime de licenças, por exemplo, licenças por usuário ou licenças por processador. Alguns softwares permitem ser extendidos e customizados, mas normalmente você precisa se adaptar ao software e não o contrário. Adquirir uma solução open source. Baixar da internet você mesmo, configurar e usar, ou contratar uma empresa de serviços que faça esse trabalho para você. A vantagem, obviamente, é ser livre de custos, a desvantagem é que administrar esse tipo de configuração pode representar um custo que normalmente não é levado em conta. O TCO não é trivial, a aplicação pode ou não ser fácil de ser modificada. Varia de caso a caso. Fazer o sistema in house. Ou seja, programar o sistema você mesmo, customizado às suas necessidade. É o modelo alfaiate, onde você tem uma equipe de desenvolvedores ou contrata uma software house que fará o sistema como você precisa. Costuma ser mais caro, mas por outro lado pode ser necessário se não existem softwares comerciais que façam o que você precisa. Teoricamente deveria ser o tipo de software que mais se adequa à sua empresa. Obviamente a prática não é bem assim. O TCO costuma ser alto, o software costuma não ser tão bom, você como empresa precisa mudar bastante para se adequar a qualquer tipo de sistema (seja comercial, open source ou in house). Tudo depende da maturidade da própria empresa e do terceiro contratado para desenvolvê-la. Sua milhagem vai variar bastante e os resultados são incertos. Usar um ASP, ou seja, você ‘aluga’ uma aplicação de mercado, em planos de licenças, mas não precisa se preocupar em como fazer o deployment, instalar, manter atualizado, etc. Exemplos disso são aplicações como SalesForce.com, É uma solução menos customizável, mas costuma ter um custo muito menor se considerar o custo total de propriedade (TCO). Em muitos casos faz sentido. Apenas é necessário uma conexão estável à internet. Pode não ser o ideal, mas mantém seus custos baixos. O modelo de serviços é uma tendência simplesmente porque a atual infra-estrutura de internet como um todo possibilita isso. Enquanto desenvolvedor você desenvolve um software que pode servir para muitas empresas diferentes mas sem o problema de ter que instalar e dar manutenção a cada um deles separadamente: uma correção no sistema central beneficia toda sua base de clientes instantaneamente. Sobre opções de hardware, vejamos: Fazer o hosting você mesmo, comprando máquinas, montando redes, enfim, administrando você mesmo in loco, ou seja, fisicamente dentro do seu perímetro. À medida que sua empresa cresce, você compra mais máquinas. É mais indicado para aplicações de intranet, que apenas dizem respeito à sua empresa e não devem crescer a escalas muito difíceis de administrar. É mais indicado para empresas que tem setor de TI maduro para administrar tudo. Atualmente, toda empresa tem uma equipe mínima de TI, mas nem todas. TI normalmente não é o core-business da empresa, é considerado como custo, assim como pagar impostos. Faz sentido cuidar de tudo se seu core-business são esses sistemas. Fazer o hosting você mesmo, mas entendendo que crescimento não é linear. Você pode precisar de mais recursos apenas num período e não em outro, ou seja, comprar máquinas pode ser necessário apenas por um pequeno período, mas não sempre. Comprar novas máquinas o tempo todo apenas aumenta seu TCO. Nesse caso você pode “comprar” máquinas em regime de on-demand, como algumas linhas de servidores IBM, a chamada ‘on-demand’. Toda vez que você precisa de mais potência, liga pra IBM e pede que ela libere mais processadores na máquina que fisicamente fica no seu local. É uma solução limitada. Fazer co-location, onde você tem máquinas suas mas utilizando a infra-estrutura de terceiros, num CPD externo ao perímetro físico de sua empresa. É um jogo de custo-benefício, pois você normalmente não tem o expertise para manter uma infra-estrutura estável e robusta como um terceiro. Mas as máquinas são suas e é sua responsabilidade comprar mais se precisar. Em certos casos as empresas tem recursos para comprar mais máquinas, mas acabam não tendo espaço físico para concentrar tudo. Ou então a empresa tem filiais e todas precisam acessar o mesmo sistema. É mais fácil quando suas máquinas ficam num CPD responsável por manter suas máquinas ligadas o tempo todo, com rede estável e rápida, com suporte 24×7. Muitas empresas tem equipes de TI locais e sistemas fora do seu espaço físico. Usar Shared Hostings, literalmente hostings compartilhados, utilizando não somente a infra-estrutura de um terceiro, mas alugando um ‘pedaço’ da mesma máquina, compartilhada com outros clientes desse terceiro. Diversos planos podem ajudar a começar com custo mínimo de infra-estrutura, mas com a desvantagem de ser afetado negativamente quando um outro cliente usando a mesma máquina demandar mais recursos e sua aplicação sofrer gargalos, além de outros problemas como bibliotecas de sistema compartilhados e coisas assim. É um balaio de gato onde os provedores buscam soluções para melhorar isso, mas a natureza desse tipo de pacote impede algo realmente à prova de balas. Crescer num ambiente desses costuma ser limitado. Isso costuma favorecer programadores/freelancers ou pequenas empresas que precisam colocar seu website na internet mas não tem recursos para configurações muito parrudas. Usar VPS, ou Virtual Private Servers, ou seja, ainda compartilhar a mesma máquina que outros clientes desse terceiro, mas ao mesmo tempo ter a ‘sensação’ de ter uma máquina inteira apenas para você, mas virtual, isolada dos outros. É como se fosse um “Shared Co-Location”, onde a máquina não é sua, você a compartilha, mas ainda parece que tem uma máquina só sua. A vantagem é que esse isolamente o deixa livre de coisas como atualizações na máquina de um Shared Hosting ameaçando a estabilidade da sua aplicação. Costuma ser mais barato que um co-location pois você não está comprando uma máquina e sim alugando um slice (pedaço) de uma máquina que usa soluções como Xen ou VMWare. É o segundo passo para empresas que querem manter seus custos baixos mas precisam de mais flexibilidade. Mesmo assim ainda é um problema, como na situação de co-location, quando você precisa de mais slices apenas por um pequeno período mas não o tempo todo. Colocar um slice no ar costuma requerer tempo, e nesse caso você pode perder o time-to-market. Cloud Computing Entendido quais são os termos usados por aí, vamos ver agora o termo da moda. Não sei se foi o primeiro, mas com certeza o que tem feito mais barulho é o modelo dos produtos da Amazon Web Services como Elastic Cloud Computing ou EC2; Simple Storage Support ou S3 e SimpleDB. Em todos eles, o principal chamariz é o conceito de elastic on-demand. Ou seja, você paga por quanto usa, mas não precisa manualmente ficar reconfigurando tudo toda vez que precisar de mais. Se usar mais paga mais, se voltar a usar menos, ‘elasticamente’ se paga menos. É pagamento por uso de recursos, não mensalidade fixa por recursos fixos. Esses produtos da Amazon respondem pelos seguintes serviços: Storage, ou armazenamento (Amazon S3). Num modelo tradicional você compraria ou alugaria um servidor de arquivos. Storages online já existem há algum tempo, mas o S3 cria um modelo diferente de um file system normal, baseado no conceito de ‘buckets’. A vantagem da Amazon é o preço e a estabilidade. A desvantagem é que ele se baseia num modelo diferente de file system que não é inicialmente mapeável. Hoje existem dezenas de bibliotecas em diferentes linguagens, que facilitam a transição. Banco de dados (Amazon SimpleDB). Em vez de um Oracle, MySQL ou outros bancos de dados relacionais, a Amazon trouxe um banco de dados não-estruturado baseado em Documentos. A principal característica é a ausência de schemas fixos e, portanto, ausência da necessidade de administração custosa sobre seu domínio de dados. Logo, diminuindo a manutenção. Por outro lado ele também introduz barreiras de adoção pois ainda não existem muitos modelos, frameworks ou bibliotecas que permitam migrar trivialmente uma aplicação feita para ser relacional (usando SQL) para o modelo do SimpleDB. Novamente, a vantagem pode ser o preço. Virtual Private Server ou VPS (Amazon EC2). É como se você usasse VPS dinâmicas, ou elásticas. Se por algum motivo seu sistema requerer mais recursos (se houver um pico de vistas e transações no seu website), você pode ‘facilmente’ habilitar mais slices dinamicamente e derrubá-las quando não precisar mais delas. Você paga pelos recursos usados, não pela quantidade de slices que tem. Eles são dinâmicos. Você pode ter 5 slices pela manhã, 20 à tarde e voltar a ter 5 de noite. A pegadinha é que não serão necessariamente os mesmos 5 slices. É um modelo diferente que garante slices mas não quais. Sua aplicação precisa armazenar os dados fora do EC2, (ou no S3 ou no SimpleDB) para que outro slice possa assumir sem depender de dados locais. É Shared-Nothing levado às últimas consequências. Qual a vantagem? Você pode ter o que precisa, quando precisa. Em vez de se comprometer a planos caros de co-location ou VPS, você pode colocar sua aplicação aos cuidados da Amazon e ter mais dinamicidade no seu negócio sem se preocupar se suas máquinas ‘vão aguentar’. É como se você pudesse pagar academia pela quantidade de horas que você efetivamente frequentou, em vez de pagar uma mensalidade fixa. Se parar no meio do mês, você não perde a mensalidade inteira. É uma tendência no mercado de serviços. Qual a desvantagem? No caso da Amazon você precisa preparar sua aplicação segundo suas limitações e requerimentos. Principalmente se considerar que é normal seu slice ser derrubado. Os dados locais a esse slice são perdidos se não forem persistidos fora dele antes disso. Isso não é um problema se for levado em consideração como premissa desde o início, mas é um paradigma diferente do que estamos acostumados com co-location ou VPS clássica, onde seus dados locais são sempre permanentes e é uma responsabilidade do hosting fazer o backup para eventuais problemas. Google App Engine Chegamos à novidade da semana: o Google App Engine. Na prática, é uma solução que mapeia um a um os serviços da Amazon. Amazon Simple DB vs Google BigTable – nenhum dos dois são bancos de dados relacionais, portanto em nenhum você poderá pensar em seus dados como um RDBMS clássico. Amazon S3 vs Google GFS – novamente, não é um FS clássico, como o que tem na sua máquina. Amazon EC2 vs App Engine – parecido mas diferente, veremos a seguir. A vantagem do Google é que ela fez o marketing desse produto como sendo: “Sua aplicação rodando dentro de nossa infra-estrutura”, ou seja, todos sabemos que os famosos produtos do Google como o site de procura propriamente dito, Google Reader, Gmail, Orkut, etc todos rodam numa infra-estrutura proprietária altamente escalável que tornou o Google famoso e agora ela está ‘aberta’ (grátis mas não libre) para que outros usufruam disso. Vejamos vantagens e desvantagens: A desvantagem dos dois é que eles quebram paradigmas e portanto exigem aplicações feitas exclusivamente para um desses ambientes. Ou seja, escolher tanto um quanto o outro significa ficar fechado a um deles no sentido de que suportar ambos pode representar mais custos de desenvolvimento. A vantagem da Amazon é que seus serviços são independentes, ou seja, se você quiser apenas storage, então use o S3 sozinho. A desvantagem da Amazon é que seus serviços exigem mais conhecimento de integração que qualquer outro. A desvantagem do Google é que é uma proposição tudo-ou-nada: sua aplicação vai ficar toda lá dentro, não apenas pedaços. A vantagem é que o Google está proporcionando um ambiente online para administrar sua aplicação que o coloca um passo à frente em relação à Amazon quanto à usabilidade. Neste momento o Google apenas tem suporte a aplicações escritas em Python. Particularmente ele já vem com Django pré-disponível e com APIs que facilitam o manuseio dos recursos de dados e storage. Com certeza uma grande notícia para a comunidade Python. Isso gerou certa comoção entre desenvolvedores de outras linguagens, mas isso é normal. Se não fosse o Google, passaria despercebido como “mais um provedor de serviços”. Mas sendo o Google eles obviamente sabem que sempre receberão elogios e críticas massivas. Portanto, nada mais do que o esperado. Falar bem é democrático, falar mal também. Se eles não previram isso, alguém do departamento de Public Relations precisa ser demitido. De qualquer forma, não dêem ouvido a mais essas guerrinhas de linguagens: elas são fogo de palha: é apenas divertido agora elas não representam muita coisa: se o Google de fato previu isso e tem um bom PR, eles sairão ilesos o Google gosta de Python: isso é público e notório e não há nenhum problema nisso. Eles são uma empresa e empresas decidem o que querem, quando querem e como querem. O dia que vocês tiverem suas empresas, vão entender isso. na realidade, o Google nunca disse que o App Engine é exclusivo para Python, vejamos: No press release eles prometem suportar outras linguagens no futuro e que – como toda aplicação Web 2.0 que se preze – esta é uma versão “Beta”.[...]