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

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?

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

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 datacenterin 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).

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.

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.

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.

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

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

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

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.

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.

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).

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

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.

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).

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.

É 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:

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)

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

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

<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­they­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_Futuro/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/gridapproach­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:

<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­people­always­forget­about/>. Acesso em: 26 jun. 2015.