Recebi um artigo muito interessante, escrito por Brian Requarth e Thomas Floracks, diretores da VivaReal Network – uma “real estate marketplace” (espécie de agregadora de imóveis) que iniciou operações no Brasil (entre outros 12 países). Confira a tradução.
Em uma época em que a economia mundial deu uma estagnada, investimentos crescentes em tecnologia inteligente vem sendo feitos para redução de custos. Como um empreendedor que tem trabalhado principalmente nos Estados Unidos, os últimos anos me inspiraram a olhar para oportunidades no exterior.
No início de 2009, decidimos lançar um projeto no Brazil porque reconhecemos as oportunidades incríveis que o país apresenta em termos de crescimentos na economia, penetração de Internet e consumidores que passam bastante tempo on-line. Usar hospedagem na nuvem nos ajudou a manter custos baixos no lançamento beta do VivaReal, em um dos mercados mais animadores do mundo. Escrevi este artigo para dar uma ideia para as outras startups web sobre como podem se beneficiar disso.
A maioria das organizações aluga ou compra seus próprios servidores. Para startups com verba limitada, isso pode ser um custo alto. Além disso, replicar um ambiente para teste de estresse da estrutura costuma ser bem caro. Não sei quanto a vocês, mas quando começamos a olhar para os nossos custos, que dobravam a cada mês apenas por replicarmos um ambiente de teste, ficamos preocupados. Pensamos que deve haver outro jeito.
Bem-vindos ao mundo da computação em nuvem (cloud computing)! Podemos definir abordagens como infra-estrutura como serviço, plataforma como serviço e software como serviço. A palavra-chave é serviço. A indústria mudou: de comprar e alugar hardware (equipamento) para contratar serviço de um provedor. Vamos examinar um exemplo, Amazon Web Services (AWS), e como nós o usamos para hospedar nosso aplicativo.
Como funciona
A infra-estrutura do EC2 (Amazon Elastic Compute Cloud) é um centro de dados virtualizado e uma fazenda de servidores. O que nós realmente gostamos neste conceito é que ele acima desta camada de virtualização nós podemos lançar instâncias, etapas, lances de servidor por meio de simples chamadas de API ou uma interface web.
Quando se lança uma instância, há duas opções para as características do equipamento do servidor: CPU, memória, espaço em disco, 32bit x 64bit e performance I/O. Esta flexibilidade foi um dos fatores-chave pelos quais escolhemos usar o EC2 para hospedagem. Como uma startup, ficamos inseguros quanto aos requisites de equipamento e não tivemos tempo ou outros recursos para fazer testes caros de carregamento ou simulações de escalabilidade. Então apenas iniciamos e esperamos tudo dar certo.
Utility?
Na cobrança do EC2 e uso do S3 (Amazon Simple Storage Service), a Amazon usa o termo utility computing, que diz respeito ao modelo de negócio “pague o quanto usa”. Gosto do fato de pagar apenas pelos recursos realmente utilizados. O EC2 é faturado por horas de uso e o uso do S3 é baseado na quantidade de hospedagem que utilizamos. Para todos os serviços da Amazon, os usuários também pagam tráfego externo por GB transferido.
Vantagens perante a hospedagem clássica
Toda startup procura pela vantagem de poupar recursos. Hospedagem em nuvem é um complemento-chave para manter os custos baixos, e ao mesmo tempo permitem crescimento de escala:
- dispensa investimento inicial;
- dispensa contrato de longo prazo;
- pagamento por hora de servidor utilizada.
Outros fornecedores
É claro que a Amazon não é a única provedora de “infra-estrutura como serviço”. Muitas outras oferecem serviços similares – alguns mais especializados do que outros. Exemplos:
- Rackspacecloud;
- LocaWeb;
- Microsoft Azure Platform;
- Sun Cloud.
Este artigo foi enviado originalmente em inglês por Brian Requarth para publicação no Startupi.
Para ler mais:
- How cloud & utility computing are different (no GigaOm);
- 2010: o ano em que a gestão vai para as nuvens (no Saia do Lugar);
- blog Computing on the cloud
- Open Cloud Manifesto
11 comments
O escalonamento da nuvem através de APIs não é tão simples e barato como se imagina. Enquanto o custo de operação é mais baixo do que o modelo tradicional "por servidor", é necessário que você invista no desenvolvimento de componentes que irão interagir com as APIs nos processos de alocação e dispensa de recursos, ou seja, além da sua aplicação, você precisará desenvolver uma camada de gerenciamento da nuvem. Agora imagine que essa camada é dependente da estratégia do provedor do serviço, ou seja, se amanhã ele resolver mudar a forma como as APIs são "chamadas", você pode ter que mudar seu aplicativo também… por força de uma decisão do seu fornecedor… e não do seu cliente.
Outro ponto de atenção do modelo de APIs é a necessidade de criação de imagens de servidores. Assumindo que a sua aplicação dedica um servidor físico (instância) ao App Server e outro ao banco de dados, o escalonamento acontece quando você é capaz de multiplicar os App Servers para o mesmo banco de dados. Cada instância deriva de uma imagem pré-definida do seu App Server original, portanto, a cada alteração no seu sistema você terá que gerar uma nova imagem. Dai cria-se um novo processo na sua operação, o de gerenciamento de imagens, que obviamente terá seu custo.
Já no Google App engine é diferente, a nuvem já dispõe de tecnologias que monitoram o desempenho da sua aplicação e alocam recursos automaticamente quando necessário. Nesse caso você pode focar o desenvolvimento apenas na sua aplicação, deixando o gerenciamento da infra-estrutura a cargo do Google.
Não trabalho no Google, mas venho avaliando diferentes fornecedores de cloud (e "cloud") desde fevereiro do ano passado, e percebi que há muitos detalhes nas entrelinhas, que só são percebidos quando colocados na planilha de custos do projeto (e do business plan).
De fato, na minha opinião, o AWS e seus concorrentes são um dos pega-bobo mais aclamados e últimos anos. Está tudo mundo literalmente com a cabeça nas nuvens acreditando que cloud hosting é sempre a melhor solução (em termos de custo vs benefício) de hospedagem para startups, mas não é bem assim. Como diz o pessoal da roça, "cada qual com o seu cada qual" :)
Para ambientes de desenvolvimento e para fazer testes de estresse, conforme menciona o artigo, ou até mesmo para executar batches de jobs não frequentes, cloud hosting é sim o ideal pelo fato de se pagar por hora. Já para casos de servidores de aplicação, banco de dados e outros servidores de produção que vão funcionar 24/7, a menos que o site tenha demanda muito baixa e possa dar conta do recado com apenas um servidor virtual (caso da grande maioria, é verdade), um bom e velho servidor dedicado "bare metal" ainda tem custo bem menor se comparado com a performance que entrega.
A grande vantagem do cloud hosting é mesmo a comodidado. Por exemplo, é mais simples jogar suas milhões de imagens no S3 e deixar a amazon cuidar da disponibilidade, sistema de arquivos e distribuição do que fazer isso numa máquina dedicada totalmente sob seus cuidados. Ou ainda, a grande facilidade pra criar novas instâncias a partir de outras pré-configuradas, em poucos segundos.
Mas como o Rodolpho mencionou existe a curva de aprendizado para lidar com a API do fornecedor e voltando à questao do custo, como em todo produto ou serviço neste planeta em que a comodidade é maior, o preço também será.
Hi Rodolpho and Diego,
I apologize for writing in English. I can read and understand Portuguese, mas aindo nao escrevo muito bem :) Thank you for contributing your thoughts to the article and stating your counter opinion. We recently published an article that went much more in depth in a tech magazine in Bogota. It went more in a few (not all) of the topics you bring up, but I decided to keep it a little shorter so I left out a few things. Thanks for complementing the post. Rudolpho, your comments about the Google App Engine are spot on. Diego, thank you for helping reinforce the idea that this is not a simple execution. There is definitely a learning curve, but in our case, it has paid off.
Thanks for your feedback and the valuable additions to our article.
It is important to know that the "cloud computing" is not the holy grail of hosting or a one size fits all solution.
As with any business decision management has to evaluate carefully if a cloud hosting solution is the best solution.
There are certain trade-offs in flexibility you have to be willing to make and you have to accept a higher level of dependency on your provider.
In the case of Amazon AWS this level of dependency is lower as you can choose to what level you want to use the API services. You have the freedom to implement your own architecture and scaling mechanisms or to use the ones that Amazon provides, e.g. use Amazon´s scalable based cloud database (SQS) or implement your own solution on a server instance in the Elastic Computing Cloud (EC2). If you only use the infrastructure (EC2) in most cases moving to a different provider could be done with little effort.
In the case of Google App Engine you are almost "married" to Google as a provider as this service qualifies as "Platform as a Service". You gain awesome scalability but you have to develop exactly in the environment that Google provides with all the limitations that Google defined for App Engine. As you exclusively make use of API calls for example for the database you lose complete control of important parts of your infrastructure. Moving an application away from App Engine means rewriting it in big parts.
The dependency on your provider and the loss of control is the biggest risk to cloud computing in my opinion. Companies have to evaluate carefully to what level they are willing to accept this dependency and what they can do to mitigate the risk.
Thomas, excellent point on client to Google "marriage"! That's another item to our trade-off equation: cost of change. At GAE you don't pay to use the platform if your operation is small, but, as you well mentioned, once you're using their toolkit the cost of moving it to another provider is huge due to code rewriting.
Do you think the same rationale applies to MS Azure?
Um ponto simples, mas não trivial. Como uma startup consegue, quando ainda sem investimento ou sem monetização, adquirir servidores com configurações muito parrudas (ex: tipo 64 GB de RAM) para suprir demandas eventuais? Quando se paga este tipo de infra por hora é mto mais fácil de ajustar no orçamento que comprar o servidor (ou alugar por mês) e ficar com pelo menos 50% do tempo sub utilizado. Pode até ser que quando se tem um serviço enorme se consiga utilizar melhor os recursos e cortar custos administrando o seus próprios servers, mas AWS é o atalho que ajuda os pequenos a ter acesso a infra de gente grande, apenas quando necessário.
I am not that familiar with Azure yet. But I know a MS Architect who is currently migrating his application to Azure. The migration was very easy to do (.NET) and from what I understand the "cloud version" of SQL server behaves pretty much the same as the regular stand alone SQL Server.
Hi Brian,
I am not a developer but am looking into investing into a few companies that are very early stage and focused on "the Cloud". As such, I am trying to educate myself as much as possible. Could you be so kind as to share the fuller article? My e-mail is pierre at pierreschurmann.com. Thank you in advance.
Hi Pierre,
The article should be published this month. As soon as it is, I will more than gladly send you the link. You can DM @brianrequarth
Kind regards
Rodolpho, também acho a proposta do GAE fantástica! Porém, como o Thomas mencionou, trata-se de PaaS. Outro fator a ser lembrado, é que eles suportam Java ou Python somente. E sendo assim, considero o GAE bem interessante para a hospedagem de aplicações individuais, quando a startup já tem uma infra-estrutura elaborada. O fato de ficar "amarrado" ao fornecedor não é legal :D
Acredito que a ideia de startup é ainda pouco difundida no Brasil. O artigo ressalta vários pontos e merece toda credibiidade. Estou há dois anos trabalhando com uma startup e vejo como uma grande oportunidade de crescimento.
Our apologies, you must be logged in to post a comment.