O documento compara a computação em nuvem versus a infraestrutura tradicional em termos de escalabilidade, desempenho, disponibilidade e custos. Apresenta recursos como balanceamento de carga e auto-escalonamento na nuvem que podem facilitar a escalabilidade e reduzir custos em comparação ao modelo tradicional.

1.
COMPUTAÇÃO NAS NUVENS E INFRASTRUTURA TRADICIONAL: COMPARAÇÃO
DE ESCALABILIDADE, DESEMPENHO, DISPONIBILIDADE E CUSTOS
Thiago Alexandre Lenz
Professor(a) Orientador(a): Mestre Hugo Brito
Estratégias em Arquitetura de Software
RESUMO
Este artigo propõe o uso de computação em nuvem para atender desafios arquiteturais
como escalabilidade, desempenho, redução e gerenciamento de riscos e redução de
custos operacionais em sistemas baseados em plataforma web. Foi utilizando como
base o ambiente Amazon AWS. Inicialmente foi ressaltado a importância e as
tendências de mercado com o surgimento da computação em nuvem. Com base nisso
foi feito um levantamento teórico, apresentado o papel de um balanceador de carga e
configuração de um auto­scaling em ambiente Amazon AWS. Foi considerado o modelo
tradicional de data­centers para comparar com o modelo em nuvem. Em cima disso foi
feito um estudo de caso para comparar os desafios arquiteturais no contexto de cada
um desses dois modelos. A proposta é mostrar que a nuvem vem para ser prática e de
baixo custo.
Palavras­Chave​: Computação em Nuvem, Amazon AWS, Load Balancing e Auto­Scaling.
ABSTRACT
This article proposes the use of cloud computing to meet challenges such as scalability,
performance, reduction and risk management and reduce operating costs in systems
based on web platform. It was using as a basis the Amazon AWS environment. Initially it
was stressed the importance and market trends with the emergence of cloud computing.
Based on this a theoretical survey was made, presented the role of a load balancer
configuration and a auto­scaling on Amazon AWS environment. It was considered the
traditional model of data centers to compare with the cloud model. On top of that a case

2.
study was done to compare the architectural challenges in the context of each these two
models. The proposal is to show that the cloud has to be practical and cost effective.
Keywords​: Cloud Computing, Amazon AWS, Load Balancing and Auto­Scaling
1. INTRODUÇÃO
A era dos sistemas WEB foi marcada pela substituição dos sistemas legados
desenvolvidos em linguagens como DELPHI e VB.NET por soluções baseadas no
modelo cliente­servidor desenvolvidas em Java, PHP e ASP.NET. Começaram a surgir
grandes demandas de aquisição de servidores devido a essa migração de
processamento do desktop para os servidores. Nessa época as empresas além de
terem soluções próprias, compravam soluções WEB e as disponibilizavam em seus
próprios data­centers, com acesso restrito a intranet.
Novas soluções tecnológicas alteram o cenário constantemente, onde nos
últimos anos começou a intensificar­se a migração computacional para ambiente das
nuvens. Um dos impulsos dessa migração é para resolver problemas de custos
referentes a disponibilização de serviços, afinal de contas não é mais necessário
comprar estruturas de data­centers, muito menos gastar com licenças de vários
softwares, basta pagar horas de aluguel de máquinas virtualizadas nas nuvens. Através
dessa tendência as empresas de soluções de software passaram a oferecer também a
hospedagem, deixaram de conceder apenas uma licença de uso e passaram vender
um serviço como um todo, através de assinatura mensal, bastando ao cliente apenas
possuir acesso a internet.
Em momentos de crise financeira, necessidade na rapidez de entregas e
resultados de soluções tecnológicas questiona­se: Qual dos ambientes, em nuvem ou
tradicional, pode contribuir para reduzir custos? Qual destes fornece mais flexibilidade
para escalar aplicações? Onde os riscos serão mais fáceis de ser minimizados e
gerenciados?

3.
O objetivo desse trabalho é apresentar recursos em nuvem que contribuam para:
facilitar a escalabilidade, reduzir custos, minimizar riscos de falhas e segurança e
facilitem a contingência e redundância.
2. DESENVOLVIMENTO
Esse tópico está subdividido nas seguintes partes: Primeiramente uma breve
motivação sobre o contexto computacional tradicional e tendências de mercado. Na
sequencia é apresentado uma revisão bibliográfica sobre computação nas nuvens,
Load balancing e Auto Scaling. Em um terceiro momento é apresentado os desafios
arquiteturais como escalabilidade, desempenho, riscos e custos. Por último é
apresentado um estudo de caso analisando cada um destes desafios arquiteturais
inseridos nos ambientes de nuvem e no modelo tradicional.
2.1 Motivação
Atualmente está ocorrendo um processo de migração de um modelo com
grandes datacenters tradicionais, ​in home​, para ambientes virtuais alugados nos quais
são fornecidos por grandes empresas. A maioria das startups já iniciam em ambientes
virtualizados, por não terem condições financeiras de montar um datacenter, e também
pela agilidade em criar ambientes virtualizados. As grandes empresas também estão
migrando, porém com passos mais cautelosos, inicialmente com serviços de menor
criticidade até criarem mais confiança.
Tanto para as empresas que estão iniciando quanto para as mais antigas,
reduzir os custos nesses ambientes em nuvem se tornará importante, a startup reduzirá
custos em sua fase inicial o que é muito importante e determinante para sua efetivação
no mercado. Já para a empresa mais sólida no mercado ganhará mais confiança no

4.
ambiente nesse tipo de solução, onde possivelmente migrará o maior número de
serviços.
Migrar toda a plataforma de serviços para a nuvem é uma tendência que cresce
consideravelmente. De acordo com MINES (2011), uma pesquisa realizada pela
Forrester concluiu que os gastos mundiais com ​Cloud Computing passarão de $ 25
bilhões em 2011 para $ 160 bilhões em 2020, um crescimento anual de 22%. Quanto
mais empresas utilizarem os ambientes baseados em nuvem maior será a contribuição
para o meio ambiente. As empresas fornecedoras de nuvem possuem uma otimização
muito maior na utilização de energia do que um ​datacenter ​in home​, além de utilizarem
energias alternativas que poluem menos.
2.2 Computação nas Nuvens
O termo Computação nas Nuvens é muito amplo e está sendo usado de forma
excessiva em tudo que abrange a área de informática. Conforme SANTOS et al (2015),
computação nas nuvens surgiu da necessidade de se compartilhar ferramentas
computacionais pela interligação de sistemas, utilizando­se da internet como principal
meio de comunicação, em aspecto semelhante as nuvens do céu. Ou seja, a
computação nas nuvens é uma nova forma de disponibilizar e organizar estruturas de
serviços utlizando­se a internet como base. De acordo com SOUSA et al (2009), cada
parte da infra­estrutura da Internet é provida como um serviço, e estes serviços
normalmente são alocados em data­centers, utilizando hardware compartilhado para
estrutura e armazenamento.
Considerando que conceito de computação nas nuvens é algo muito abrangente
devido ao uso demasiado dessa nomenclatura é importante entender o seu real
propósito. Uma dos benefícios da nuvem é possibilitar o corte de custos operacionais e,
o mais importante, permitir que departamentos de TI se concentrem em projetos
estratégicos em vez de manter o data­center funcionando (VELTE et al., 2012).

5.
Empresas grandes como Amazon, Google e Microsoft mantém datacenters de
grande porte localizados em vários lugares do mundo para virtualização de servidores.
Os consumidores destes serviços podem gerenciar seus ativos através de páginas web
e acesso via protocolos de seguranças já conhecidos como SSH (​Secure Shell​). Umas
das grandes vantagens desse novo modelo é a facilidade de escalabilidade, com
apenas alguns cliques e configurações novas máquinas estarão disponíveis para serem
utilizadas através da nuvem.
Sendo perceptível a grande evolução e grande redução de custos do modelo
tradicional para o modelo novo, o novo modelo propõe um pagamento conforme
demanda, ou seja, o valor cobrado será baseado no número de horas em que estas
máquinas ficarão conectadas, além é claro de recursos de armazenamento, frequencia
de leitura e escrita realizados durante esse tempo.
Quanto a estrutura da nuvem, existem diversos recursos para resolver cada tipo
de problema. Este trabalho apresenta dois recursos que visam evitar a ociosidade de
máquinas: ​Load balancing​ e ​Auto Scaling​.
2.2.1 Load Balancing
Load Balancing​, ou então balanceador de carga, é um recurso bem antigo que
foi bastante utilizado em ambientes tradicionais (​in home​), conforme VISWANATHAN
(2001), trata­se de um conceito de servidores em ​cluster (​Figura 1​), onde existe um
servidor virtual que recebe todas as requisições e distribui entre os nós desse ​cluster
com o objetivo de otimizar o desempenho do sistema. Hoje este recurso já está
disponível em diversos serviços de virtualização de servidores, como Amazon e
Microsoft, além da possibilidade de fazer download ou adquirir softwares que façam
essa tarefa através de configuração própria.

6.
Figura 1​: Papel do Load Balancer
Fonte​ : MACVITTIE (2009)
Mesmo com essa otimização de desempenho, várias dessas máquinas no
cluster ficam ociosas gerando custos da mesma maneira que máquinas que estão
sendo usadas efetivamente. Para entender o problema considere a ​Figura 2 abaixo:
Um determinado e­commerce possui épocas de alta demanda, precisamente próximo a
datas festivas como: final de ano, Páscoa, dia das mães, dia dos pais e dias das
crianças. Cada uma destas datas possui mais ou menos demanda que as outras.

7.
Figura 2​: Baixa e alta demanda de um e­commerce
Fonte: ​Elaborado pelo próprio autor
Supondo que no auge de acessos sejam necessários 10 (dez) instâncias de
servidores e no mais baixo apenas 2 (duas) máquinas, se as 10 máquinas estiverem
ligadas todo o tempo vai gerar um custo necessário. O Load Balancing resolve esse
problema, quando chegar próximo destes períodos basta ligar mais máquinas para
atender a demanda necessária, e quando houver redução desliga­se a quantidade de
máquinas excedentes.
Saber quantas máquinas serão necessárias não é tão simples assim. Existem
diversas variáveis que devem ser consideradas: Quantidade de usuários simultâneos,
tempo médio de processamento por requisição e capacidade processamento de
requisições de cada instância. Determinar a capacidade de cada instância não é fácil, é
preciso considerar: tecnologias de servidor de aplicação, configurações de hardware
(memória, processador, cache, etc), acesso a outros recursos, etc. A melhor maneira de
descobrir essa capacidade é executar testes de carga e estresse, que nada mais é que
uma simulação do ambiente de produção.

8.
2.2.2 Auto Scaling
O Load Balancer por si só resolve muitos problemas de custos, porém a Amazon
AWS fornece um recurso complementar, o ​Auto Scaling​. Conforme AMAZON (2015),
trata­se de um recurso que permite aumentar ou reduzir a capacidade de serviços de
forma automática, garantindo a execução da quantidade desejada de servidores. Sua
utilização ideal é para casos onde há variações horárias de acesso.
Utilizando o mesmo exemplo do Load Balancer (​Figura 2​), o Auto Scaling entra
como um adicional muito importante, cabe a ele decidir através de configurações
quando adicionar uma máquina quando ocorrer aumento de usuários ou remover uma
máquina ociosa quando os acessos diminuirem. Isso evita muitos transtornos, pois ele
tem maior precisão de quantas máquinas são necessárias, além de do fato que a
criação e configuração de uma nova máquina é muito mais rápida do que feita
manualmente.
No console (ambiente administrativo) da Amazon AWS é possível criar um
auto­scaling. A ​Figura 3 mostra o inicio do processo de criação do Auto­scaling. Nessa
primeira parte informa­se o nome do grupo, o número de instâncias iniciais e uma
sub­rede.
Figura 3​: Criação de Auto Scaling ­ Parâmetros iniciais
Fonte: ​Elaborado pelo próprio autor

9.
A ​Figura 5 apresenta o início da segunda parte da configuração. Nessa parte
configura­se a escala que o Auto­scaling vai trabalhar, basicamente conforme a
ilustrado na figura será entre 2 e 10 instâncias.
Figura 4​: Parâmetros de escalabilidade ­ Intervalo de escala.
Fonte: ​Elaborado pelo próprio autor
As ​Figuras 5 e 6 ​apresentam as configurações de incremento e decremento de
instâncias respectivamente. As configurações são exatamente iguais, apenas mudando
a ação resultante. A ideia é que de acordo com determinada ​policy uma determinada
ação de adicionar ou remover é executada. A fins de exemplificação, no caso do
incremento quando a média de CPU de todas as instâncias atingir 80% deverá ser
incrementado uma nova instância. No caso do decremento quando a média das
máquinas for menor de 40% pode se remover 1 instância.
Figura 5​: Configuração de incremento de escalabilidade
Fonte: ​Elaborado pelo próprio autor

10.
Figura 6​: Configuração de decremento de instâncias
Fonte: ​Elaborado pelo próprio autor
2.3 Desafios Arquitetuturais
Esse tópico aborda sobre os desafios que devem ser lidados pelo arquiteto de
software, questões que vão desde o planejamento e projeção do sistema até o
gerenciamento em ambiente de produção. São abordadas questões como:
escalabilidade, desempenho, riscos, contingência, redundância e custos.
2.3.1 Escalabilidade flexível e Desempenho
Considerando um sistema onde o número de usuários aumenta e diminui de
forma expressiva, ou apenas aumenta sem retroceder, a flexibilidade para esticar a
capacidade de processamento deverá ser considerada pelo arquiteto de software. Será
necessário uma atenção na solução tecnológica a ser adotada bem como as
características do ambiente onde será feito a implantação. Deverá ser possível
adicionar novas máquinas de forma simples, seja de forma manual ou automática.
Conforme SOUSA et al (2009), quando se fala de escalabilidade se diz respeito a

11.
adição e troca de recursos computacionais, devendo ser possível escalar tanto em nível
de recursos de hardware e software para atender as necessidades das empresas.
Outro fato importante a ser considerado á o desempenho, questões de latência
de rede podem comprometer o uso da aplicação dependendo do volume de
informações que é trafegado. Segundo MEDEIROS et al (2014), a latência pode ser
considerada como somatório de atrasos impostos pela rede e equipamentos utilizados
na comunicação, no ponto de vista de aplicação pode ser tratada como tempo de
resposta. Por exemplo banco de dados e servidor de aplicação não deveriam ficar em
máquinas que estejam distantes geograficamente, pois no caminho podem haver
equipamentos falhos e ainda se for uma distância muito grande os atrasos vão ocorrer
mesmo com a existência de qualidade.
2.3.2 Riscos, Contingência e Redundância
Uma aplicação distribuída pode ser tanto distribuída logicamente como
geograficamente, ou seja, pode existir vários serviços instalados na mesma máquina ou
mesmo data­center local, como também podem haver serviços em diversos
data­centers espalhados geograficamente.
Seja qual for a solução adotada muitos são os riscos e preocupações que devem
ser considerados. Esses riscos podem gerar indisponibilidade momentânea de serviços.
Conforme CORRADINE (2014), o tempo inativo afeta a eficiência dos sistemas e seus
rendimentos, o que resulta em perda de produtividade e de clientes, causando impacto
negativo na rentabilidade. Para esse trabalho vale destacar os seguintes riscos:
● Falha de equipamentos: Algo comum, memórias, discos rígidos, placas de
rede e cabeamento, são itens que com o tempo tem seu uso
comprometido e devem ser trocados por novos.

12.
● Questões adversas de tempo: A localização do data­center deve estar
longe e bem protegida de possíveis alagamentos ou até mesmo exposição
solar;
● Segurança Física: O acesso as instalações de um data­center deve ser
muito restrito e bem monitorado;
● Segurança Lógica: Proteção com firewall e anti­vírus devem ser rigorosos.
Esses riscos citados podem ocasionar no rompimento de alguns serviços que
fazem parte de um sistema distribuído. Além destes é claro, outros fatores indiretos a
estes podem ocasionar falhas, como: Sobrecarga de processamento, despejo de
memória, disco rígido cheio e falha no próprio sistema operacional. É necessário um
plano de contingência. A redundância é um recurso que pode ser utilizado. Essa
redundância pode ser tanto de hardware como também física. Conforme AMANTÉA e
NEPOMUCENO (2007), redundância é um método que utiliza dois (ou mais)
componentes idênticos de um sistema para aumentar sua capacidade de realizar suas
operações por um longo período de tempo. Por exemplo, é possível o mesmo serviço
estar hospedado em um data­center em São Paulo e outro no Rio de Janeiro, caso um
venha a falhar o outro passa a ser o efetivo.
A redundância as vezes pode ser de certa forma atendida com a escalabilidade e
com o balanceador de carga. Esses dois podem minimizar os problemas caso
servidores do cluster venham a falhar pois as demais máquinas deste cluster vão
continuar respondendo pelo serviço. No entanto o objetivo inicial da redundância é na
existência de um recurso reserva que seja idêntico ao titular. Como pode ser observado
na ​Figura 7​, quando um data­center inteiro falhar o data­center Reserva assume a
responsabilidade.

13.
Figura 7​: Redundância de DataCenters
Fonte​: Elaborado pelo próprio Autor
2.3.3 Custos
Um sistema distribuído pode ser disponibilizado tanto em data­centers próprios
ou locais, como em vários data­centers em nuvem, independente de local. O ponto a
ser considerado pelo arquiteto será até que tamanho esse sistema irá aumentar. Os
custos estão diretamente ligados aos itens citados anteriormente: Escalabilidade,
desempenho, contingência e riscos. Todos esses itens geram custos que devem ser
considerados.
A questão do custos requer uma atenção maior das empresas, principalmente
em momentos de crise. As empresas devem adotar soluções criativas, buscando
soluções que garantam a redução de custos em vários setores da empresa, a TI é uma
delas. É necessário investir em soluções inteligentes, TREMARIN (2015).

14.
2.4 Metodologia
A metodologia aplicada será basicamente uma análise comparativa. Será feito
uma comparação com base nos itens citados como desafios arquiteturais. Para cada
item será apresentado como este seria aplicado em ambiente datacenter local ou cloud
computing com o objetivo de levantar as vantagens e desvantagens de cada um.
2.5 Estudo de Caso
O estudo de caso está dividido em quatro partes: Escalabilidade, Desempenho,
Riscos e Contingências e por último sobre Custos.
2.5.1 Escalabilidade
Ambiente Data­center​: Escalar em um ambiente data­center não é uma tarefa
fácil. Existe a limitação física. Por mais grande que seja o data­center podem haver
outros serviços sendo alocados em máquinas paralelas. Supondo que haja a
necessidade de escalar um serviço pode haver a necessidade de desligar outros
serviços ou o até mesmo ampliar o datacenter, o que por vezes pode demorar.
Recursos como Load Balancing e Auto Scaling devem ser configurados a parte, o que
requer tempo e conhecimento extra. Mesmo assim ficam limitados a escalabilidade
física. Considerando tudo isso escalar em um data­center próprio não existe
flexibilidade desejada.
Ambiente Cloud Computing​: Considerando­se ambientes cloud computing, os
quais são baseados em ambientes virtuais, aumentar a capacidade de hardware e

15.
adicionar novas máquinas são tarefas instantâneas. Não existe burocracia de
aquisição, os recursos são liberados com alguns cliques através de interfaces web de
gerenciamento. Além do mais na nuvem recursos como Load Balancing e Auto­Scaling
(pelo menos na Amazon AWS) já estão disponíveis para serem usados, sem
necessidade de configuração extra. Sendo assim, dobrar, triplicar, ou qualquer que seja
o tamanho desejável é uma tarefa flexível.
2.5.2 Desempenho
Ambiente Data­center​: Para analisar o desempenho deve ser considerado o
seguinte ponto: Quem são e onde estão os usuários finais? Se a localização física dos
usuários for próximo ao data­center, o desempenho será melhor devido a latência
baixa, ou seja, considerando­se uma arquitetura distribuída que fique toda no
data­center local e os usuários forem locais, o desempenho será melhor. Se houver
algum serviço ou usuário em outro ponto geográfico deverá ser considerado a latência
de todo o trajeto.
Ambiente Cloud Computing​: No caso da cloud computing sempre haverá a
questão da latência no trajeto dos usuários finais até o data­center que foi contratado.
Caso seja adotado cloud deve se tomar muito cuidado, pois na hora de alugar uma
máquina virtual é escolhido a localização do data­center. Por exemplo, a Amazon
possui data­centers em vários lugares do mundo, no Brasil existe um em São Paulo. Se
a maioria dos usuários forem brasileiros deve se considerar escolher o data­center do
Brasil.
No caso do desempenho tanto o data­center local como o cloud computing tem
condições de desempenhos semelhantes. A Cloud tem uma pequena vantagem pelo
fato das fornecedoras possuírem estruturas consideravelmente grandes, o que requer
um cuidado muito maior com a latência por parte deles, pois isso está nas premissas da
qualidade dos serviços prestados.

16.
2.5.3 Riscos, Contingência e Redundância
Ambiente Data­center​: Caso seja adotado o datacenter, os riscos citados:
Falhas de equipamentos, questões adversas de tempo e seguranças física e lógica,
todos serão itens de preocupação a serem considerados pelo responsável e
gerenciador do serviço. Obviamente utilizando a redundância alguns desses problemas
podem ser minimizados garantindo assim a contingência. Falando especificamente da
segurança física, será necessário um esforço extra para diminuir o máximo a
possibilidade de acesso de pessoas não autorizadas.
Ambiente Cloud Computing​: Considerando os riscos: Falhas de equipamentos,
questões adversas de tempo e seguranças física e lógica, todos são de
responsabilidade da empresa fornecedora de cloud computing. Na questão de
redundância e contingência, a empresa fornecedora vai garantir até a falha de
equipamentos naquele local, pois existe a replicação de data­centers em pontos
geográficos diferentes. Sendo assim, o único ponto a ser considerado como
contingência adicional a cloud computing será quando o datacenter e sua réplica
falharem.
Na questão de segurança lógica a empresa fornecedora garante até o acesso ao
sistema operacional dos servidores, que são fornecidos inclusive por ela. Segurança de
serviços instalados nesses servidores serão de responsabilidade da empresa que
contratou a nuvem.
2.5.4 Custos
Esse tópico está divido em duas partes, primeiramente é abordado sobre os
custos de montar um data center na própria organização, e no tópico seguinte é
abordado sobre os custos de computação em nuvem mais populares de mercado. O
Quadro 1​ abaixo apresenta uma comparação prévia sobre os custos, ORACLE (2009).

17.
Quadro 1​ ­ Custos de nuvem versus servidor tradicional
EC2 Amazon (nuvem) Custos do servidor empresarial
tradicional
Capacidade de computação 0,10/hora +
armazenamento 0,15/GB = US$ 70 a
US$ 150/mês (utilização total)
Aprox. US$ 400/mês
Fonte​: Oracle (2009)
2.5.4.1 Custo de datacenter local
Montar um datacenter local requer uma série de preocupações, vários detalhes e
itens que precisam ser adquiridos ou serviços contratados, segue alguns: Links
dedicados de internet, rack para servidores, salas refrigeradas, sistema anti­incêndio,
gerador de energia elétrica, cabeamento e vários outros itens como serviços de
instalação e manutenção. O ​Quadro 2 contém preços e custos de alguns itens para
data­center mais simples.
Quadro 2​ ­ Preços de data­center local
Descrição Valor
Link dedicado de Internet 1
Aprox. R$ 100 / Mb
Servidor Dell Power Edge R720 para até 10 máquinas virtuais 2
Aprox. R$ 15k
Rack para servidor 3
Aprox. R$ 1.400
Fonte​: Elaborado pelo próprio autor
1
GVTLink. Disponível em: <​http://www.gvtlink.com.br​>. Acesso em 11 de Maio de 2015.
2
SystechTecnologia. Disponível em: <​http://systechtecnologia.com.br/​>. Acesso em 11 de Maio de 2015.
3
Brasutil. Disponível em: <​http://www.brasutil.com/​>. Acesso em 11 de Maio de 2015.

18.
É importante salientar que os valores informados no ​Quadro 2 são aproximados
pois podem variar de fornecedor para fornecedor além de cidade para cidade.
Para o ambiente ​in home deve ser considerado a vida útil de cada equipamento,
conforme CLEMENT et al (2012), servidores tem aproximadamente de 3 a 5 anos,
componentes de rede de 5 a 7 anos e toda a estrutura como um todo de 10 a 15 anos.
Considerando esse ponto, deverá haver uma preocupação constante em como
descartar corretamente esses equipamentos para não afetar o meio ambiente, o que
gera um custo adicional.
2.5.4.2 Custos Virtualização da Amazon AWS
Ao contrário do datacenter local, contratar serviços na nuvem não requer
preocupação adicionais como: rack, sistema anti­incendio, link dedicado de internet e
os demais itens citados no item anterior. Toda essa responsabilidade pertence a
empresa que oferece a virtualização, que possuem estruturas de datacenters grandes o
suficiente para atender uma alta demanda de muitos clientes, além possuir replicação
no caso de falhas.
A Amazon AWS é um dos dos principais provedores de serviços de virtualização
do mercado. Qualquer pessoa física ou jurídica pode abrir uma conta e configurar seus
servidores através de uma interface Web e terminal de linha de comando com SSH.
A precificação da Amazon é baseada sob demanda, ou seja, será cobrado
somente a quantidade de horas de cada serviço utilizado. O ​Quadro 3 abaixo contém
os serviços e seus respectivos valores:

19.
Quadro 3​ ­ Custos de Virtualização com Amazon AWS
Descrição Valor
Máquina Virtual (EC2) AT2 Medium ( 2
vCPU, 3,75 Gb RAM)
$0.108 por hora
Máquina Virtual (EC2) T2 Small (1 vCPU,
2 Gb RAM)
$0.054 por hora
Load Balancer $0.025 por Elastic Load Balancer por
hora
Fonte:​ Amazon AWS ­ Adequado pelo autor
Em outro cenário foi comparado os custos de computação em nuvem versus
custos da estrutura tradicional conforme o ​Gráfico 1​. O estudo demonstra que em um
período de 8 anos os custos de SaaS (​Software as a Service​), que é um dos modos de
utilização de cloud computing, ficaram abaixo dos custos de ​On­Premise (sinonimo de
in­house​, ou seja, estrutura tradicional), WLODARZ (2013).
Gráfico 1​ ­ Comparação de custos Saas vs On Premise
Fonte​: WLODARZ (2013)

20.
3. RESULTADOS
De acordo com o estado de caso onde foram realizadas comparações entre as
duas tecnologias é possível considerar os seguintes resultados:
● Escalabilidade​: A cloud computing é muito mais flexível e prática para
aumentar a capacidade de processamento de um sistema, de forma muito
mais rápida.
● Desempenho​: Nesse ponto os dois tem condições iguais de atingir as
metas de tempo de resposta em requisições feitas pelos usuários. Tudo
vai depender do cenário e questões geográficas como localização dos
datacenters e dos usuários.
● Riscos e Contingência​: O ambiente data­center próprio vai exigir uma
preocupação muito maior com hardware e segurança. Com a cloud
também devem haver esses cuidados, mas boa parte dessa segurança já
está embutida na contratação do serviço de hospedagem.
● Custos​: Outro ponto vantajoso para a Cloud Computing, uma vez que não
existe o custo de configuração inicial e gerenciamento físico de hardware
como acontece no ambiente ​in home​. Na cloud computing esse custo é
distribuído conforme o uso, o que provê uma flexibilidade maior para
gerenciamento deste.
4. CONCLUSÃO
Com a demanda crescente de usuários na internet a computação nas nuvens
torna­se indispensável, com isso é necessário uma atenção maior na organização da
infra­estrutura e arquitetura de serviços. Por meio deste trabalho foi possível afirmar

21.
que a computação nas nuvens traz muitos benefícios para o dia a dia. Os principais são
em relação aos custos, desempenho e de alta disponibilidade. Questões de risco
também são minimizadas pois são de responsabilidade dos fornecedores de nuvem. A
nuvem traz para melhorias de desenvolvimento, como uma otimização de código, que
pode contribuir ainda mais para diminuir o custo.
A computação nas nuvens é uma tendência, conforme NASCIMENTO (2015), no
futuro as pessoas não vão mais precisar instalar softwares, tudo irá girar em torno da
internet, que será uma plataforma completa de aplicações. Isso é facilmente percebível,
tanto que o serviço de maior consumo e navegação de dados da internet da América do
Norte hoje é o Netflix, sendo uns dos principais clientes da Amazon AWS. O artigo
apresentou que a nuvem não é apenas para grandes empresas, mas também para
pequenas e médias. Os grandes diferenciais serão o nível de conhecimento e a
confiança para utilizar as técnicas e recursos apresentados. Através destes diferenciais
será possível diminuir os custos de recursos nas nuvens. Em momentos de crise as
empresas que reduzirem custos serão mais competitivas.
5. REFERÊNCIAS BIBLIOGRÁFICAS
AMANTÉA, Guilherme C. NEPOMUCENO, Guilherme. Estudo e implementação de
redundância dos serviços na rede do IME. Disponível em
<​http://bcc.ime.usp.br/principal/tccs/2007/melao­piercio/monografia.pdf >. Acesso em:
21 Jan 2015.
AMAZON. Auto Scaling. Disponível em: <​http://aws.amazon.com/pt/autoscaling/​>.
Acesso em: 28 mar. 2015.
CLEMENT, Simon, et al. Disponível em
<​http://www.efficient­datacenter.eu/fileadmin/docs/dam/procurement_guidelines/prime_it
_equipment_leaflet_PT.pdf​>. Acesso em: 29 de Mar. 2015.
CORRADINE, Neil. Gestão de risco é assunto chave em infraestrutura física unificada.
Disponível em

22.
<​http://www.datacenterdynamics.com.br/focus/archive/2014/01/artigo­gest%C3%A3o­de
­risco­%C3%A9­assunto­chave­em­infraestrutura­f%C3%ADsica­unificada​>. Acesso em
21 jun 2015.
MACVITTIE, Don. Intro to Load Balancing for Developers ­ How they work. Disponível
em:
<​https://devcentral.f5.com/articles/intro­to­load­balancing­for­developers­ndash­how­the
y­work​>. Acesso em: 22 fev. 2015.
MEDEIROS, R. M. et al. Uma análise de desempenho da rede metropolitana de
telemedicina dos hospitais universitários da cidade de Natal­RN/Brasil. Disponível em:
<​www2.ifrn.edu.br/ojs/index.php/HOLOS/article/download/987/pdf_60​>. Acesso em: 21
Jan 2015.
MINES, Cristopher. 4 Reasons Why Cloud Computing is also a Green Solution.
Disponível em:
<​http://www.greenbiz.com/blog/2011/07/27/4­reasons­why­cloud­computing­also­green­
solution​>. Acesso em: 28 mar. 2015.
NASCIMENTO, Adriana M. R. do. Computação em Nuvem ­ A internet do Futuro.
Disponível em:
<​http://www.nead.fgf.edu.br/novo/material/Computacao_em_Nuvem_A_Internet_do_Fut
uro/Computacao_em_Nuvem_A_Internet_do_Futuro.pdf​>. Acesso em: 09 de Maio de
2015.
ORACLE. A Abordagem de grade de aplicações a um data center moderno. Disponível
em:
<​http://www.oracle.com/technetwork/pt/middleware/fusion­middleware/documentation/gr
idapproach­middleware­2286606­ptb.pdf​> Acesso em: 21 jun 2015.
SOUSA, Flávio R. C. et al. Computação em Nuvem: Conceitos, Tecnologias, Aplicações
e Desafios. Disponível em:
<​http://www.ufpi.br/subsiteFiles/ercemapi/arquivos/files/minicurso/mc7.pdf​>. Acesso em:
21 Jun 2015.
TREMARIN, Nei. Investir para reduzir custos: A saída para um 2015 melhor. Disponível
em:

23.
<​http://convergecom.com.br/tiinside/webinside/03/04/2015/investir­para­reduzir­custos­a
­saida­para­um­2015­melhor/#.VYcCP­dUNXt​>. Acesso em: 21 jun 2015.
VELTE, Anthony T; VELTE, Toby J; ELSENPETER, Robert. Computação em Nuvem.
2ed. Rio de Janeiro: Alta Books, 2012.
WLODARZ, Derrick. Comparing Cloud vs On­premise? Six hidden costs people always
forget about. Disponível em:
<​http://betanews.com/2013/11/04/comparing­cloud­vs­on­premise­six­hidden­costs­peo
ple­always­forget­about/​>. Acesso em: 26 jun. 2015.