amazon_
Escalando sua
infraestrutura
com o tamanho do
seu negócio
com Amazon Web Services
Usando a Amazon para montar e escalar uma
infraestrutura robusta de acordo com as métricas do
negócio e sem investimentos iniciais, pagando só pelo uso
Bruno Pereira | @blpsilva | [email protected]
é sócio-diretor da Rivendel Tecnologia e engenheiro de Computação pela UFRJ. Tem 11 anos de experiência na área, com principal
background em Java, com as certificações SCJA, SCJP, SCWCD e SCEA. Trabalha há 6 anos com desenvolvimento ágil e inovação em
startups e grandes corporações. Trabalha há 4 anos com Amazon Web Services, com mais de 50 clientes atendidos. Autor de livro
sobre AWS pela Casa do Código.
V
amos supor que você é founder e CTO de uma
startup no segmento de comércio eletrônico,
ainda em fase de investimento anjo ou seed, com
fôlego para rodar a empresa por alguns meses até
conseguir evidências de que seu negócio ganhou tração e merece rodadas adicionais de investimentos.
Ser minimalista é a única forma de sobreviver, tanto
em decisões quanto ao espaço físico como em gastos
com equipamentos, servidores, licenças de software
e outras coisas. Você precisar concentrar suas despesas nas pessoas que compõem o time e no “inbound
marketing”[1]. Baseado nestas premissas, você deci/ 22
diu construir seu negócio com Cloud Computing e
Open Source, usando uma plataforma sem CAPEX[2]
e com diversos profissionais de primeira linha capazes de compor seu time.
Porém, ser minimalista não pode implicar em ser
menos robusto. O segmento de comércio eletrônico
no Brasil é muito competitivo e o custo de aquisição
de clientes[3] é muitas vezes o principal fator de sucesso ou fracasso de uma startup. Quando uma campanha “acertar na mosca” e seu negócio experimentar um crescimento acelerado de clientes e vendas,
sua aplicação e sua infraestrutura precisam estar
A Amazon revolucionou o mercado de infraestrutura de servidores
ao lançar sua plataforma Amazon Web Services (AWS) em 2006.
Com a AWS veio o conceito de nuvem de fato, onde você não se preocupa com a localização e com a capacidade de expansão dos recursos. Veio também uma mentalidade bem diferente de lidar com
infraestrutura e serviços. Os problemas clássicos de adivinhar o volume de acessos e o tempo enorme para compra de servidores físicos
parecem um passado longínquo. Na pegada de startups, a habilidade de conduzir experimentos e rapidamente ajustar a direção de
acordo com as métricas obtidas só é possível em sua plenitude com
uso de algum tipo de nuvem. Neste artigo mostraremos como usar a
Amazon para ter todo este poder em mãos.
prontas para comportar as visitas e transações que
surgirem. As perdas financeiras e de marca quando
seu produto fica indisponível são muito sensíveis
e podem arruinar meses de trabalho bem-feito. O
segmento de varejo tem uma sazonalidade bem conhecida, e datas como Dia das Mães, Natal e Black
Friday certamente trarão picos de acesso até 100 vezes maior que sua média, ou até mais que isso. Nosso objetivo no artigo é mostrar como ter uma infraestrutura muito eficiente em custo e mesmo assim
conseguir responder a todas as demandas dos seus
clientes.
23 \
Criando do zero a sua infraestrutura na
Amazon
De acordo com suas premissas, você escolheu
usar o Magento como sua plataforma de comércio
eletrônico inicial. Para chegar ao nosso Minimum
Viable Product[4], vamos começar com uma loja beta
bem enxuta, capaz de apresentar os produtos e o seu
diferencial, mas ainda não com os refinamentos para
operação em larga escala. Para uma instalação atual
mínima do Magento na Amazon, precisamos de:
» Servidor Linux no mínimo Small (é possível
fazê-lo rodar numa instância Micro, mas de
forma instável, não recomendada)
» Servidor Apache a partir da versão 1.3 ou Nginx
» Php 5.2 ou 5.3 (a 5.4 funciona, mas não é suportada oficialmente ainda)
» MySql 5.0.2 ou superior
O ponto de partida para criar sua infraestrutura
na Amazon é criar uma conta, em http://aws.amazon.
com. Na caixa Formas de Cobrança na Amazon descrevemos brevemente as opções, mas a mais rápida
para testes é o cadastro de um cartão de crédito internacional.
Tendo uma conta válida, vamos acessar a console
da Amazon e entrar na opção EC2 (Elastic Compute Cloud), onde fica a Dashboard de administração
das instâncias (servidores virtuais da Amazon). Por
padrão em contas novas somos encaminhados para
a região US-East (North Virginia). No canto superior
direito da tela podemos ver o nome do usuário e uma
caixa de seleção com a região atual.
Figura 1. Nome do usuário e caixa de seleção de regiões.
Para muitas aplicações a latência para acesso aos
Estados Unidos não é tão relevante a ponto de impactar a experiência de uso, e hospedar a infraestrutura
em uma região nos Estados Unidos é geralmente a
opção mais barata e interessante para uma startup.
Porém, isto deve ser avaliado em cada cenário e comparado de forma objetiva com testes. A Amazon possui quatro regiões nos Estados Unidos (uma exclusiva
para Governo), uma na Europa, três na Ásia/Pacífico e
uma na América do Sul (São Paulo).
Primeira Topologia
É muito comum começarmos a usar o Magento
com todos os componentes instalados no mesmo servidor, conforme a figura 2.
/ 24
Há duas formas de cobrança diretamente com
a Amazon: cartão de crédito internacional ou
wire transfer (transferência bancária direta
para os Estados Unidos). Para clientes que
desejam ou precisam de uma fatura em R$
a única opção é a contratação dos serviços
da Amazon através de um parceiro, como a
Rivendel tecnologia.
Figura 2. Topologia inicial do Magento na Amazon.
Para chegar nesta topologia, passamos pelas seguintes etapas:
1. Escolha da AMI (algo como um template pré-configurado) do servidor
2. Escolha do tipo da instância e zona de disponibilidade
3. Escolha dos dispositivos de armazenamento
4. Chaves de acesso e grupos de segurança
5. Associação de um Elastic IP e apontamento
DNS
No modelo On-Demand esta infraestrutura custaria aproximadamente US$ 0,06 por hora, e sem
nenhum contrato ou compromisso de permanência.
Podemos ver a facilidade e baixo custo para vários
experimentos e a possibilidade de começar sem nenhum investimento pesado em infraestrutura. Caso
fique ligado em tempo integral, o custo da infraestrutura inicial ficaria em cerca de US$ 45 mensais,
considerando um volume de acesso ainda moderado.
Definições sobre a infraestrutura até agora
amI (amazon machine Image): é um template usado para criar novas instâncias. Podemos usar
imagens públicas mantidas por vários fornecedores
ou também criar nossas próprias AMIs com ambientes previamente configurados e prontos para serem
inicializados.
Tipos de instância: a Amazon trabalha com tipos de instância padrão, com quantidades de recursos
bem definidas. Há atualmente 18 tipos de instância e
cada um deles possui diferenças quanto à quantidade de memória, capacidade de processamento e desempenho de storage e de rede. Na Amazon todos os
recursos são compartilhados entre instâncias e em
linhas gerais quanto maior o tamanho da instância,
mais prioridade ela tem nos recursos compartilhados,
especialmente quanto ao storage e à rede.
Regiões e Zonas de Disponibilidade: a Amazon possui nove regiões e cada uma delas se divide
em algumas Zonas de Disponibilidade. Cada zona
de disponibilidade é o equivalente a um datacenter,
com estrutura física, alimentação elétrica e links de
rede/internet totalmente independentes em relação
às outras zonas. Todos os recursos que criamos em
uma determinada região são conhecidos e compartilhados somente dentro da mesma região, incluindo
instâncias, bancos de dados, configurações de segurança, chaves de acesso, entre outras coisas. É muito
comum vermos topologias multizona, com aplicações
rodando em múltiplos datacenters de uma região. Topologias multirregião já são bem mais raras e mais
complexas de implementar.
Chaves de acesso: cada instância fica associada
a uma determinada chave de acesso no momento da
criação. Com instâncias Linux, estas chaves servem
diretamente para conexão SSH às instâncias. Nas instâncias Windows as chaves servem para obter a senha descriptografada do usuário Administrator, para
permitir as conexões Remote Desktop. Não é possível
alterar a chave de acesso de uma instância após a sua
criação.
Grupos de segurança: cada instância fica também associada a um grupo de segurança no momento
da criação. Estes grupos de segurança servem para
definir as regras de acesso a portas e protocolos em
cada instância do grupo. Podemos definir regras para
os protocolos TCP, UDP e ICMP, definindo a partir de
quais IPs ou quais grupos de segurança é liberado o
acesso ao protocolo/porta em questão. Na figura 3
temos um exemplo de definição de regras de acesso.
Os grupos de segurança são semelhantes a Firewalls,
porém eles permitem apenas a definição de regras de
entrada (inbound) nas instâncias. Para definir regras
de saída das instâncias é necessário usar Firewalls
dentro das mesmas.
Elastic IPs: são endereços de IP públicos que podem ser associados às instâncias em execução.
Dispositivos de armazenamento: há alguns
tipos de armazenamento disponíveis na Amazon,
mas o mais comumente usado em instâncias EC2 é o
Elastic Block Store (EBS), um storage de rede que fica
anexado a uma instância e “montado” localmente.
Refinando a infraestrutura
Nossa primeira topologia concentra todos os
componentes em uma única instância, o que deixa
a arquitetura bastante vulnerável a falhas. À medida
que nosso negócio vai crescendo e ficando mais valioso, uma etapa bem comum é segregar o servidor
web do servidor de banco de dados. Podemos criar
uma nova instância EC2 para o banco de dados, mas
no caso do MySql é muito interessante criar uma instância RDS (Relational Database Service).
O RDS é um serviço de banco de dados escalável e
eficiente em custo, que permite o uso de um banco de
dados bem gerenciado sem investir tempo em tarefas
de administração de banco de dados. A Amazon oferece o RDS para MySql, Oracle e Sql Server. A EnterpriseDB oferece um serviço muito semelhante para o
Postgresql. A topologia com a inclusão do RDS pode
ser vista na figura 4.
Figura 3. Definição de regras de acesso de um grupo de segurança.
25 \
que o negócio realmente ganhou tração e as indisponibilidades deixarem de ser algo aceitável. Tanto
nosso servidor web como nosso servidor de banco de
dados são pontos únicos de falha, e qualquer indisponibilidade em um dos componentes nos deixará sem
vender.
A Amazon simplificou muito o trabalho de construir uma arquitetura realmente robusta, com o uso
de topologias com múltiplas zonas de disponibilidade, ou multizona. Todas as regiões da Amazon possuem pelo menos duas zonas de disponibilidade, então a abordagem que vamos descrever aqui funciona
na Amazon como um todo.
Introduzindo um balanceador de carga
Figura 4. Topologia com o servidor de BD usando RDS, segregado
do servidor web.
A introdução de uma instância Micro do RDS
MySql aumenta o custo da infraestrutura em cerca de
US$ 0,025 por hora, ou US$ 18 mensais, e alivia a carga do servidor web que antes continha toda a infraestrutura. Uma característica interessante desta nossa
infraestrutura é que ela começa bem enxuta e eficiente, mas é bem fácil e rápido crescer verticalmente
os componentes que escolhemos até agora. Na figura
5 podemos ver a opção “Change instance type”, que
permite que façamos upgrade (ou downgrade) do tamanho do servidor de forma quase imediata (porém
é necessário parar o servidor para fazer a alteração).
Isto é muito mais fácil do que migrações convencionais em servidores físicos e até mesmo em servidores
virtualizados, onde os limites do que pode ser feito
aparecem bem mais rápido.
Com esta revisão nossa infraestrutura custará
cerca de US$ 65, ainda bem suave.
Alta disponibilidade
A etapa seguinte de refinamento da arquitetura/
infraestrutura é essencial a partir do momento em
Para trazer maior redundância e disponibilidade
ao servidor web, vamos colocar entre ele e os usuários
finais um balanceador de carga, que é um elemento
comum em infraestruturas de Produção e distribui
os acessos de usuários finais em 1 ou mais servidores. No caso da Amazon há o Elastic Load Balancer,
um balanceador via software que escala automaticamente sua capacidade de acordo com a demanda
e também é pago somente pelo tráfego, sendo muito
econômico.
Nosso objetivo é ter pelo menos duas instâncias
ativas do servidor web, e usando uma topologia multizona, para que eventuais instabilidades em uma das
instâncias ou mesmo em uma zona de disponibilidade inteira não tragam indisponibilidade para nosso
produto.
Para ter uma segunda instância em execução,
vamos primeiro criar uma AMI da nossa instância
original, para poder usá-la na criação de novas instâncias. Isto é feito selecionando a instância desejada
e clicando na opção “Create Image (EBS AMI)”. A figura 6 mostra a caixa de opções para geração da AMI.
Costumo nomear as AMIs de acordo com o nome da
instância e a data/hora, ou então um nome referente
a alguma versão importante.
Após a criação da AMI, podemos criar novos ser-
Figura 5. Opção “Change instance type”, que permite upgrade e downgrade de instâncias.
/ 26
Figura 6. Criando uma AMI a partir de uma instância.
Figura 7. Criando novos servidores a partir de uma AMI que criamos.
Figura 8. Elastic Load Balancer e as instâncias configuradas.
vidores a partir da mesma, como na figura 7.
Além da possibilidade de encaminhar requisições
Já com as duas instâncias criadas, vamos criar o para múltiplas instâncias, o Elastic Load Balancer
Elastic Load Balancer e colocá-lo para encaminhar traz outras vantagens, incluindo:
os acessos para as duas instâncias. Na figura 8 temos
»» Health check das instâncias para não encamiuma visão das instâncias configuradas para acesso
nhar requisições para instâncias que estejam
através do Load Balancer e uma informação sobre sua
indisponíveis
»» Capacidade de balancear usando sticky sesdisponibilidade. O balanceador também traz uma informação sobre as zonas de disponibilidade que consions, para que nas aplicações com sessão um
têm as instâncias atrás do balanceador.
determinado usuário seja sempre encaminha-
27 \
Figura 9. Ativar topologia multizona no RDS.
do para o mesmo servidor durante toda a sessão
»» Possibilidade de instalar um único certificado
SSL para atender a múltiplos servidores
Configurando o RDS MySql também em
multizona
Após conseguir a alta disponibilidade dos servidores web, precisamos ter o mesmo para o servidor
de banco de dados. O RDS possui uma configuração
bem simples para habilitar a topologia multizona,
como podemos ver na figura 9. Além disso também é
possível aumentar ou diminuir o tamanho da instância sem indisponibilidades para usuários finais.
A topologia revisada após estas modificações
pode ser vista na figura 10.
Com esta arquitetura já temos uma proteção significativa contra falhas em componentes individuais,
com redundâncias na camada web e na camada de
banco de dados. Não vamos entrar em detalhes sobre
outras possibilidades, mas é muito comum também
o uso de uma CDN como o Cloudfront para cachear
páginas estáticas e conseguir sustentar os sites para
leitura mesmo em períodos de indisponibilidade dos
servidores web. Além disso, é bem comum o uso de
camadas de cache de dados internos na aplicação,
como o Memcached e outros, que podem trazer proteção adicional contra falhas no banco de dados.
Supondo que tenhamos mantido os tamanhos de
instância do servidor web e do banco de dados, esta
infraestrutura custará cerca de US$ 140 mensais e é
capaz de comportar um volume expressivo de visitas
e transações.
Elasticidade
Tudo que discutimos até agora é muito interessante sob o ponto de vista de robustez e também de
flexibilidade. Porém, uma característica muito diferenciada da Amazon é a infraestrutura elástica. Em
infraestruturas mais tradicionais, a ideia de um negócio sazonal como o varejo é desesperadora. As empresas precisavam” chutar” com semanas de antecedência a quantidade de visitas e transações e torcer para
conseguir servidores temporários para poder atender
às demandas sem acumular um custo fixo balizado
pelo pico e não pela média.
/ 28
Figura 10. Topologia com alta disponibilidade do servidor web e
do banco de dados.
A Amazon é a maior varejista on-line do mundo,
então ela já vive este tipo de dilema desde 1994. A
plataforma AWS têm diversos componentes dotados
de características elásticas, aumentando ou diminuindo sua capacidade de acordo com a demanda.
Nossa topologia já estava usando o Elastic Load
Balancer e o Relational Database Service, e vamos
introduzir também o AutoScaling, que vai trazer a
escalabilidade horizontal aos nossos servidores web.
Auto Scaling resumidamente
Configurando um grupo de Auto Scaling, definimos algumas coisas como:
»» Imagem (AMI) utilizada para criar automaticamente novos servidores
»» Tamanho das novas instâncias que serão criadas
»» Tamanho mínimo e máximo do grupo
»» Políticas de Scale Up (criação de novos servidores) e Scale Down (desligamento de servidores)
Já criamos anteriormente uma AMI com a versão
atualizada da nossa aplicação para configuração da
topologia multizona e já configuramos também um
Load Balancer para encaminhar as requisições para
as duas instâncias de servidor web. Para configuração
do Auto Scaling é necessário usar a API da Amazon
para executar os comandos, pois ainda não há as configurações de Auto Scaling disponíveis no console de
administração.
A instalação é bem simples: precisamos ter o
JDK 1.5 ou superior, baixar a Command Line Interface (CLI) do Auto Scaling Tools e configurar algumas
variáveis de ambiente. O vínculo da CLI com a conta
da Amazon é feito através de um arquivo no qual pre- Listagem 3. Definição de políticas de Scale Up e
enchemos nossa Access Key ID e a Secret Access Key, Scale Down.
que farão a autenticação e autorização da conta na
API da Amazon.
as-put-scaling-policy MagentoScaleUpPolicy --autoNa Listagem 1 temos um exemplo de comando scaling-group magento-as
para criar uma “Launch Config”, e na Listagem 2 te--adjustment=1 --type ChangeInCapacity --cooldown 300
mos um exemplo de comando para criar o grupo de
Auto Scaling. Para finalizar, na Listagem 3 colocamos as-put-scaling-policy MagentoScaleDownPolicy --autoexemplos de definições das políticas de Scale Up e scaling-group magento-as
Scale Down.
“--adjustment=-1” --type ChangeInCapacity --cooldown 300
Após a criação dos grupos de Auto Scaling e das
políticas de Scale Up e Scale Down, a última etapa é
configurarmos os gatilhos que vão disparar a criação
e desligamento de servidores. Estes gatilhos são criados através de Alarmes do CloudWatch, usando métricas do tipo AutoScaling. Em linhas gerais as políticas de criação e desligamento de servidores seguem o
seguinte exemplo hipotético:
»» Após 3 minutos com os servidores acima de
80% de CPU, adicione 1 novo servidor ao grupo
e distribua os acessos entre eles
»» Após 3 minutos com os servidores abaixo de
30% de CPU, desligue 1 dos servidores do grupo
e redistribua os acessos dentro do grupo
Esta abordagem nos permite monitorar continuamente os servidores e tomar ações automáticas
dentro de nossas políticas quando o volume crescer
ou diminuir. Além disso, configuramos curvas suaves de subida e descida de servidores, para garantir
que nossa infraestrutura não vai crescer ou diminuir
abruptamente devido a picos de poucos segundos.
Esta abordagem claramente aborda sazonalidade de Figura 11. Topologia com Auto Scaling.
um jeito bem eficiente, pois a infraestrutura e os custos crescem ou diminuem de acordo com a demanda Algumas observações sobre o Auto
dos clientes, e não precisaremos pagar por um parque
Scaling
ocioso a maior parte do tempo. A Amazon cobra por
»» O Auto Scaling faz uso da escalabilidade hohora de uso dos servidores e com isso podemos pagar
rizontal, não vertical. Portanto um trabalho
um valor bem suave por uma quantidade adicional de
importante de arquitetura e infraestrutura é
servidores que ficam ligados por curtos intervalos de
encontrar o tamanho ótimo de cada instância
tempo, de forma sazonal.
para que tenhamos o melhor cenário em terA topologia final com a introdução do Auto Scamos de robustez e custo.
ling está na figura 11.
»» Embora o tempo de resposta do auto scaling
seja relativamente rápido, recomendamos que
Listagem 1. Criação da Launch Config.
os grupos tenham no mínimo dois servidores e
usem topologia multizona. Assim manteremos
as-create-launch-config --image-id ami-b754c687
--instance-type m1.small --group magento --region usa alta disponibilidade
east-1 --launch-config magento-small-config
»» O fato de usar AMIs padrão e poder a qualquer
momento ligar ou desligar servidores traz à
tona as preocupações quanto à persistência de
Listagem 2. Criação do grupo de Auto Scaling.
dados/arquivos das aplicações. Idealmente a
topologia deve ser construída de forma que as
as-create-auto-scaling-group magento-as
instâncias compartilhem alguns recursos e que
--launch-configuration magento-small-config
seja possível ter 2 ou 20 servidores em paralelo
--min-size 2 --max-size 4 --availability-zones
sem intervenções manuais. Isto tem implicaua-east-1a,us-east-1b,us-east-1d --load-balancers
ções típicas sobre uploads de arquivos, bancos
LoadBalancerMagento --region us-east-1
29 \
de dados, índices em disco e outros componenO Rackspace e o Windows Azure são os concortes, que devem ser desenhados permitindo a rentes mais similares à plataforma da Amazon, e um
escalabilidade horizontal.
comparativo entre estas plataformas provavelmente
geraria artigos completos, dada a quantidade de opções e riqueza de detalhes das plataformas. Ambos
Comparação com outras opções de
oferecem servidores Windows e Linux de vários tanuvem
manhos, cobrança sob demanda por hora e serviços
Neste artigo descrevemos abordagens comuns
de aplicação, como banco de dados, envio de e-mail,
para construir um novo negócio com a Amazon, que
entre outros.
é a plataforma de nuvem mais popular, com mais de
Considero a Amazon como uma opção mais com50% de market share. Porém, há outras opções que
pleta e madura, além de ter uma comunidade de usuoferecem alguns dos benefícios que a Amazon ofereários e clientes maior. Porém, esta é uma preferência
ce e algumas vantagens e desvantagens, dependendo
pessoal que pode não ser a realidade para o seu nedo seu contexto.
gócio e a sua situação. Há uma competição enorme
entre os provedores de Cloud e isto sempre traz inoHeroku
vações e incentivos para o uso que podem se encaixar
O Heroku é uma plataforma de aplicações que dá muito bem no seu produto ou negócio. Portanto, em
um acesso bem fácil para que desenvolvedores publi- vez de fazer uma escolha com pouca informação, requem suas aplicações na nuvem sem a necessidade comendamos a avaliação de alternativas ao provedor
de profissionais de infraestrutura. Isto certamente que for sua escolha inicial.
é conveniente e agiliza muito a condução de experimentos, especialmente por startups. O Heroku usa
por baixo a plataforma da Amazon, então muitas das
vantagens que a Amazon oferece, o Heroku também, Considerações Finais
Neste artigo buscamos ilustrar de forma objetialém de recursos adicionais.
va
como
começar um negócio usando a Amazon e ter
Porém, o Heroku acrescenta um custo consideráa
infraestrutura
cada vez mais robusta e refinada à
vel depois que sua plataforma começa a crescer e ter
medida
que
os
clientes
vão aumentando e com isso
um volume mais intenso. Com isso, é muito comum
as
visitas
e
transações.
Mostramos
etapas comuns em
as empresas saírem do Heroku para o uso direto da
uma
operação
que
vai
crescendo
e
as
abordagens para
Amazon após um amadurecimento do negócio.
conseguir alta disponibilidade e capacidade elástica
de forma bem simples e eficiente em custo. Em um
Google App Engine
contexto de Lean Startups, esse poder e flexibilidade
O Google App Engine é também uma opção mui- são ferramentas valiosíssimas, e recomendo a todos
to interessante de nuvem, porém numa categoria di- que no mínimo avaliem bem o que a plataforma Amaferente da Amazon, pois o App Engine é uma Plata- zon Web Services tem a oferecer para seu produto.
forma como Serviço (PaaS). Isto implica que você tem Você não gastará mais que alguns trocados para isso,
uma série de componentes prontos para o uso e paga e os retorno para seu negócio pode ser fantástico.
sob demanda, tendo também a elasticidade de forma
automática, mais fácil que na Amazon.
Porém, sendo uma plataforma como serviço, você
precisa construir sua aplicação pensando especificamente nos componentes do App Engine, o que te dá
bem menos flexibilidade do que opções de infraes/referências
trutura como Serviço (IaaS), nas quais praticamente
qualquer aplicação que funcione em um servidor fí> [1] > Inbound Marketing: http://en.wikipedia.org/wiki/
sico pode ser usada praticamente sem modificações.
Inbound_marketing
A decisão de usar uma Plataforma como Serviço
> [2] > Capex: https://en.wikipedia.org/wiki/Capital_
ou Infraestrutura como Serviço depende mais de asexpenditure
pectos de negócio e parcerias que a empresa deseja
firmar do que de possibilidades que as duas modali> [3] > Custo de aquisição de clientes: http://en.wikipedia.
dades oferecem. Ambas permitem que você cresça em
org/wiki/Customer_acquisition_cost
investimentos de acordo com o crescimento do negócio e sem CAPEX, então a avaliação depende de mui> [4] > Minimum Viable Product: http://en.wikipedia.org/
tos critérios importantes para o futuro da empresa.
wiki/Minimum_viable_product
Rackspace/Windows Azure
/ 30