trabalho de conclusão de curso de graduação
DESCRIPTION
TCC que propiciou a conclusão da graduação em Ciência da Computação.TRANSCRIPT
UNIVERSIDADE REGIONAL INTEGRADA DO ALTO URUGUAI E DAS MISSÕES
CAMPUS DE ERECHIM
DEPARTAMENTO DE ENGENHARIAS E CIÊNCIA DA COMPUTAÇÃO
CURSO DE CIÊNCIA DA COMPUTAÇÃO
DANIEL FERNANDO PIGATTO
ESTUDO E IMPLEMENTAÇÃO DE UMA SOLUAÇÃO DE SOFTWARES
APLICATIVOS UTILIZANDO COMPUTAÇÃO NAS NUVENS
ERECHIM
2009
DANIEL FERNANDO PIGATTO
ESTUDO E IMPLEMENTAÇÃO DE UMA SOLUAÇÃO DE SOFTWARES
APLICATIVOS UTILIZANDO COMPUTAÇÃO NAS NUVENS
Trabalho de Conclusão de Curso,
apresentado ao Curso de Ciência da
Computação, Departamento de
Engenharias e Ciência da Computação da
Universidade Regional Integrada do Alto
Uruguai e das Missões – Campus de
Erechim.
Prof. Orientador: Alexandro Magno dos
Santos Adário
ERECHIM
2009
AGRADECIMENTOS
Aos meus pais, Agenor e Dinora, pela dedicação e carinho que sempre tiveram
comigo, seja em questões de formação de caráter, como no incentivo aos estudos e à
graduação. E a minha irmã, Fernanda, que da mesma forma prestou seu apoio e parceria
comigo em todos os projetos que decidi participar, especialmente no presente.
Aos familiares, especialmente a minha tia Dinaura e meus avós Augusto e Zenaide,
por entenderem minhas faltas aos encontros de família e pelo carinho que sempre me foi
dedicado.
Aos mestres, que além de desempenhar com mérito seus papéis de educadores,
mostraram-se profissionais apoiadores e amigos em todas as etapas concluídas. Especial
agradecimento ao Prof. Alexandro Adário, meu orientador neste trabalho, pela preparação e
apoio dedicados, desde a mais simples dúvida sanada até o mais complexo problema
resolvido.
Aos colegas de graduação, especialmente aos mais presentes, João Paulo, Saulo,
Jonas, Rodrigo, Joel, Maurício, Mateus, Elias, Lucas, Luis, Julior, entre muitos outros, os
quais não só foram colegas, mas verdadeiros amigos, especialmente pelo apoio em momentos
de tensão, pelo respeito demonstrado e pela parceria em todas as situações vivenciadas.
Aos amigos de curta e longa data e aos colegas de trabalho, os quais souberam
entender algumas ausências em importantes eventos ou quando da indisponibilidade em
comparecer a um programa diferente de lazer.
Ao Google, porque sem ele grande parte deste trabalho de pesquisa não teria sido
possível ou não teria sido tão eficiente.
"Perfection is achieved, not when there is nothing more to add,
but when there is nothing left to take away."
Antoine de Saint-Exupery
RESUMO
A era da computação baseada na Web e o recente conceito de virtualização desencadearam no surgimento de uma nova abordagem para minimizar custos com infraestrutura de tecnologia da informação em ambientes corporativos: a cloud computing ou “computação nas nuvens”. Trata-se de um “aluguel” de servidores de terceiros para armazenagem de dados e execução remota de aplicações. Este trabalho mostra as vantagens da computação nas nuvens para empresas de pequeno, médio e grande porte, incluindo comparações de desempenho e relação custo-benefício entre o modelo tradicional e esta nova abordagem. São demonstradas algumas ferramentas do mercado, apurando seus respectivos resultados e implementando um ambiente com a união das melhores, tendo por finalidade proporcionar uma solução de baixo custo, escalável – com possibilidade de crescimento – e com excelente grau de colaboração online. O trabalho também busca um ambiente altamente disponível e com alto grau de abstração a fim de minimizar o impacto para o usuário final.
Palavras-chave: cloud computing. computação nas nuvens. alta disponibilidade. ambiente corporativo. sistemas distribuídos.
ABSTRACT
The computing era based on web and the recent concept of virtualization initiated the emergence of a new approach to minimize the costs with infrastructure of technology information in corporative environments: the cloud computing. It deals of the renting of third-party servers for data storage and remote execution of applications. This study shows the advantages of cloud computing for companies of small, medium and big size, including comparisons of performance and cost-benefit relation between the traditional model and this new approach. Some market tool are demonstrated, checking their respective results and implementing an environment with the union of the best, aiming at providing a solution of low cost, scalable – with possibility of growth – and an excellent degree of on line collaboration. This study also searches for an environment highly available and with a great degree of abstraction intending to minimize the impact for the final user.
Keywords: cloud computing. high availability. corporative environment. distributed systems.
LISTA DE FIGURASFigura 1 - Diferenças entre as camadas dos protocolos ISO/OSI e TCP/IP.............................22
Figura 2 - Organização do cluster Beowulf...............................................................................27
Figura 3 - Organização virtual provida pela computação em grade.........................................28
Figura 4 - Níveis de divisão da computação nas nuvens segundo a ontologia proposta..........37
Figura 5 - Aplicativos de computação nas nuvens divididos em grupos de usuários...............43
Figura 6 - Organização do VMware vSphere, o primeiro sistema operacional em nuvem do mercado.....................................................................................................................................49
Figura 7 - Login de usuário no modo de simulação local do Google App Engine...................59
Figura 8 - Tela de criação de nova aplicação no Google App Engine......................................60
Figura 9 - Tela de Login do aplicativo-exemplo para Google App Engine...............................61
Figura 10 - Tela do Painel do Usuário do aplicativo-exemplo para Google App Engine.........62
Figura 11 - Exemplo de e-mail enviado através do aplicativo-exemplo...................................63
Figura 12 - Volume de buscas no Google para os termos Google Docs, Microsoft Office e OpenOffice................................................................................................................................65
Figura 13 - Variação no tempo de upload de documentos de texto..........................................67
Figura 14 - Variação no tempo de carregamento de documentos de texto................................67
Figura 15 - Variação no tempo de impressão de documentos de texto.....................................68
Figura 16 - Variação no tempo de upload de planilhas de cálculo............................................69
Figura 17 - Variação no tempo de carregamento de planilhas de cálculo.................................69
Figura 18 - Variação no tempo de impressão de planilhas de cálculo......................................70
Figura 19 - Variação no tempo de tarefas sobre apresentações de slides..................................71
Figura 20 - Variação no tempo de upload de uma imagem para o Google Docs......................72
Figura 21 - Tempo de upload e conversão de arquivos de texto com o mesmo conteúdo........73
Figura 22 - Área de trabalho e barra de inicialização rápida com atalhos de aplicativos remotos apresentados de forma semelhante a aplicativos desktop tradicionais........................77
Figura 23 - Menu Iniciar com atalhos de aplicativos remotos apresentados de forma semelhante a aplicativos desktop tradicionais...........................................................................78
Figura 24 - Google Contacts apresentado de maneira semelhante a um aplicativo desktop.....79
Figura 25 - Google Docs apresentado de maneira semelhante a um aplicativo desktop..........79
Figura 26 - Zoho Projects apresentado de maneira semelhante a um aplicativo desktop.........80
Figura 27 - Gmail apresentado de maneira semelhante a um aplicativo desktop.....................80
Figura 28 - LinkedIn apresentado de maneira semelhante a um aplicativo desktop.................81
Figura 29 - Google Calendar apresentado de maneira semelhante a um aplicativo desktop....81
Figura 30 - To Do List apresentado de maneira semelhante a um aplicativo desktop..............82
Figura 31 - Zoho Chat apresentado de maneira semelhante a um aplicativo desktop..............82
LISTA DE TABELAS
Tabela 1 - Comparativo entre TI Interno e Serviços Terceirizados...........................................39
Tabela 2 - Comparativo entre Serviços Terceirizados e Computação nas Nuvens...................40
Tabela 3 - Características dos arquivos utilizados para os testes..............................................66
Tabela 4 - Compatibilidade entre elementos das suítes............................................................74
LISTA DE ABREVIATURAS E SIGLAS
API – Application Programming Interface
CaaS – Communication as a Service
CAN – Campus Area Network
CDN – Content Delivery Network
CGI – Common Gateway Interface
CSS – Cascading Style Sheet
DaaS – Data-Storage as a Service
DOC – Extensão padrão do Microsoft Word 2003
DOCX – Extensão padrão do Microsoft Word 2007
EC2 – Elastic Compute Cloud
Eucalyptus – Elastic Utility Computing Architecture Linking Your Programs To Useful
Systems
FTP – File Transfer Protocol
GFS – Google File System
HaaS – Hardware as a Service
HTML – HyperText Markup Language
IaaS – Infrastructure as a Service
IDL – Interface Definition Language
IP – Internet Protocol
JPEG – Joint Photographic Experts Group
KB – Kilobyte
Kbps – Kilobit por segundo
LAN – Local Area Network
MAN – Metropolitan Area Network
MB – Megabyte
Mbps – Megabit por segundo
ODP – Open Document Presentation
ODS – Open Document Spreadsheet
ODT – Open Document Text
PaaS – Platform as a Service
PAN – Personal Area Network
PC – Personal Computer
PDA – Personal Digital Assistants
PDF – Portable Document Format
PPT – Extensão padrão do Microsoft PowerPoint 2003
PPTX – Extensão padrão do Microsoft PowerPoint 2007
QoS – Quality of Service
RAM – Random Access Memory
REST – Representational State Transfer
s – segundos
S3 – Simple Storage Service
SaaS – Software as a Service
SAN – Storage Area Network
SDK – Software Development Kit
SMS – Short Message Service
SMTP – Simple Mail Transfer Protocol
SO – Sistema Operacional
SOA – Service-Oriented Architecture
SOAP – Simple Object Access Protocol
SP3 – Service Pack 3
TCP – Transmission Control Protocol
TCP/IP – Transmission Control Protocol / Internet Protocol
TI – Tecnologia da Informação
URL – Uniform Resource Locator
VPC – Virtual Private Cloud
VPN – Virtual Private Network
WAN – Wide Area Network
WSGI – Web Server Gateway Interface
XLS – Extensão padrão do Microsoft Excel 2003
XLSX – Extensão padrão do Microsoft Excel 2007
XML – eXtensible Markup Language
SUMÁRIO
1 INTRODUÇÃO....................................................................................................................13
2 SISTEMAS DISTRIBUÍDOS.............................................................................................152.1 METAS...............................................................................................................................162.1.1 Acesso a recursos............................................................................................................162.1.2 Transparência da distribuição......................................................................................172.1.3 Abertura..........................................................................................................................182.2 REDES DE INTERCONEXÃO.........................................................................................192.2.1 Organização das Redes..................................................................................................202.2.2 Tipos de Redes................................................................................................................202.2.3 Protocolos de Rede.........................................................................................................212.2.3.1 Modelo de referência OSI.............................................................................................222.2.3.2 Protocolo TCP/IP..........................................................................................................232.2.4 Segurança em Redes......................................................................................................242.3 ESCALABILIDADE..........................................................................................................252.4 SISTEMAS DE COMPUTAÇÃO DISTRIBUÍDOS..........................................................26
3 COMPUTAÇÃO NAS NUVENS........................................................................................303.1 CONCEITUAÇÃO.............................................................................................................303.2 CARACTERÍSTICAS........................................................................................................313.3 MODELOS DE SERVIÇO.................................................................................................323.3.1 Nível de Aplicação..........................................................................................................333.3.2 Nível de Ambiente de Software.....................................................................................333.3.3 Nível de Infraestrutura de Software.............................................................................343.3.4 Nível de Kernel de Software..........................................................................................363.3.5 Nível de Hardware e Firmware.....................................................................................373.4 ECONOMIA.......................................................................................................................383.5 APLICAÇÕES E PÚBLICO-ALVO...................................................................................403.5.1 Usuários Domésticos......................................................................................................413.5.2 Comunidades e Grupos.................................................................................................423.5.3 Corporações....................................................................................................................42
4 PROVEDORES DE SERVIÇOS EM NUVEM................................................................444.1 AMAZON WEB SERVICES..............................................................................................444.1.1 Amazon Elastic Compute Cloud (Amazon EC2)........................................................444.1.2 Amazon SimpleDB.........................................................................................................454.1.3 Amazon Simple Storage Service (Amazon S3)............................................................454.1.4 Amazon CloudFront.......................................................................................................454.1.5 Amazon Elastic MapReduce.........................................................................................464.1.6 Amazon Virtual Private Cloud (Amazon VPC)...........................................................464.2 SUN.....................................................................................................................................464.3 IBM.....................................................................................................................................474.4 EUCALYPTUS...................................................................................................................48
4.5 VMWARE...........................................................................................................................484.5.1 VMware vCloud.............................................................................................................484.5.2 VMware vSphere............................................................................................................494.6 MICROSOFT......................................................................................................................504.7 GOOGLE............................................................................................................................50
5 ESTUDOS DE CASO..........................................................................................................515.1 ESTUDO DE CASO 1: FRAMEWORK GOOGLE APP ENGINE....................................515.1.1 Conjunto de APIs...........................................................................................................525.1.2 Limitações.......................................................................................................................545.1.3 Vantagens........................................................................................................................545.1.4 Desvantagens..................................................................................................................555.1.5 Tutorial de Desenvolvimento de Aplicativo-exemplo..................................................555.1.5.1 Preparação do ambiente de desenvolvimento...............................................................565.1.5.2 Criando um novo projeto..............................................................................................565.1.5.3 Testando o projeto.........................................................................................................585.1.5.4 Efetuando upload do projeto.........................................................................................605.1.6 Avaliação dos Resultados...............................................................................................635.2 ESTUDO DE CASO 2: PLATAFORMA GOOGLE DOCS...............................................645.2.1 Testes de Desempenho em Relação à Velocidade de Acesso.......................................655.2.2 Testes de Compatibilidade.............................................................................................735.2.3 Avaliação dos Resultados...............................................................................................74
6 SOLUÇÃO EM NUVEM PARA AMBIENTES CORPORATIVOS...............................756.1 PROPOSTA DE AMBIENTE.............................................................................................756.2 SISTEMA TRADICIONAL X SOLUÇÃO EM NUVEM.................................................83
CONCLUSÃO.........................................................................................................................84
REFERÊNCIAS......................................................................................................................87
ANEXOS..................................................................................................................................90ANEXO A – Limitações do Google App Engine......................................................................91ANEXO B – Código-fonte do aplicativo-exemplo para Google App Engine..........................94ANEXO C – Tabela de Dados Coletados nos Testes com Google Docs................................101
1 INTRODUÇÃO
A necessidade de reinvenção é uma característica comum à ciência. Novos modelos e
soluções devem surgir para que a evolução seja possível e de fato alcançada. No meio
corporativo esta premissa é bastante importante, uma vez que inovação é a palavra-chave para
qualquer empreendimento, seja ele atuante no ramo que for. Contudo, a preocupação com o
crescimento não pode ser atrapalhada por fatores que deveriam facilitar as tarefas cotidianas,
como o setor de tecnologia da informação. Ele pode, muitas vezes, representar um “peso” na
estrutura de uma empresa, significando atrasos devido a determinadas deficiências e gastos
adicionais com mão-de-obra e infraestrutura.
Dentro dos sistemas distribuídos, visando a economia no meio corporativo, surgiu o
modelo recente conhecido por computação nas nuvens. A ideia é nova e ainda está
amadurecendo. Consiste no “aluguel” de espaços em servidores de terceiros para hospedagem
de dados e aplicativos da empresa, eliminando a necessidade de manter desenvolvedores e
equipamentos subutilizados dentro das dependências da empresa. O investimento é
consideravelmente menor se comparado ao modelo tradicional e, ainda, elimina a
preocupação com TI, permitindo que a empresa concentre-se apenas no seu ramo de
atividade.
Este trabalho objetiva conceituar o modelo computacional distribuído em questão,
evidenciando vantagens e desvantagens, avaliando o desenvolvimento de um aplicativo para a
infraestrutura, efetuando comparações de serviços disponíveis na Web já adaptados ao modelo
e, por fim, sugerindo uma solução genérica em nuvem. O que motiva a realização deste
estudo é o fator econômico que possui grande evidência, a possibilidade de aumento da vida
útil do hardware e a vantagem de possibilitar à empresa direcionar suas preocupações para o
negócio, não focando tanto no setor de TI. É possível comprovar por meio de testes com
sistemas em nuvem, que o uso do modelo é viável, exigindo uma abordagem ligeiramente
diferentes da tradicional. Os gráficos apresentados demonstram onde é necessário atuar para
obter o desempenho aceitável e o equilíbrio adequado na adoção de um sistema
computacional distribuído em nuvem.
No Capítulo 2, apresenta-se uma caracterização dos sistemas distribuídos,
especificação de metas a serem cumpridas quando da adoção dos mesmos e apresentação dos
14
principais sistemas computacionais distribuídos. Em seguida, no Capítulo 3, o foco passa a ser
o modelo computacional distribuído conhecido por computação nas nuvens, apresentando
vantagens e desvantagens, classificação do modelo em níveis e caracterização das aplicações
e do público-alvo. O Capítulo 4 mostra alguns serviços em nuvem já em uso no mercado e sua
classificação dentro dos níveis previamente abordados. Em seguida, no Capítulo 5, são
apresentados dois estudos de caso para justificar a possibilidade de adoção da computação nas
nuvens como solução de boa relação custo-benefício para ambientes corporativos. O primeiro
deles abordando o desenvolvimento para a plataforma Google App Engine e o segundo
avaliando o desempenho, a compatibilidade e os fatores de migração para o serviço Google
Docs. Para concluir, o Capítulo 6 apresenta uma proposta de ambiente em nuvem, com custo
reduzido e que pode ser aplicada de maneira geral.
2 SISTEMAS DISTRIBUÍDOS
Ao mesmo tempo em que se iniciaram as primeiras interligações de computadores,
surgiu a ideia de distribuir aplicações entre eles de modo a melhor utilizar recursos que
poderiam estar ociosos durante parte do tempo. Com o aprimoramento da velocidade e da
confiabilidade das redes, cada vez mais computadores no mundo tornaram-se interconectados,
dando fim a uma era em que apenas grandes corporações e ambientes acadêmicos eram
detentores de tal estrutura.
Os avanços da era da informação são cada vez mais rápidos e capazes de oferecer
facilidades no dia-a-dia da sociedade moderna. Todos os segmentos de mercado têm migrado
para aplicações Web visando oferecer maior comodidade ao cliente, que pode realizar
transações bancárias, efetuar reservas em hotéis e companhias aéreas, ler notícias ou acessar
documentos oficiais a partir de casa, escritório, dispositivos móveis etc., a qualquer hora do
dia. Tais avanços foram viabilizados pelo notável aumento da facilidade de aquisição de
microcomputadores, uma vez que estes tiveram seu custo reduzido significativamente, e pelo
avanço nas redes de comunicação pelo mundo, as quais popularizaram o acesso à Internet,
especialmente em ambientes domésticos.
Com o aumento do número de computadores e dos serviços disponibilizados na rede
mundial, a preocupação passou a residir no desempenho dos equipamentos utilizados. A
indústria de microprocessadores não conseguiu manter o mesmo ritmo de crescimento no
poder de processamento de seus novos produtos, contudo a demanda por este crescimento
continuava aumentando.
As limitações na capacidade de processamento impõem restrições aos muitos tipos de software, tais como os programas de escritório, de manipulação de imagens, jogos, científicos e servidores utilizados nas organizações. Uma forma de contornar a limitação local de processamento é a utilização de técnicas que possibilitem o processamento distribuído. (DANTAS, 2005, p. 3, 4)
O uso de computação distribuída passou a ganhar espaço em universidades, centros de
16
pesquisas e empresas de tecnologia da informação, sendo vista como uma alternativa viável
ao uso das arquiteturas computacionais centralizadas e suas limitações. “Um sistema
distribuído é um conjunto de computadores independentes que se apresenta aos seus usuários
como um sistema único e coerente”, como define Tanenbaum (2007, p. 1). Devido às
características de aumento exponencial de processamento de tarefas, alta disponibilidade e por
apresentar maior tolerância a falhas é que os sistemas distribuídos passaram a ser
considerados sistemas de alto desempenho ou alta disponibilidade, atendendo a um vasto
mercado de sistemas conhecidos como críticos.
Os sistemas distribuídos são a solução para aqueles ambientes onde há a necessidade
de aumento da capacidade de processamento de informações, compartilhamento de dados e
sem grandes custos. Fica claro que não é recomendado aplicar sistemas distribuídos onde não
há necessidade, baseando-se apenas no fato de que esta abordagem pode trazer boas
vantagens.
2.1 METAS
É necessário ter metas ao decidir pelo uso de sistemas distribuídos e algumas destas
metas, segundo Tanenbaum (2007, p. 2-10), devem ser devidamente cumpridas.
2.1.1 Acesso a recursos
A principal meta desejada com o uso de um sistema distribuído é o compartilhamento
de recursos controlado, tanto para aplicações, quanto para usuários. Há algumas razões para
querer compartilhar recursos, como por exemplo, compartilhando uma impressora na rede ou
o acesso a um supercomputador permite que um número maior de colaboradores usufrua deste
recurso, resultando em um melhor aproveitamento do mesmo com economia financeira.
A colaboração e a troca de informações é um fator muito relevante e cada vez mais
buscado. Um exemplo claro é a Internet com seu crescimento acelerado, que utiliza
protocolos simples para trocas de arquivos, o que possibilitou que grupos dispersos
geograficamente pudessem estabelecer uma forma eficiente de colaboração e edição.
17
2.1.2 Transparência da distribuição
Uma meta importante no uso de sistemas distribuídos é a ocultação da distribuição de
seus processos, isto é, torná-lo transparente de modo que o sistema seja capaz de se apresentar
ao usuário como sendo um único sistema de computador. Existem vários tipos de
transparência:
• Transparência de acesso: oculta as diferenças de representação dos dados e como se
dá o acesso aos recursos, estabelecendo padrões de exibição de arquivos ao usuário e
às aplicações, escondendo as diferenças entre sistemas operacionais e suas variações
quanto à nomeação de arquivos. Além das diferenças entre sistemas operacionais, a
transparência de acesso busca ocultar diferenças entre arquiteturas de máquinas,
devendo oferecer a mesma visão do sistema para qualquer estação de trabalho
existente em uma rede heterogênea.
• Transparência de localização: é responsável pela ocultação da localização física de
um recurso dentro do sistema. A nomeação é a principal forma de obter este tipo de
transparência, onde é possível utilizar uma nomenclatura que não ofereça pistas sobre
a localização do recurso. Um exemplo disso é o uso de URLs, as quais não
especificam qual servidor está exatamente hospedando aquele site.
• Transparência de migração: oculta a mudança física de um recurso, o que não deve
necessariamente alterar a forma de acesso ao mesmo. Ainda utilizando o exemplo das
URLs, fica transparente aos utilizadores se determinado site sempre esteve localizado
no servidor X ou se anteriormente esteve hospedado no servidor Y.
• Transparência de relocação: no momento em que um sistema dá suporte à migração
de recursos em tempo real, ele possui transparência de relocação. É a mesma ideia da
transparência de migração, com o diferencial de que o sistema não necessita ter seu
funcionamento interrompido para efetuar a migração, sendo transparente aos usuários
e aplicações, os quais podem prosseguir com suas atividades.
• Transparência de replicação: consiste no ato de replicar um recurso para aumentar
sua disponibilidade. Por exemplo, um arquivo muito requisitado pode ter uma cópia
criada e a forma de acesso gerenciada para que o caminho permaneça sendo o mesmo.
Para tal, é necessário haver transparência de localização no sistema, a fim de ocultar
fisicamente o recurso replicado.
• Transparência de concorrência: existe quando é possível a dois ou mais usuários ou
18
aplicações possuírem acesso a um mesmo recurso, ao mesmo tempo, sem que estes
percebam a concorrência de acesso. Para um sistema distribuído é muito importante a
colaboração entre as estações de trabalho, sendo primordial tratar a concorrência de
acesso a recursos compartilhados e ocultar este fato da camada de usuário e aplicação.
• Transparência à falha: um sistema distribuído está mais suscetível a falhas, uma vez
que a complexidade da estrutura aumenta com heterogeneidade, acesso concorrente a
recursos, compartilhamento eficiente etc., dificultando, por conseqüência, o
gerenciamento do sistema. A transparência a falhas busca ocultar a ocorrência de
falhas, permitindo que o sistema recupere-se do erro e continue seu funcionamento
normal.
Algumas vezes não é trivial e nem adequado o uso de transparência para ocultar todos
estes detalhes de usuários ou aplicações, uma vez que sistemas geograficamente distribuídos a
longas distâncias, certamente estarão limitados pela velocidade da rede que os conecta e à
capacidade de processamento dos computadores intermediários (TANENBAUM, 2007, p. 4).
As transparências são boas metas de projeto, mas necessitam ser avaliadas juntamente com
outras questões para determinar a viabilidade e a necessidade de implementá-las.
2.1.3 Abertura
Tanenbaum (2007, p. 4) define um sistema distribuído aberto como um “sistema que
oferece serviços de acordo com regras padronizadas que descrevem a sintaxe e a semântica
desses serviços.” Os serviços que em redes de computadores são padronizados por protocolos,
nos sistemas distribuídos são especificados por meio de interfaces, normalmente descritas por
uma linguagem de definição de interface (Interface Definition Language – IDL).
A existência de interfaces permite que, por exemplo, uma aplicação A comunique-se
com uma aplicação B, desde que B disponibilize uma interface padrão de comunicação que é
entendida por A. Uma interface deve ter todas as especificações necessárias para haver uma
comunicação completa, porém isto normalmente inexiste. Para ser completa ela deve
especificar tudo que é necessário para uma implementação, mas normalmente uma interface
não é absolutamente completa, exigindo que o desenvolvedor especifique algumas questões
de implementação.
Com a obtenção de uma interface neutra e completa, duas características importantes
19
para sistemas distribuídos são também obtidas:
Interoperabilidade caracteriza até que ponto duas implementações de sistemas ou componentes de fornecedores diferentes devem coexistir e trabalhar em conjunto, com base na mera confiança mútua nos serviços de cada um, especificados por um padrão comum. Portabilidade caracteriza até que ponto uma aplicação desenvolvida para um sistema distribuído A pode ser executada, sem modificação, em um sistema distribuído B que implementa as mesmas interfaces que A. (TANENBAUM, 2007, p. 5, grifo do autor)
2.2 REDES DE INTERCONEXÃO
A computação é sem dúvida sinônimo de evolução. As principais conquistas
tecnológicas do século XX se deram no campo do processamento e da distribuição de
informações. Entre os principais desenvolvimentos surgiram as redes de telefonia, o rádio, a
televisão, os precedentes da informática e o lançamento de satélites de comunicação. Como
resultado do crescimento acelerado, estas áreas estão convergindo cada vez mais, diminuindo
as diferenças entre coleta, transmissão, armazenamento e processamento de informações.
Hoje é possível comunicar-se em questão de segundos com estações de trabalho
localizadas a milhares de quilômetros de distância geograficamente. E, à medida que evoluem
as maneiras de coleta e tratamento da informação, novos sistemas mais sofisticados devem
surgir.
O velho modelo de um único computador atendendo às necessidades computacionais
de uma organização foi, há muitos anos, substituído pelas redes de computadores, nas quais o
trabalho é distribuído entre todas as estações interconectadas (TANENBAUM, 2003, p. 2).
Shimonski (2005, p. 4) define redes como sistemas que estão interconectados de alguma
maneira e suportam troca de informações entre si. Tanenbaum (2003, p. 2) explica que redes
são um “conjunto de computadores autômatos interconectados por uma única tecnologia.”
Neste capítulo definiremos aspectos a respeito das redes de computadores, citando
fundamentos de sua organização.
20
2.2.1 Organização das Redes
O que define uma rede e a torna diferente das demais são alguns elementos citados
como fundamentais por Shimonski (2005, p. 5, 6):
• Hardware. Inclui os componentes físicos de um computador ou de uma rede, tais
como adaptadores de rede que permitem a troca de informações através dela. Outros
dispositivos que podem ser classificados como hardware são os roteadores, switches e
hubs.
• Mídia. Consiste nos cabos ou tecnologias sem fio, as quais transferem os dados por
toda a rede.
• Protocolos. São espécies de regras que controlam como os dados são enviados entre
os computadores. O protocolo mais popular é o TCP/IP (Transmission Control
Protocol / Internet Protocol).
• Topologia. Define o projeto da rede, como ela é organizada e descreve como os
computadores estão conectados fisicamente.
• Tipo de rede. Define o tamanho da rede e sua escala em uma área geográfica.
• Modelo de rede. Define os níveis de segurança disponíveis e os componentes
necessários para efetuar as conexões.
• Acesso. Determina quem pode utilizar a rede e como será este acesso, além de ditar se
recursos deverão ser públicos ou privados.
• Sistema Operacional de Rede. A rede pode ter um servidor que disponibiliza
serviços para diversos computadores, o qual deverá rodar um sistema operacional de
rede, como Windows ou Linux.
• Outros softwares e dispositivos. Permitirão acesso a recursos como sites internos,
correio eletrônico, bancos de dados etc.
2.2.2 Tipos de Redes
Redes podem conectar estações de trabalho próximas, em um limitado espaço físico,
ou estações a longas distâncias geográficas. Podem ainda ser consideradas redes criadas para
algumas finalidades específicas. Para identificar as redes de computadores quanto a sua
21
abrangência física, foram convencionadas algumas nomenclaturas:
• Rede Local (LAN – Local Area Network). São redes privadas contidas em um único
edifício ou campus universitário com até alguns quilômetros de extensão. Elas têm
tamanho limitado, o que implica que o pior tempo de transmissão é limitado e
conhecido com antecedência.
• Rede Geograficamente Distribuída (WAN – Wide Area Network). Abrange uma
grande área geográfica, podendo ser até mesmo um país ou continente.
• Rede Metropolitana (MAN – Metropolitan Area Network). Abrange uma cidade.
Um bom exemplo deste tipo de rede são as redes de transmissão de TV a cabo, criadas
para levar sinal até lugares onde não era possível utilizar a transmissão pelo ar.
• Rede de Armazenagem (SAN – Storage Area Network). Serve para conectar
dispositivos de armazenagem a altas velocidades, sem a necessidade da
implementação de uma LAN ou WAN para tal.
• Rede Pessoal (PAN – Personal Area Network). Trata-se do uso bem limitado de redes
wireless de poucos metros de alcance para comunicação entre dispositivos pessoais,
como notebooks, PDAs, telefones móveis, entre outros.
• Rede de Campus (CAN – Campus Area Network). É a nomenclatura utilizada para
uma série de LANs existentes em edifícios próximos fisicamente, muito comumente
encontradas em empresas e campus universitários. É maior que uma LAN e menor que
uma MAN.
2.2.3 Protocolos de Rede
O estabelecimento de uma conexão física entre dois computadores não é suficiente para que eles se comuniquem. A comunicação livre de erros, confiável e eficiente entre computadores exige a implementação de sistemas de software elaborados que geralmente são chamados protocolos. [...] Exige que os meios de transmissão sejam capazes de manipular a heterogeneidade de equipamentos e conexões. (OZSÜ; VALDURIEZ, 2001, p. 68)
A arquitetura ISO/OSI serviu como base para o protocolo mais conhecido nas redes do
tipo WAN. Entre cada camada de nós, está especificada uma interface clara que define a
22
passagem de informações entre as camadas de software e hardware. Semelhante ao OSI, outro
protocolo muito difundido é o TCP/IP, que possui menos camadas e não especifica a camada
de host para rede. O OSI possui sete camadas, enquanto o TCP/IP apresenta cinco. As
diferenças entre os protocolos e as camadas existentes em cada protocolo podem ser vistas na
Figura 1.
Figura 1 - Diferenças entre as camadas dos protocolos ISO/OSI e TCP/IP
O protocolo coloca caracteres de controle no início e no final do conjunto de dados transmitidos. Estes controles são conferidos ao chegarem na outra ponta, pelo outro programa/protocolo idêntico ao anterior. Se ao longo da transmissão ocorreu algum erro, o protocolo deve tentar enviar novamente os mesmos, até que cheguem corretamente. (SOUSA, 1996, p. 39)
2.2.3.1 Modelo de referência OSI
O modelo OSI (Open Systems Interconnection) é um protocolo que permite a
integração de diversos componentes. Ele divide as etapas de transmissão, definindo como
deve proceder cada etapa do processo ao transferir dados. Cada nível oferece serviços ao nível
seguinte e estão assim classificados:
• Nível 7 – Aplicação: trata-se dos programas aplicativos do usuário, o que pode ser
23
banco de dados, correio eletrônico etc.
• Nível 6 – Apresentação: é onde ocorre a conversão dos dados. Ex.: compressão de
dados, conversão de formatos, criptografia entregando os dados convertidos à
aplicação.
• Nível 5 – Sessão: estabelece a conexão entre aplicações, definindo como vai ser feita a
troca de informações e o modo de transmissão.
• Nível 4 – Transporte: faz o controle da transferência de dados entre os computadores,
garantindo que a mensagem seja entregue e evitando duplicações.
• Nível 3 – Rede: encaminha pacotes, faz contabilização e transferência de dados para
outra rede.
• Nível 2 – Controle de linha: faz a detecção e a correção de erros, fazendo com que a
linha física pareça livre de erros.
• Nível 1 – Físico: especifica conexões elétricas, cabos, nível de voltagem de luz etc.
2.2.3.2 Protocolo TCP/IP
O protocolo TCP/IP foi criado para atender necessidades de endereçamentos e
problemas de interconexão de redes, garantindo interoperabilidade entre diferentes sistemas e
objetivando ser transparente aos diferentes hardwares de diferentes plataformas, protocolos e
interfaces do nível físico existentes (SOUSA, 1996, p. 91). Trata-se de um grupo de
protocolos e padrões que definem como deve funcionar o acesso a correio eletrônico,
transferência de arquivos etc., que interagem entre si a fim de transferir dados de um ponto a
outro.
Os protocolos mais comuns dentro da arquitetura TCP/IP são:
• IP: envia datagramas, mas não controla envio/recebimento correto dos dados.
• TCP: transporta os dados, efetuando correção de dados para garantir sua integridade.
• FTP: O File Transfer Protocol é utilizado para efetuar o compartilhamento e a
transferência de arquivos remotos, através do TCP.
• SMTP: O Simple Mail Transfer Protocol é o protocolo que trata de acessos a correio
eletrônico.
24
2.2.4 Segurança em Redes
O fator segurança é uma das grandes preocupações ao utilizar redes e, principalmente,
no momento em que dados passam a ser trafegados pela Internet.
A segurança é um assunto abrangente e inclui inúmeros tipos de problemas. Em sua forma mais simples, a segurança se preocupa em garantir que pessoas mal-intencionadas não leiam ou, pior ainda, modifiquem mensagens secretamente enviadas a outros destinatários. (TANENBAUM, 2003, p. 767)
São necessárias algumas técnicas para trafegar dados com segurança. Segundo
Tanenbaum (2003, p. 770-804), as mais utilizadas são:
• Criptografia: As informações a serem enviadas são transformadas em códigos que
seguem um padrão especificado por uma chave. Para ser possível desfazer esta
criptografia e ler a mensagem no destino, é necessário possuir uma cópia da chave de
encriptação e realizar o processo inverso.
• Algoritmos de chave simétrica: São algoritmos de criptografia que buscam criar
chaves mais elaboradas, procurando tornar praticamente impossível o entendimento da
encriptação. Este tipo de algoritmo utiliza a mesma chave para codificação e
decodificação.
• Algoritmos de chave pública: Neste caso, a chave de criptografia e a chave de
descriptografia são diferentes e é muito difícil derivar uma a partir da outra. Desta
maneira, uma chave de criptografia é criada e distribuída publicamente, mas a chave
de descriptografia é mantida em segredo, permitindo que qualquer indivíduo
interessado no envio de mensagens secretas a alguém possa fazê-lo tendo garantia de
que apenas o destinatário será capaz de decifrá-la.
• Assinaturas digitais: Buscam substituir assinaturas que em documentos impressos
são feitas à mão, procurando uma identificação digital para documentos enviados pela
Internet.
25
2.3 ESCALABILIDADE
A escalabilidade é uma das metas mais importantes em sistemas distribuídos.
“Escalabilidade permite que um sistema distribuído cresça (adicione mais máquinas ao
sistema) sem afetar as aplicações e os usuários existentes” (DEITEL, 2005, p. 507).
Infelizmente, um sistema escalável perde capacidade de desempenho à medida que é
ampliado.
Em um sistema que, por exemplo, um servidor trabalha para oferecer serviços
centralizados de acesso a dados e aplicativos, à medida que o sistema é ampliado haverá
gargalo de comunicação no servidor, logicamente, mesmo que este possua alta capacidade de
processamento. Se por um lado em alguns casos é necessário manter bancos de dados
centralizados por questões de segurança de dados, de outro fica claro que seria impossível
trabalhar sem replicar e distribuir dados visto que diversos sistemas trabalham com milhares
de requisições ao mesmo tempo.
Mesmo algoritmos centralizados não constituem uma boa prática. Ao ampliar o
número de estações de trabalho em uma rede, o crescimento do roteamento de mensagens é
exponencial, o que resulta em funcionamento não eficiente se for centralizado. Desta maneira,
o trabalho dos algoritmos quando distribuídos deve utilizar comunicação assíncrona, tendo em
vista que a perfeita sincronização de relógios demandaria considerável esforço.
Não só algoritmos, mas sistemas distribuídos como um todo devem se utilizar de
comunicação assíncrona para ocultar a latência de comunicação, distribuição e replicação. A
ideia, de acordo com Tanenbaum (2007, p. 7), é que após efetuar uma requisição, a aplicação
não fique parada aguardando por um retorno, devendo esta executar outra tarefa até a chegada
da resposta, o que dispara o funcionamento de um manipulador especial para finalizar a
requisição emitida anteriormente.
Há casos em que esta técnica não se aplica, porque não é possível aguardar uma
resposta e executar outra operação naquele intervalo de tempo. Neste caso, é possível fazer a
transferência de informações constantemente ao servidor, podendo assim, por exemplo, fazer
a validação de um formulário enviando campo por campo durante o preenchimento do
mesmo. Enquanto o usuário digita o conteúdo dos campos do formulário, o sistema vai
fazendo a verificação dos dados já digitados e informa ao usuário em tempo de edição sobre
um possível erro de sintaxe, acelerando o processo no momento de submissão definitiva do
formulário.
26
Considerando que problemas de escalabilidade frequentemente aparecem sob a forma de degradação do desempenho, em geral é uma boa ideia replicar componentes por um sistema distribuído. A replicação não somente aumenta a disponibilidade, mas também ajuda a equilibrar a carga entre componentes, o que resulta em melhor desempenho. Além disso, em sistemas de ampla dispersão geográfica, ter uma cópia por perto pode ocultar grande parte dos problemas de latência de comunicação já mencionados. (TANENBAUM, 2007, p. 9)
Uma das melhores formas de obtenção de replicação é o uso de cache. Um bom
exemplo de replicação por cache é o uso de servidores Proxy que armazenam o conteúdo de
páginas recentemente acessadas pelos clientes de uma LAN (Local Area Network) e, ao ser
requisitada novamente pelo mesmo ou por um cliente diferente, a página é carregada a partir
do cache, diminuindo então a latência e o tempo de resposta.
A existência de uma série de cópias de um mesmo recurso às vezes pode gerar
inconsistência. Se uma das cópias for atualizada, todas as outras ficam inconsistentes e é
necessário utilizar técnicas especiais de controle de consistência. Em alguns casos é aceitável
para um cliente receber uma página verificada há poucos minutos, tendo em vista que não é
um site de informações constantemente atualizadas. Já em casos onde os resultados são
informados em tempo real e atrasos de alguns minutos podem fazer muita diferença, o uso de
cache não é uma boa prática.
2.4 SISTEMAS DE COMPUTAÇÃO DISTRIBUÍDOS
Existem três modelos de sistemas de computação distribuídos, sendo dois deles
largamente empregados atualmente para aplicações de alto desempenho, e o terceiro
começando a compor o cenário de alternativas viáveis voltadas para, de modo especial, o
meio corporativo.
No modelo computação de cluster, “o hardware subjacente consiste em um conjunto
de estações de trabalho ou PCs semelhantes, conectados por meio de uma rede local de alta
velocidade” (TANENBAUM, 2007, p. 10). O sistema operacional utilizado também é
semelhante entre elas. O uso deste tipo de computação surgiu a partir da diminuição do custo
para aquisição de computadores pessoais e da visão de que a união de vários computadores
para execução de tarefas paralelas poderia ser uma alternativa à compra de
27
supercomputadores e à reutilização de recursos obsoletos. Um exemplo bastante conhecido é
o cluster Beowulf baseado em Linux, cuja organização está representada na Figura 2.
Figura 2 - Organização do cluster Beowulf
Estabelecendo uma comparação entre os clusters e os sistemas em grade percebemos
que o primeiro é homogêneo, apresentando mesmo sistema operacional, mesma arquitetura e
estando todos os nodos conectados à mesma rede, o que não acontece em sistemas em grade.
Nestes, existe alto grau de heterogeneidade: hardware, sistemas operacionais, redes, domínios
administrativos, políticas de segurança, entre outros. Um aspecto importante na computação
em grade é o fato de que “recursos de diferentes organizações são reunidos para permitir a
colaboração de um grupo de pessoas ou instituições” (TANENBAUM, 2007, p. 11).
A organização de um sistema em grade se dá por meio de grupos conectados uns aos
outros em uma organização virtual, como apresenta a Figura 3. Dessa maneira, cada grupo
tem dentro de seu domínio, acesso exclusivo a determinados recursos, que podem ser clusters
ou impressoras, por exemplo, os quais não estão disponíveis a outros grupos. Quanto a outros
recursos o compartilhamento pode ser total, como por exemplo, a distribuição de tarefas de
processamento entre grupos para melhor utilização de nodos ociosos.
28
Figura 3 - Organização virtual provida pela computação em grade
A computação em nuvem deriva dos modelos acima citados e é um conceito recente.
Trata-se de um modelo emergente de infraestrutura de tecnologia da informação desenvolvido
para oferecer recursos computacionais a alta velocidade. As estações de trabalho necessitam
basicamente de um sistema operacional e algumas configurações de acesso a recursos
disponíveis em servidores remotos. Como o usuário não sabe onde estão localizados
fisicamente estes recursos, adotou-se a nomenclatura “nuvem”, que representa um
aglomerado de servidores espalhados pelo mundo acessíveis via Internet. Os serviços são
entregues de maneira simples, provendo escalabilidade, qualidade diferenciada e enfoque no
usuário para prover inovação e eficiente tomada de decisões (IBM, 2009).
A tecnologia de serviços Web, que representa o próximo estágio da computação distribuída, afetará profundamente as organizações no futuro. Serviços Web abrangem um conjunto de padrões relacionados que podem habilitar quaisquer duas aplicações de computador a se comunicar e trocar dados via Internet. Muitos fatores indicam que os serviços Web mudarão radicalmente as arquiteturas de TI e os relacionamentos entre parceiros. (DEITEL, 2005, p. 551)
29
O que Deitel (2005) afirmou pode ser visto hoje com o nome de computação nas
nuvens. As vantagens, desvantagens e outros detalhes a respeito deste novo modelo
distribuído serão discutidos no próximo capítulo.
3 COMPUTAÇÃO NAS NUVENS
3.1 CONCEITUAÇÃO
O termo computação nas nuvens, do inglês cloud computing, surgiu como um novo
modelo de computação distribuída que aproveita conceitos de clusters e grids, além de basear-
se nos avanços de técnicas de virtualização conquistados nos últimos anos. O conceito de
“nuvem” surge da disposição física dos elementos envolvidos no modelo. Em outras palavras,
os servidores que hospedam dados e aplicativos ficam localizados em datacenters de
empresas de qualquer parte do mundo, o que nos leva à necessidade de um termo que abstraia
esta localização. Para tal, adotou-se o termo “nuvem”, significando então, um emaranhado de
servidores disponíveis via Internet.
De acordo com Andy Bechtolsheim (2008), o modelo de computação em nuvem é a
quinta geração da computação, depois do mainframe, PC (Personal Computer), modelo
cliente-servidor e Web. Trata-se de uma evolução do modelo cliente-servidor, diferindo na
distribuição do processamento, o qual é em grande parte centralizado no servidor remoto,
cabendo ao terminal cliente efetuar pequenas tarefas de processamento locais.
Computação em nuvem, portanto, trata-se da utilização de softwares ou sistemas em
rede e da capacidade de prover recursos ao usuário sob demanda. Desta maneira, as
informações são permanentemente armazenadas em servidores na Internet (localizados na
“nuvem”), sendo realizadas caches destes dados em computadores desktop, notebooks,
dispositivos móveis, entre outros, os quais estarão fazendo uso da infraestrutura em nuvem.
É comum referir-se ao modelo como utility computing (computação como uma
utilidade), o que significa que o usuário poderá acessar aplicações de negócio online, a partir
de qualquer dispositivo virtualmente disponível, mediante um pagamento por uso.
Devido ao fato de permitir escalabilidade e elasticidade, o modelo oferece aos
administradores de tecnologia da informação uma maneira de aumentar a capacidade de
acordo com a demanda. Ou seja, com a adoção do modelo, não existe a necessidade de alto
investimento na substituição de hardware obsoleto, na compra de licenciamento de softwares
ou no treinamento de pessoal, uma vez que todo o processamento se dá em servidores
localizados nas "nuvens", pagando apenas pelo tráfego que de fato for gerado.
31
3.2 CARACTERÍSTICAS
Na computação tradicional, os softwares rodam sob plataformas individuais e são
cópias instaladas em cada unidade de trabalho. Todos os documentos criados por tais
softwares são armazenados localmente no disco rígido do computador e podem ser acessados
por computadores de uma mesma rede, mas não por terminais localizados fora da mesma.
Esta abordagem pode ser considerada orientada a terminal.
De modo contrário à abordagem supra-citada surge a computação nas nuvens. As
aplicações e os documentos utilizados não rodam e não são armazenados, respectivamente,
em unidades de trabalho, mas em servidores acessíveis a partir de outro dispositivo ou estação
via Internet. Se ocorrer alguma falha na unidade de trabalho, softwares e documentos
permanecem acessíveis, uma vez que estão armazenados em uma coleção de servidores.
Trata-se de uma abordagem orientada a documento.
A computação em nuvem não deve ser confundida com computação em rede. Nesta
última, as aplicações e os documentos estão hospedados em servidores localizados dentro de
uma companhia e acessíveis apenas na rede da mesma. Já a computação em nuvem envolve
várias companhias, vários servidores e várias redes de transmissão, disponibilizando serviços
e documentos em qualquer local do mundo que ofereça acesso à Internet. Contudo, esta
infraestrutura de comunicação, processamento e armazenagem deve ser transparente ao
usuário final, mesmo que parcialmente.
Esta transparência vem do conceito de abstração característico de todo sistema
computacional distribuído. “Um sistema distribuído é um conjunto de computadores
independentes que se apresenta aos seus usuários como um sistema único e coerente”, definiu
Tanenbaum (2007, p. 1). A infraestrutura é transparente ao usuário permitindo que o acesso
ocorra a partir de qualquer dispositivo com acesso à Internet, esteja ele rodando qualquer
sistema operacional e qualquer navegador devidamente atualizados.
De acordo com Miller (2008), a organização pioneira na disponibilização de serviços
em computação nas nuvens, o Google, elenca seis propriedades do modelo:
• Orientação ao usuário: Uma vez que o usuário está conectado à nuvem, qualquer
documento armazenado – arquivos de texto, mensagens, imagens, aplicações – torna-
se propriedade do usuário.
• Orientação à tarefa: Em vez de focar na aplicação e o que ela pode fazer, o foco está
no que o usuário necessita realizar e em como a aplicação pode auxiliá-lo. Aplicações
32
tradicionais – editores de texto e planilhas de cálculo, e-mail, etc. - estão tornando-se
menos importantes que os documentos criados por elas.
• Eficácia: O fato de se conectar centenas ou milhares de computadores a uma nuvem
cria uma riqueza de poder computacional impossível de ser implementada com um
único computador.
• Acessibilidade: Uma vez que dados são armazenados diretamente nas nuvens, o
usuário tem a possibilidade de instantaneamente buscar mais informações de diversos
repositórios. Não há limitação a uma única fonte de dados, como em uma unidade
individual de trabalho.
• Inteligência: Com grandes montantes de informação armazenados em servidores nas
nuvens, a mineração e análise de dados são técnicas necessárias para um
aproveitamento mais inteligente da informação acessível. Arquiteturas em nuvem
facilitam estas tarefas, uma vez que todos os dados e aplicações encontram-se
centralizados.
• Programável: Muitas tarefas do modelo em nuvem devem ser automatizadas. Por
exemplo, para proteger a integridade dos dados, as informações armazenadas em um
único computador na nuvem devem ser replicadas para outros computadores da
mesma nuvem. Se este computador ficar indisponível, a programação da nuvem
automaticamente redistribui os dados daquele nodo para outro. Tratam-se de técnicas
de tolerância a falhas.
Em resumo, a computação em nuvem torna possível a mudança de foco do
computador para o usuário, da aplicação para a tarefa e do isolamento de dados para dados
acessíveis em qualquer local e compartilhados com qualquer membro que possua permissão.
3.3 MODELOS DE SERVIÇO
Existem alguns tipos de computação em nuvem que caracterizam a abordagem
utilizada, cuja qual pode variar de acordo com a necessidade do consumidor e ser classificada
como: aplicações, ambientes de software, infraestrutura de software, kernel de software e
hardware (YOUSEFF, 2008). Esta abordagem está representada em níveis na Figura 4.
33
3.3.1 Nível de Aplicação
O nível de aplicação é o mais visível ao usuário final. Normalmente, os serviços
prestados por este nível são acessíveis por usuários através de portais Web e, em alguns casos,
são serviços pagos. Este modelo mostrou-se atrativo para muitos usuários, uma vez que
diminui o peso da preocupação com a manutenção de software e o alto custo com operações e
suporte contínuos. Em outras palavras, o trabalho computacional é transferido aos datacenters
nos quais as aplicações em nuvem são desenvolvidas. Esta característica diminui as restrições
de hardware necessárias ao usuário final, além de fornecer ótimo desempenho a estações de
trabalho com hardware mais antigo, sem a necessidade de investimento na compra de novos
equipamentos.
Este modelo simplifica e facilita até mesmo o trabalho dos provedores de serviços em
nuvem. Uma vez que a aplicação é desenvolvida e mantida na infraestrutura da companhia
que provê o serviço, os desenvolvedores podem criar pequenos pacotes de atualização e
adicionar novas funcionalidades sem atrapalhar o trabalho dos usuários. Isto convenciona uma
receita garantida ao desenvolvedor e traz comodidade ao utilizador, sendo benéfica para
ambos os lados e normalmente referenciada como SaaS - Software as a Service (Software
como Serviço).
Apesar dos diversos benefícios oferecidos pelo modelo em questão, alguns problemas
de implantação limitam seu uso em larga escala. Especificamente, a segurança e a
disponibilidade de aplicações em nuvem são dois dos maiores problemas do modelo que
devem ser enfrentados por provedores e utilizadores. Mais um motivo para o retardo na
adoção de SaaS é a dificuldade na migração de dados para as nuvens.
3.3.2 Nível de Ambiente de Software
O segundo nível de acordo com a proposta de Youseff (2008) é o ambiente de
software, também chamado de plataforma de software. Este nível é utilizado por
desenvolvedores de aplicações para as nuvens, que implementam e implantam suas aplicações
diretamente na nuvem. Os provedores destes serviços nas nuvens oferecem aos
desenvolvedores um conjunto definido de APIs, as quais facilitam a interação entre o
ambiente e as aplicações em nuvem, assim como o aumento da agilidade de implantação e o
34
suporte à escalabilidade necessária para tais aplicações. O serviço oferecido neste nível é
comumente tido como PaaS – Platform as a Service (Plataforma como Serviço). Um exemplo
deste tipo de serviço é o Google App Engine, o qual oferece um ambiente de desenvolvimento
em Python e APIs que permitem aplicações interagirem com a nuvem do Google. O
framework App Engine será abordado em detalhes mais adiante.
Existem alguns benefícios para desenvolvedores de aplicações que voltam-se para
ambientes de programação em nuvem, incluindo estruturas que viabilizam escalabilidade e
balanceamento de carga automáticos, bem como a integração facilitada com outros serviços
para realização de tarefas como autenticação, tarefas de e-mail e interface com o usuário.
Desta forma, grande parte da complexidade de desenvolvimento é abstraída pelo ambiente de
programação e o desenvolvedor ganha a habilidade de integrar novos serviços a sua aplicação
de acordo com a necessidade. Em resumo, o desenvolvimento torna-se uma tarefa menos
complicada, há uma aceleração no tempo de implantação e minimização de falhas lógicas na
aplicação.
3.3.3 Nível de Infraestrutura de Software
O nível de infraestrutura de software fornece recursos fundamentais para camadas de
nível superior, permitindo a criação de novos ambientes de software ou novas aplicações.
Prosseguindo na visão de Youseff (2008), este nível pode ser categorizado em: recursos
computacionais, armazenamento de dados e comunicações.
a) Recursos Computacionais: Neste nível, máquinas virtuais (virtual machines) são a
melhor maneira de fornecer recursos computacionais, já que oferecem ao usuário
maior flexibilidade, uma vez que ele normalmente possui permissão total para uso da
máquina virtual, estando apto a personalizar o software e obter maior performance e
eficiência. Estes serviços são normalmente chamados IaaS – Infrastructure as a
Service (Infraestrutura como Serviço). A virtualização é a tecnologia responsável pela
existência deste componente de nuvem, o qual viabiliza ao usuário uma flexibilidade
jamais vista em termos de configuração na proteção da infraestrutura física do
datacenter. Recentemente, os avanços em virtualização de sistemas operacionais
trouxeram dois conceitos plausíveis para o nível em questão: a paravirtualização e a
35
virtualização assistida por hardware. Embora ambas as tecnologias abordem o
isolamento como uma forma de aumento de desempenho entre máquinas virtuais
compartilhando os mesmos recursos físicos, a interferência de desempenho entre
máquinas virtuais que fazem uso da mesma cache não pode ser descartada. A perda de
desempenho em máquinas virtuais compartilhando o mesmo meio físico, resulta na
incapacidade dos fornecedores de serviços nas nuvens em oferecerem garantias
aceitáveis de desempenho aos seus clientes.
b) Armazenamento de Dados: O segundo recurso de infraestrutura é o armazenamento
de dados, o qual permite ao usuário armazenar seus dados em discos remotos e acessá-
los a qualquer momento e de qualquer lugar. Este serviço é comumente conhecido
como DaaS – Data-Storage as a Service (Armazenamento de Dados como Serviço),
um facilitador de tarefas de escalabilidade que podem ir além de servidores limitados.
Sistemas de armazenamento de dados surgiram para suprir alguns requisitos sobre
gerenciamento de dados e informações, incluindo alta disponibilidade, confiabilidade,
desempenho, replicação e consistência de dados. Contudo, devido à natureza
conflitante destes requisitos, não existe um sistema capaz de implementar todos eles.
Alguns exemplos de sistemas de armazenamento de dados são: sistemas de arquivos
distribuídos e bancos de dados relacionais com replicação.
c) Comunicação: Uma vez que a necessidade de garantia de QoS – Quality of Service
(qualidade de serviço) para uma rede de comunicação cresce ao tratar-se de um
sistema em nuvem, a comunicação se torna um componente vital da infraestrutura em
questão. Em consequência disto, estes sistemas possuem a obrigação de fornecer
certas capacidades de comunicação “orientadas a serviço”, configuráveis,
programáveis, previsíveis e confiáveis. Com estas vantagens, o conceito de CaaS –
Communication as a Service (Comunicação como Serviço) surgiu para oferecer
suporte a determinados requisitos, tais como segurança em redes, encriptação de dados
e monitoramento de rede. Apesar deste ser o modelo comercialmente menos adotado
entre todos os serviços em nuvem existentes, segundo Youseff (2008), é possível
observar em algumas pesquisas que várias decisões, protocolos e soluções de projeto
arquitetural necessitam fornecer CaaS com QoS.
36
Alguns recursos comuns de projeto são compartilhados entre os três componentes de
infraestrutura. Por exemplo, segurança, disponibilidade e qualidade de serviços estão entre as
características mais importantes. Entretanto, o oferecimento de outros mecanismos de
segurança para arquiteturas “orientadas a serviço” é uma rica área de estudos e pesquisas, com
enfoque um pouco diferente das comunidades de SOA – Service-Oriented Architecture
(Arquitetura Orientada a Serviços) e das comunidades de segurança.
A interface com o usuário para componentes de insfraestrutura em nuvem varia
substancialmente de um sistema para outro. Exemplos de interfaces utilizadas neste modelo
são: SOAP – Simple Object Access Protocol e REST – Representational State Transfer.
Contudo, a própria característica de implementação “orientada a serviço” muito atrapalha,
sendo plausível projetar uma interface unificada e interativa através de um portal Web para
comunicar com serviços Web a fim de oferecer uma interface padronizada para serviços em
nuvem neste nível.
3.3.4 Nível de Kernel de Software
O nível de Kernel de Software é o responsável por oferecer o gerenciamento de
software básico para os servidores físicos que compõem a nuvem. Neste nível, o Kernel de
Software tem a possibilidade de ser implementado como um Kernel de SO, hypervisor,
máquina virtual e/ou clustering middleware. Algumas aplicações em grid foram implantadas e
rodadas neste nível com algumas máquinas conectadas em cluster. Contudo, a falta de bons
mecanismos de abstração de virtualização em computação em grid, tornam o trabalho muito
semelhante à infraestrutura de hardware e o suporte à migração, pontos de checagem e
balanceamento de carga para aplicações deste nível sempre foram tarefas difíceis.
O campo de pesquisa da computação em grid é vasto e alguns dos conceitos
desenvolvidos com tais estudos podem ser percebidos atualmente na computação nas nuvens.
Segundo Youseff (2008), pesquisas na área da computação em grid podem auxiliar
potencialmente nos avanços da computação nas nuvens, possibilitando mudanças
significativas da idéia atual do novo modelo para uma computação nas nuvens como utilidade
(utility computing).
37
3.3.5 Nível de Hardware e Firmware
O último nível proposto na ontologia de Youseff (2008) é composto pelo hardware e
pelos componentes de rede, os quais formam o esqueleto da nuvem. Desta forma, o cenário de
usuários deste nível de computação nas nuvens é composto por empresas de grande porte que
necessitam suprir grandes requisitos na parte de TI e podem adotar o modelo HaaS –
Hardware as a Service (Hardware como Serviço).
Neste tipo de serviço, a empresa fornecedora responsabiliza-se por gerenciar, operar e
atualizar o hardware de seus consumidores, por tempo determinado de sublocação. Este
modelo é vantajoso para o usuário a partir do momento em que elimina-se a preocupação com
investimentos na criação e manutenção de datacenters. Além disso, os fornecedores possuem
conhecimento técnico e infraestrutura de custo-benefício necessários para manter seus
sistemas, tornando-se especialistas no ramo. As características mais importantes de um
provedor de HaaS, entre outras, são agilidade e eficiência em escalar sistemas, manter
datacenters e minimizar o consumo de energia.
Todos os níveis apresentados estão ilustrados em camadas na Figura 4.
Figura 4 - Níveis de divisão da computação nas nuvens segundo a ontologia proposta
Fonte: Adaptado de Youseff (2008)
38
3.4 ECONOMIA
Os primeiros clientes a demonstrarem interesse na adoção da computação nas nuvens
foram as empresas. Tanto grandes quanto pequenas companhias têm a possibilidade de
redução de custos em TI e melhorias em produtividade com a utilização de ferramentas
baseadas na Web para gerenciamento de projetos, colaboração em documentos e
apresentações, gerenciamento de contatos empresariais, agendas e compromissos, etc. A
grande vantagem da computação nas nuvens para o meio empresarial é a capacidade de fazer
mais com orçamentos limitados.
Outra vantagem que a computação nas nuvens traz para uma empresa são os
benefícios da portabilidade. Ao invés de prender-se a documentos e aplicações armazenados e
instalados em computadores localizados em escritórios ou empresas, os colaboradores podem
ter acesso a qualquer dado necessário a partir de qualquer lugar com acesso à Internet – em
casa, no trabalho, na rua.
Segundo pesquisa publicada por George Reese (2008), o mundo está passando por
uma crise financeira jamais vista na história, o que impulsiona a busca por alternativas mais
baratas para dar continuidade a operações em empresas. “Os mercados de capitais estão
congelados e as empresas que necessitam fazer investimentos de capital para crescer ou
continuar as suas operações estão enfrentando um desafio” (REESE, 2008). A falta de capital
ocasiona uma falta de flexibilidade em aproveitamento da tecnologia para operar e
desenvolver um negócio. No momento em que não é possível para uma empresa conseguir um
empréstimo bancário, passa a ser necessário utilizar receitas da própria empresa para comprar
novos servidores e estações de trabalho.
Tipicamente, quando uma empresa quer ampliar sua estrutura de TI, existem duas
alternativas apontadas por Reese (2008):
• Implementá-la por si própria, alugar equipamentos caso necessário;
• Terceirizar a infraestrutura para um provedor de serviços.
Uma característica comum às duas alternativas é a necessidade de suprir picos de uso
independentemente do tempo gasto por eles, ou seja, a empresa deve possuir infraestrutura
capaz de sanar momentos de maior demanda, sejam eles de apenas uma hora durante um ano
ou de praticamente o ano inteiro. Em casos de pouca frequência destes picos, os equipamentos
ficam ociosos e/ou subutilizados.
A análise proposta por Reese (2008) supõe que, para determinado cliente, dois
39
servidores de aplicação apoiados por dois servidores de banco de dados, mais um balanceador
de carga sejam a solução do problema. As opções seriam semelhantes às apresentadas na
Tabela 1.
Tabela 1 - Comparativo entre TI Interno e Serviços Terceirizados
TI Interno ($) Serviços Terceirizados ($)
Investimento de Capital 40.000 0Custos de Implantação 10.000 5.000Serviços Mensais 0 4.000Trabalho Mensal 3.200 0Custo após 3 anos 149.000 129.000Fonte: Reese (2008)
De acordo com as observações feitas pelo pesquisador, assumem-se os seguintes
fatores: servidores com boa quantidade de memória RAM e um bom balanceador de carga;
custo após três anos é tido como 10% do custo do capital; um bom fornecedor de serviços
terceirizados com custo-benefício. Com esta visão, no cenário especificado acima, os serviços
terceirizados conseguem uma economia de 13,5% sobre a abordagem de manter um setor
interno de TI na empresa.
Um dos atrativos de serviços terceirizados é a inexistência de investimento de capital.
Analisando a pesquisa de Reese (2008), para uma abordagem com TI interno, o investimento
inicial seria de 40.000 dólares, o que representa um altíssimo investimento inicial diante da
situação atual da economia. Esta conclusão, mostra que os argumentos sugerem a adoção da
abordagem de serviços terceirizados, mas Reese compara esta com a computação nas nuvens,
como pode ser visualizado na Tabela 2.
Em comparação com o modelo de TI interno na empresa, a computação nas nuvens
consegue uma economia de 29%. E em comparação com serviços terceirizados, a computação
nas nuvens economiza 18% dos custos. É importante ressaltar que nesta pesquisa não estão
sendo consideradas questões como compra por capacidade e compra por uso, o que
aumentaria os ganhos com a computação nas nuvens, cuja qual é paga por uso.
40
Tabela 2 - Comparativo entre Serviços Terceirizados e Computação nas Nuvens
Serviços Terceirizados ($) Computação nas Nuvens ($)
Investimento de Capital 0 0Custos de Implantação 5.000 1.000Serviços Mensais 4.000 2.400Trabalho Mensal 0 1.000Custo após 3 anos 129.000 106.000Fonte: Reese (2008)
Além dos números, Reese afirma que existem outros benefícios econômicos com a
adoção da abordagem em nuvem, tais como: investimento inicial nulo, sejam quais forem as
necessidades do consumidor; discrepância entre o pico e a média de uso de processamento
torna a diferença entre o custo da computação em nuvem cada vez mais vantajosa em relação
a outras opções; no modelo em nuvem há automaticamente a inclusão de um bom espaço de
armazenamento, o qual é elástico e cresce de acordo com a necessidade, diferentemente de
outras opções que se tornariam consideravelmente mais caras quando da adição de novos itens
de hardware; redundância se torna mais barata a partir do momento em que esta é uma
preocupação extremamente importante por parte dos provedores de serviços em nuvem.
3.5 APLICAÇÕES E PÚBLICO-ALVO
Existem diversas atividades desempenhadas por grupos de pessoas que podem ser
melhor realizadas e gerenciadas por sistemas computacionais, especialmente sistemas em
nuvem. Pode-se estabelecer formas de colaboração para tomadas de decisão, agendamento de
tarefas, eventos e compromissos, criação de orçamentos, controle de despesas, apresentações,
entre outras. De acordo com Miller (2008), a migração de aplicativos para as nuvens permitiu
o crescimento de grupos de colaboração, bem como a facilitação da execução de suas
atividades, especialmente com o surgimento de novos aplicativos para as nuvens. Ele ainda
divide usuários de computação nas nuvens em três grupos: usuários domésticos, comunidade
e grupos e corporações.
41
3.5.1 Usuários Domésticos
É comum que todos os membros de uma família trabalhem em locais diferentes e
tenham, então, poucos momentos de comunicação verbal e pessoal. É possível centralizar as
comunicações entre membros em comunicações baseadas em webmail, acabando com a ideia
de e-mail acessível em um único computador via aplicações como o Microsoft Outlook que
efetuam download das mensagens para a estação de trabalho.
Da mesma forma que a comunicação via e-mail, a armazenagem de compromissos em
agendas de aplicativos locais impedia ou dificultava a colaboração e visualização de eventos
programados entre membros de um grupo familiar. Para assegurar confirmações e
notificações de compromissos nos sistemas atuais, estão disponíveis estruturas automatizadas
para desempenhar tal tarefa. Ou seja, uma vez criado um evento por algum membro possuidor
de permissão, cada membro do grupo poderá receber notificações via e-mail ou mensagem
SMS, sendo capaz de confirmar ou não a sua participação. Além disso, o usuário pode
configurar seu sistema de agenda para ser notificado novamente alguns instantes antes da
ocorrência do evento, de acordo com as possibilidades de configuração oferecidas por seu
serviço de agenda.
Outros serviços funcionam semelhantemente ou servem apenas como referência cujo
qual um grupo de membros pode editar. Neste caso, temos exemplos como listas de compras
de supermercado, listas de afazeres, gerenciamento de orçamentos e projetos escolares. Um
serviço muito comum e de ampla utilização, segundo Miller (2008), é a suíte de aplicativos
online Google Docs, que oferece serviços de edição de textos, planilhas e apresentações,
todos com possibilidade de colaboração online por número ilimitado de usuários. Além deste,
serviços de e-mail como Gmail, Windows Live Hotmail e Yahoo! Mail propiciam o
compartilhamento e introduzem novidades tais como a evidência do compartilhamento e os
serviços de comunicação instantânea. Pode-se citar também serviços de listas de tarefas como
Planner, Remember the Milk, Ta-da List, Bla-bla List, Tudu List e Voo2Do, que possuem
características diferentes entre si e os serviços de compartilhamento de álbuns de fotos online,
como o famoso Flickr. Veja a Figura 5, que demonstra uma nuvem de serviços divididos em
grupos, criada a partir da análise de serviços e com base em citações de Miller (2008).
42
3.5.2 Comunidades e Grupos
Semelhantemente às possibilidades de colaboração disponíveis para grupos familiares,
existem ferramentas em nuvem para facilitar e gerenciar a troca de informações entre grupos e
comunidades de qualquer segmento. O gerenciamento de agendas e compromissos funciona
de modo a permitir que todos tenham como confirmar a participação em eventos, trabalhando
com notificações e permitindo a mais de um usuário gerenciar a agenda do grupo. De acordo
com a necessidade, existem algumas opções como Google Calendar, Yahoo! Calendar,
CalendarHub e Zvents.
Para o gerenciamento de orçamentos de projetos é possível encontrar serviços como o
Salesforce.com AppExchange, um integrante da família Salesforce.com que traz um
detalhamento maior e mais precisão nos resultados. Contudo, gratuitamente é possível
encontrar algumas outras opções, tais como Google Spreadsheets e Zoho Sheet que oferecem
planilhas de cálculo online e colaborativas. Outra necessidade comum a grupos e
comunidades são ferramentas de marketing para projetos. Os serviços Google Docs e Zvents
facilitam estas atividades e redes sociais como Facebook e Myspace podem auxiliar no
aumento da visibilidade destes eventos entre nichos específicos. Veja a Figura 5, que ilustra a
divisão em grupos de alguns aplicativos em nuvem mais conhecidos, criada a partir da análise
de serviços e com base em citações de Miller (2008).
3.5.3 Corporações
Esta é a classe de usuário que antes aderiu aos sistemas de computação nas nuvens,
segundo a visão de Miller (2008). A economia e o aumento de produtividade são interessantes
a pequenas e grandes empresas, as quais podem fazer mais com orçamentos limitados. Este é
o motivo pelo qual existem suítes dedicadas a oferecer conjuntos de ferramentas em um único
pacote, com integração entre elas, voltadas a empresas. Exemplos disto são Salesforce.com e
Google Apps. Ambos oferecem aplicativos de diversas espécies integrados, que juntos
substituem os softwares tradicionais instalados localmente nas estações de trabalho.
O uso de computação nas nuvens ajuda empresas a gerenciar projetos com eficiência,
englobando agendas de compromissos compartilhadas entre membros da organização,
gerenciamento de projetos, relatórios, ferramentas de marketing, orçamentos, relatórios de
43
despesas, apresentações e mobilidade. Aplicativos como BigContacts e Highrise facilitam o
gerenciamento e a colaboração de listas de contatos e/ou clientes, da mesma forma que
projetos podem ser totalmente gerenciados por aplicativos como AceProject, Basecamp,
onProject e Project Insight.
Existem alguns serviços de agendas de compromissos voltados para o meio
empresarial que pode-se citar, como o Appointment Quest, hitAppoint e Schedulebook, todos
oferecendo maiores opções de compartilhamento e visibilidade. Para um melhor entendimento
de aplicativos voltados a este meio, elaborou-se a Figura 5 a partir da análise de serviços e
com base em citações de Miller (2008).
Figura 5 - Aplicativos de computação nas nuvens divididos em grupos de usuários
Fonte: o autor
4 PROVEDORES DE SERVIÇOS EM NUVEM
Existem alguns níveis de computação nas nuvens como visto no capítulo anterior.
Cada serviço possui detalhes que o diferenciam dos demais, como por exemplo, o custo de
uso e as limitações impostas. Algumas empresas dedicadas em disponibilizar serviços de
computação nas nuvens trabalham com módulos abertos a desenvolvedores, facilitando o
crescimento de suas plataformas e abstraindo a complexidade no desenvolvimento de sistemas
escaláveis.
Muitos são os serviços existentes no mercado, mas existem alguns que podem ser
destacados. Os sistemas de cobrança da Amazon, por exemplo, seguem a ideia de pagamento
sob-demanda, cobrando do cliente apenas o que ele utiliza de fato. Além deste fator, um ponto
positivo dos serviços entregues pela Amazon é a integração entre eles.
4.1 AMAZON WEB SERVICES
A Amazon Web Services existe desde 2006 e oferece uma série de serviços em
computação nas nuvens, cada um voltado a um específico nicho de usuário, para atender
desde a necessidade de taxas altas de processamento até a alta demanda de disponibilidade.
4.1.1 Amazon Elastic Compute Cloud (Amazon EC2)
A Amazon Elastic Compute Cloud (Amazon EC2) é uma plataforma paga que oferece
remotamente um conjunto de computadores rodando Linux/UNIX ou Windows com
permissões de administrador do sistema, cuja qual é capaz de ampliar ou reduzir de acordo
com a necessidade do cliente. Isto possibilita “alugar” tantos computadores quanto forem
necessários e acessá-los remotamente, podendo o cliente instalar, acessar e desenvolver
aplicações para este ambiente, além de armazenar dados e documentos. Trata-se de uma
Infraestrutura como Serviço (IaaS), uma vez que oferece recursos para camadas de nível
superior, permitindo a criação de novos ambientes de software e de novas aplicações.
45
O oferecimento do Amazon EC2 se dá de várias formas. O cliente decide quantas
estações de trabalho necessita, seja usuário doméstico ou corporativo, e contrata o tipo de
sistema operacional e outros recursos.
4.1.2 Amazon SimpleDB
O Amazon SimpleDB é um serviço que provê as principais funções de um banco de
dados voltado para as nuvens. O objetivo do SimpleDB é diminuir a complexidade de uso de
bancos de dados escaláveis, permitindo ao desenvolvedor preocupar-se apenas com a
aplicação em desenvolvimento. Este tipo de serviço é classificado como Armazenamento de
Dados como Serviço (DaaS), visto que ele permite ao usuário armazenar seus dados em
discos remotos e acessá-los a qualquer momento e de qualquer lugar.
O Amazon SimpleDB trabalha com uma abordagem que elimina a necessidade de
modelagem de dados, constantes manutenções e preocupação com aumento de desempenho, o
que normalmente acontece com desenvolvedores que utilizam bancos relacionais. O serviço
oferece um conjunto de APIs para armazenagem e acesso aos dados, possibilitando
implementar escalabilidade, pagando somente por recursos utilizados.
4.1.3 Amazon Simple Storage Service (Amazon S3)
O Amazon S3 é outro exemplo de Armazenamento de Dados como Serviço (DaaS),
que diferencia-se do SimpleDB por ser voltado apenas à Internet. Trata-se de um sistema de
armazenamento de arquivos que vai desde 1Byte até 5GB, escalável, preparado para serviços
Web que realizem muitas requisições simultâneas.
4.1.4 Amazon CloudFront
Amazon CloudFront é um serviço Web para distribuição de conteúdo. Ele integra-se a
outros serviços da Amazon para prover a desenvolvedores e empresas uma forma fácil de
distribuir conteúdo para seus clientes, com baixa latência e alta velocidade de transferência de
46
dados. A distribuição de conteúdo se dá por meio de uma rede global distribuída. As
requisições são automaticamente encaminhadas para a localidade mais próxima, garantindo
assim que o conteúdo seja fornecido com o menor tempo possível.
O CloudFront é outro serviço classificado na categoria Armazenamento de Dados
como Serviço (DaaS), um dos mais baratos da Amazon.
4.1.5 Amazon Elastic MapReduce
O Amazon Elastic MapReduce é um serviço Web que permite a empresas,
pesquisadores, analistas de dados e desenvolvedores realizarem o processamento de grandes
quantidade de dados de forma fácil e rentável. Trata-se de um serviço utilizador dos recursos
de infraestrutura do Amazon EC2 e do Amazon S3. Os usos mais indicados para o serviço
são tarefas como indexação da Web, mineração de dados, análise de arquivos de log,
aprendizado de máquina, análise financeira, simulação científica e investigação
bioinformática. Trata-se de uma Infraestrutura como Serviço (IaaS).
4.1.6 Amazon Virtual Private Cloud (Amazon VPC)
O Amazon Virtual Private Cloud (Amazon VPC) é uma forma de transmissão de dados
com segurança e transparência entre a infraestrutura de TI de uma empresa e a infraestrutura
em nuvem da Amazon. O serviço permite que uma empresa conecte sua infraestrutura
existente a um conjunto de recursos oferecidos pela Amazon, de forma isolada através de uma
Rede Virtual Privada (VPN), ampliando suas capacidades de gestão, tais como serviços de
segurança, firewalls e sistemas de detecção de intrusão. Neste caso, classifica-se o Amazon
VPC em Comunicação como Serviço (CaaS), uma vez que há uma forte necessidade de
garantia de QoS na transmissão de dados via Internet.
4.2 SUN
A Sun oferece a plataforma Sun Open Cloud, uma “infraestrutura open source de
47
cloud computing ativada por tecnologias de software líderes da indústria, incluindo Java,
MySQL, OpenSolaris e Open Storage” (SUN, 2009). A estratégia da Sun é o oferecimento de
nuvens públicas para garantir maior interoperabilidade, isto é, assegurar a livre troca de
informações entre nuvens públicas e privadas.
Outro compromisso assumido pela Sun enquanto provedora de serviços em nuvem é o
oferecimento de APIs para o público desenvolvedor. A empresa tem histórico forte na criação
de comunidades colaborativas para fazer com que seus produtos cresçam e desenvolvam de
forma livre, característica que a Sun pretende implantar com serviços em nuvem da mesma
forma.
A Sun Open Cloud é oferecida sob-demanda e classifica-se em Plataforma como
Serviço (PaaS), uma vez que oferece aos desenvolvedores um conjunto definido de APIs para
facilitar a interação entre o ambiente e as aplicações em nuvem, assim como o aumento da
agilidade de implantação e o suporte à escalabilidade.
“Os principais parceiros e entusiastas dos padrões de cloud [nuvem] estão apoiando a Sun Microsystems para oferecer uma plataforma aberta de cloud que ajudará a garantir que os desenvolvedores tenham um ecossistema robusto de aplicações e serviços para acelerar a criação e a implementação de aplicações cloud-enabled (viabilizadas para clouds) e para simplificar o gerenciamento”. (SUN, 2009).
4.3 IBM
A IBM mantém o IBM Cloud Labs em nove centros de larga expansão no mundo,
incluindo São Paulo. Existe um grupo de softwares oferecidos para dar suporte a cada etapa
de migração de um ambiente tradicional para outro em nuvem, através dos quais a IBM
facilita as tarefas mais essenciais. Outros softwares estão disponíveis para o controle,
gerenciamento e segurança do ambiente em nuvem para serem utilizados após a aquisição do
modelo. Tivoli e LotusLive são alguns dos softwares disponibilizados.
A plataforma para desenvolvedores da IBM chama-se developerWorks, a qual possui
seções específicas para computação nas nuvens.
48
4.4 EUCALYPTUS
Eucalyptus (Elastic Utility Computing Architecture Linking Your Programs To Useful
Systems) é uma infraestrutura open source para implementação de computação nas nuvens em
cluster, por meio de ferramentas em Linux e serviços Web básicos. Atualmente, a interface do
Eucalyptus é capaz de comunicar-se com os serviços EC2 e S3 da Amazon, mas o projeto
busca oferecer suporte a todos os serviços públicos ou privados existentes no mercado que
estiverem interessados em firmar parcerias.
O projeto surgiu no departamento de Ciência da Computação da Universidade da
Califórnia como projeto de pesquisa, sendo posteriormente transformado em organização por
seus criadores.
4.5 VMWARE
A VMware tornou-se reconhecida mundialmente devido ao desenvolvimento da
plataforma de mesmo nome para virtualização. Como propulsora da computação nas nuvens,
a virtualização utiliza de maneira mais eficaz recursos de hardware subutilizados. A aposta da
VMware no campo de computação nas nuvens é a associação da virtualização a este novo
modelo computacional distribuído, aplicada como VMware vCloud e VMware vSphere.
4.5.1 VMware vCloud
O VMware vCloud é a solução em computação nas nuvens oferecida pela VMware. O
diferencial deste serviço é o estabelecimento de parcerias com provedores de computação nas
nuvens para garantir a interoperabilidade entre nuvens públicas e privadas e a correta
execução de aplicativos já existentes. Para tal, o VMware vCloud estabelece padrões de
comunicação via interfaces bem estabelecidas.
49
4.5.2 VMware vSphere
VMware vSphere, o primeiro sistema operacional em nuvem do setor, utiliza os recursos da virtualização para transformar datacenters em infraestruturas de computação em nuvem consideravelmente simplificadas e permite que as organizações de TI forneçam a próxima geração de serviços de TI flexíveis e confiáveis usando recursos internos e externos com segurança e baixo risco. (VMWARE, 2009)
Figura 6 - Organização do VMware vSphere, o primeiro sistema operacional em nuvem do mercado
Fonte: VMware (2009)
50
O VMware vSphere é oferecido em seis versões diferentes. Está disponível juntamente
com a plataforma um software para efetuar migração de aplicativos já existentes para a
plataforma do vSphere. Além disso, cada característica importante segundo a visão da
VMware para sistemas de computação nas nuvens, possui um software ou serviço
especializado. Por exemplo, para controlar a parte de segurança da plataforma, existe o
VMware VMsafe que “permite o uso de produtos de segurança que funcionam em conjunto
com a camada de virtualização para oferecer a máquinas virtuais níveis mais altos de
segurança do que os oferecidos por servidores físicos (VMWARE, 2009). Na figura 6 é
possível visualizar as camadas de trabalho do vSphere.
4.6 MICROSOFT
Compute, Storage e Fabric são os três níveis oferecidos pela Microsoft no Windows
Azure como forma de facilitar a migração da plataforma tradicional para a abordagem em
nuvem. Juntamente com o ambiente de desenvolvimento do Windows Azure, eles fornecem
uma ponte para desenvolvedores que quiserem hospedar seus aplicativos.
O Azure é parte do Azure Services Platform, que visa prover um ambiente similar ao
sistema operacional Windows, voltado a negócios e clientes. Dados e aplicativos dos usuários
são armazenados em servidores controlados pela Microsoft e ficam acessíveis via Windows
Azure a partir de qualquer lugar no mundo.
4.7 GOOGLE
O Google oferece gratuitamente uma plataforma para desenvolvimento de aplicativos
nas linguagens de programação Python e Java, juntamente com APIs de desenvolvimento.
Trata-se do Google App Engine, classificado no tipo Plataforma como Serviço (PaaS),
fazendo parte do nível de ambiente de software de acordo com a taxonomia definida por
Youseff (2008), no qual os provedores de serviços oferecem um conjunto de APIs para
desenvolvedores, como é o caso do Google. Contudo, há a necessidade de utilizar o BigTable,
o banco de dados do Google e existe uma limitação natural à linguagem de programação e aos
recursos oferecidos por ela (WAYNER, 2008).
5 ESTUDOS DE CASO
Para melhor conduzir o entendimento desta pesquisa, efetuou-se dois estudos de caso,
de modo que se possa avaliar diferentes características de sistemas desenvolvidos para as
nuvens.
5.1 ESTUDO DE CASO 1: FRAMEWORK GOOGLE APP ENGINE
É recente a possibilidade de um desenvolvedor hospedar aplicativos na Web sem
custos ou com ínfimos gastos. Há poucos anos atrás, não era possível dispor de servidores
gratuitamente para hospedagem de páginas pessoais ou aplicações voltadas à Web. Esta é uma
realidade que veio sendo mudada graças ao crescimento do uso da Internet em todo o mundo
e aos investimentos de grandes empresas do ramo de TI, que investiram em servidores e
serviços baseados em navegadores Web.
Um dos fatores que possibilitaram a evolução da Web foram as Redes de Distribuição
de Conteúdo (CDN – Content Delivery Network). Trata-se de um sistema de servidores
distribuídos por todo o mundo, atendendo às solicitações de acordo com a posição física.
Google, Yahoo! e Amazon utilizam CDNs para disponibilizar seus serviços de maneira
eficiente. Porém, para usuários domésticos ou pequenas empresas, esta prática se tornaria
muito cara e, consequentemente, inviável.
O histórico do Google revela uma empresa que sempre teve preocupação com o
desenvolvimento da Web como um todo, implantando algumas mudanças ao longo de uma
década e revolucionando algumas visões antiquadas. O Google é um dos pioneiros em
computação nas nuvens e, como mencionado anteriormente, desenvolveu o Google App
Engine, abrindo a possibilidade de hospedagem de aplicativos em uma plataforma escalável e
gratuita.
O framework do Google é o oposto do oferecido pela Amazon. Enquanto no Amazon
EC2 é possível executar qualquer aplicativo devido à permissão de superusuário, no Google
App Engine não é possível gravar dados em diretório de preferência do usuário, apenas no
banco de dados especificado pelo Google, o chamado BigTable. Contudo, o resultado destas
52
limitações não traz apenas desvantagens. Consultando a documentação do App Engine
percebe-se a abstração de complexidade de programação que o framework oferece e as
restrições de segurança de execução.
O sandbox1 garante que os aplicativos executem somente ações que não interfiram no desempenho e escalabilidade de outros aplicativos. Por exemplo, um aplicativo não pode gravar dados em um sistema de arquivos local ou fazer conexões de rede arbitrárias. Em vez disso, os aplicativos usam serviços escaláveis oferecidos pelo Google App Engine para armazenar dados e se comunicar pela internet. O interpretador de Python emite uma exceção quando o aplicativo tenta importar um módulo da biblioteca padrão que não funciona nas restrições do sandbox. (GOOGLE, 2009)
Recentemente o Google App Engine começou a suportar aplicações na linguagem de
programação Java, que está em fase de testes. A linguagem Python está disponível desde o
lançamento da plataforma, o que significa que grande parte dos aplicativos hoje hospedados
no Google estão escritos em Python.
O aplicativo da Web em Python interage com o servidor da Web do Google App Engine usando o protocolo CGI. Um aplicativo pode usar uma estrutura de aplicativo da Web compatível com WSGI usando um adaptador CGI. O Google App Engine inclui uma estrutura simples de aplicativo da Web, denominada webapp, para facilitar o início do desenvolvimento. No caso de aplicativos maiores, as estruturas de terceiros já desenvolvidas, como Django, funcionam bem com o Google App Engine. O Google App Engine suporta Python 2.5. (GOOGLE, 2009)
5.1.1 Conjunto de APIs
Dentre as APIs (Interface de Programação de Aplicativos) disponíveis para
desenvolvedores do Google App Engine, pode-se destacar algumas (GOOGLE, 2009). A API
de Armazenamento de dados, por exemplo, apresenta sintaxes de chamadas para tarefas
relacionadas a dados, tais como criação, atualização, acesso ou exclusão de entidades.
1 Sandbox: mecanismo de segurança para separar programas em execução concorrente.
53
O armazenamento de dados do Google App Engine armazena e executa consultas sobre objetos de dados conhecidos como entidades. Uma entidade tem uma ou mais propriedades, valores nomeados em um de diversos tipos de dados suportados. (…) O armazenamento de dados pode executar diversas operações em uma única transação e reverter a transação inteira em caso de falha de uma das operações. Isso é particularmente útil para os aplicativos de Web distribuídos, nos quais diversos usuários podem acessar ou manipular o mesmo objeto de dados ao mesmo tempo. (GOOGLE, 2009, grifo nosso)
A API de Mensagens apresenta a sintaxe para chamadas de envio de mensagens por e-
mail, incluindo procedimentos para envio de anexos junto às mensagens. Os aplicativos
podem enviar mensagens de e-mail em nome de administradores do aplicativo e em nome de
usuários com Contas do Google. Os procedimentos de envio de e-mails são padronizados,
efetuando mais de uma tentativa quando algum e-mail não puder ser entregue imediatamente.
A API de Obtenção de URL existe para realizar solicitações HTTP ou HTTPS,
permitindo ao aplicativo comunicar-se ou solicitar recursos de outros hosts disponíveis na
Internet. De acordo com o Google (2009), “o serviço de obtenção de URL usa a infraestrutura
de rede do Google para proporcionar eficiência e escalabilidade.”
A API de Manipulação de imagens dita sintaxes de manipulação de arquivos de
imagens, permitindo redimensionar, girar, inverter e cortar imagens. Oferece também a
possibilidade de aprimoramento de fotografias, fazendo uso de um algoritmo predefinido. “A
API também pode fornecer informações sobre uma imagem, como o formato, a largura, a
altura e um histograma de valores de cores”, como afirmado pelo Google (2009).
A API de Cache de memória apresenta sintaxe para uso de recursos avançados de
memória, uma prática comum em aplicativos escaláveis que busca acelerar consultas comuns
no armazenamento de dados.
A API de Contas de usuário mostra como proceder para colocar o aplicativo sob
autenticação das Contas do Google. Não é obrigatório manter aplicativos sob login das Contas
do Google, podendo o desenvolvedor criar seu próprio sistema de login.
Enquanto um usuário estiver conectado, o aplicativo pode acessar o endereço de e-mail do usuário, além de um ID exclusivo do usuário. O aplicativo também pode detectar se o usuário atual é um administrador, facilitando a implementação de áreas do aplicativo restritas aos administradores. (GOOGLE, 2009)
54
5.1.2 Limitações
Para o uso gratuito do App Engine existem algumas limitações de chamadas a cada
serviço por dia e por minuto estabelecidas pelo Google. É um limite alto para uma aplicação
de poucos acessos ou não muito conhecida, contudo à medida em que o número de usuários
da aplicação cresce, se torna necessário investir em upgrade. Quando tal necessidade surge, é
possível contratar o serviço e obter um maior número de chamadas às funções oferecidas
pelas APIs. As tabelas de limitações de cada recurso oferecido pela plataforma podem ser
conferidas no Anexo A.
5.1.3 Vantagens
O uso da infraestrutura do Google está associado a uma garantia já conhecida de
disponibilidade que é característica dos produtos da empresa. São sistemas de alta
disponibilidade e escalabilidade conhecidos principalmente pelo buscador, cujo qual tornou-se
o sistema de buscas mais utilizado no mundo, apresentando crescimento em relação aos seus
concorrentes no ano de 2008 (SULLIVAN, 2009). Estas evidências aumentam a credibilidade
nos serviços oferecidos pela empresa, incluindo o Google App Engine, especialmente pelo
fato de tratar-se de um sistema com suporte a escalabilidade e alta disponibilidade.
Para lidar com problemas como o grande número de acessos concorrentes e a
possibilidade de algum nodo de seu datacenter apresentar defeitos ou ficar indisponível, o
Google desenvolveu seu próprio sistema de arquivos, conhecido como GFS – Google File
System, a fim de simplificar tarefas de acesso.
Arquivos do Google tendem a ser muito grandes e costumam alcançar vários gigabytes. Cada um desses arquivos contém grandes quantidades de objetos menores. Além do mais, em geral eles são atualizados mais por anexação de dados a um arquivo do que sobrescrevendo partes de um arquivo. Essas observações, junto com o fato de que falhas de servidor são a norma, e não a exceção, resultaram na construção de clusters de servidores. (TANENBAUM, 2007, p. 299-300)
A ocultação de localização dos dados no banco de dados do Google App Engine,
55
abstrai parte da complexidade para o programador, tornando a arquitetura do serviço mais
fechada. Isto é, enquanto a Amazon, por exemplo, oferece serviços separadamente para
armazenagem e processamento implicando em uma tarefa complexa de integração entre eles,
o Google oferece ambos em uma única estrutura integrada.
Esta estrutura está sendo oferecida com suporte a duas linguagens de programação de
ampla utilização: Python e Java. Este fato dá ao programador mais liberdade de escolha,
podendo ele escolher a que melhor oferece suporte as suas necessidades. Seja qual for a
escolha, o Google App Engine oferece ao desenvolvedor um painel de monitoramento de
estatísticas do aplicativo e controle de versões, além de uma série de configurações como
tempo de duração de cookies, migração para domínios próprios e logs de usuários que
efetuaram login no aplicativo, além das atividades desenvolvidas por eles.
5.1.4 Desvantagens
Uma desvantagem clara no uso do App Engine é a quebra de paradigmas, o que exige
aplicações desenvolvidas exclusivamente para este ambiente. Ou seja, a escolha pelo uso
desta infraestrutura implica em “prender-se” a um sistema fechado, com o agravante de que o
administrador do aplicativo não sabe onde seus dados e os dados de seus usuários ficam
armazenados.
Esta ocultação de localização das informações, segundo a ótica do Google, busca
diminuir a complexidade no gerenciamento de um banco de dados distribuído. Contudo, sob a
ótica de algum desenvolvedor cético, pode consistir em desvantagem, uma vez que o Google
torna-se detentor das informações mais importantes pertencentes a clientes do aplicativo.
5.1.5 Tutorial de Desenvolvimento de Aplicativo-exemplo
Para demonstrar os passos de desenvolvimento de um aplicativo para a plataforma
Google App Engine, apresenta-se abaixo um tutorial didático que aborda desde a preparação
do ambiente, criação de um aplicativo de lista de tarefas, até o procedimento de publicação
nos servidores do Google.
56
5.1.5.1 Preparação do ambiente de desenvolvimento
O Google App Engine hospeda aplicativos desenvolvidos nas linguagens Python e
Java. Para este tutorial adotou-se Python na versão 2.6.2, sendo a instalação deste o primeiro
passo para usuários do sistema operacional Windows. Para usuários de Linux e MAC OS X,
basta seguir o próximo passo, uma vez que Python já vem instalado com o sistema
operacional.
O SDK (Software Development Kit) do Google App Engine é o próximo item a ser
instalado e está disponível para download em http://code.google.com/intl/pt-
BR/appengine/downloads.html. Outros itens estão disponíveis na mesma página, tais como
plugin para desenvolvimento utilizando a IDE Eclipse e a documentação completa do SDK.
Para este exemplo, não adotou-se IDE.
5.1.5.2 Criando um novo projeto
A primeira tarefa a realizar é a escolha de um nome para o projeto, o chamado
application id, cujo qual identificará o aplicativo e determinará o endereço para acesso ao
mesmo hospedado sob o domínio do Google. Este nome não deverá conter letras maiúsculas
ou caracteres especiais, apenas letras minúsculas e números. Para este exemplo, utilizou-se o
nome todolist-tcc.
Crie um diretório com o nome especificado para o projeto em qualquer local do
computador. Dentro do diretório do projeto, crie um novo diretório para definição do estilo de
cores do aplicativo, no qual será colocado o arquivo CSS (Cascading Style Sheets). Neste
caso, chamaremos de stylesheets. Crie outros dois diretórios: images para armazenar ícones e
outras imagens que porventura serão utilizadas no projeto e javascript para guardar um
arquivo de execução javascript. Os nomes destes diretórios não necessitam ser exatamente os
utilizados neste exemplo e existe a possibilidade de criação de quantos diretórios forem
necessários.
Neste momento, o projeto deve conter a seguinte estrutura:
57
todolist-tcc/stylesheets/images/javascript/
O próximo passo é a criação dos arquivos correspondentes a cada um dos diretórios
criados. Neste exemplo, vamos criar um arquivo HTML no diretório-raiz do projeto, ou seja,
em todolist-tcc, chamado index.html. Coloque o que desejar neste arquivo, cujo qual será
exibido ao usuário como página principal de seu aplicativo. No diretório stylesheets adicione
um arquivo main.css, que conterá regras de estilo de página. No diretório images coloque
alguma imagem do seu interesse para ser utilizada na aplicação. E, finalmente, no diretório
javascript, adicione um arquivo da biblioteca jQuery (pode-se efetuar download em
http://docs.jquery.com/Downloading_jQuery). No Anexo B é possível visualizar códigos
utilizados em cada um dos arquivos criados neste exemplo.
Após esta etapa, o projeto deverá conter a seguinte estrutura:
todolist-tcc/index.htmlstylesheets/
main.cssimages/
apagar.gifmail.gif
javascript/jquery-1.2.6.min.js
Para informar ao Google App Engine o que fazer com cada um dos arquivos criados e
onde encontrá-los, é necessário criar mais um arquivo, cujo nome deve ser exatamente
app.yaml e sua localização deve ser no diretório-raiz do projeto. O conteúdo deste arquivo,
para este exemplo, deverá ser o seguinte:
application: todolist-tccversion: 1runtime: pythonapi_version: 1
58
handlers:- url: /stylesheets static_dir: stylesheets
- url: /images static_dir: images
- url: /javascript static_dir: javascript
- url: /.* script: todolist-tcc.py
É importante que o nome escrito na primeira linha do arquivo acima especificado seja
exatamente o mesmo escolhido para o projeto, da mesma forma que as indicações de caminho
para os diretórios que contêm o arquivo CSS, as imagens e a biblioteca javascript.
Após a conclusão destes passos, está pronta a aplicação.
5.1.5.3 Testando o projeto
Todo desenvolvedor sabe da importância da realização de testes durante o
desenvolvimento e antes da entrega ao usuário. É também sabido que um sistema nunca está
pronto e que sempre há detalhes a melhorar. Portanto, antes de publicar o projeto nos
servidores do Google, é necessário testá-lo localmente. Para isso é que foi previamente
instalado o SDK do App Engine.
Dentro do diretório do SDK, encontra-se o arquivo dev_appserver.py, um script em
Python usado para simular o App Engine. Para rodar o aplicativo exemplo todolist-tcc, acesse
o terminal de execução de linhas de comando do seu sistema operacional. Usuários de Mac
podem rodar a partir do Terminal; usuários de distribuições Linux podem rodar a partir de
qualquer shell disponível; e usuários de Windows deverão rodá-lo por meio do Prompt de
comandos. Execute o seguinte comando:
dev_appserver.py todolist-tcc
59
Se o terminal exibir as seguintes linhas após a execução deste comando, a aplicação
foi inicializada com sucesso e está acessível por meio de http://localhost:8080.
INFO 2009-10-11 18:46:30,203 dev_appserver_main.py:465] Running application todolist-tcc on port 8080: http://localhost:8080
Utilizando um navegador de preferência do usuário é possível acessar o aplicativo e
testá-lo. A primeira página a ser visualizada pelo usuário será a especificada anteriormente
como index.html. Como a execução é local, o serviço de contas de usuário trabalha de
maneira um pouco diferente, como pode ser visto na Figura 7, permitindo efetuar login sem
possuir uma conta do Google verdadeira, da mesma forma que as funções de envio de
mensagens de e-mail poderão apresentar problemas devido à falta de comunicação com os
servidores do Google. Estes pequenos detalhes passam a funcionar corretamente assim que o
aplicativo for hospedado nos servidores do Google App Engine.
Figura 7 - Login de usuário no modo de simulação local do Google App Engine
Durante os testes é provável que surja a necessidade de efetuar alterações no
aplicativo. Para realizar esta operação, não é necessário parar a execução do simulador do
App Engine. Basta editar os arquivos do projeto e atualizar a página http://localhost:8080 no
navegador para ver os resultados.
É importante observar que, ao executar um aplicativo, o servidor de desenvolvimento
cria um novo arquivo no diretório do projeto, chamado index.yaml. Ele serve para uso
interno do App Engine, podendo ser excluído sem ocasionar nenhum efeito. Porém, na
próxima execução ele será novamente criado.
60
5.1.5.4 Efetuando upload do projeto
O desenvolvedor deve possuir uma conta do Google para publicar seu projeto. Acesse
o endereço http://appserver.google.com, efetue login e aceite os termos e condições de uso.
Depois, clique em Create an Application. No primeiro uso do serviço, será necessário
efetuar uma verificação via SMS, informando um número válido de telefone celular para
recebimento de um código de validação. Este código deve ser digitado no campo requerente.
Cada conta gratuita do Google App Engine oferece espaço de 500MB para seus projetos e o
número máximo de 10 aplicativos por conta.
O próximo passo é verificar a disponibilidade de domínio para seu aplicativo, que
deve ser exatamente o nome escolhido para o projeto. Neste caso, o domínio desejado é
todolist-tcc e deve ser informado no campo Application Indentifier. Clicando em Check
Availability será possível saber se o domínio está disponível ou se será necessário efetuar
mudanças no projeto para adaptá-lo ao novo nome.
Figura 8 - Tela de criação de nova aplicação no Google App Engine
61
Se houver a necessidade de alteração do nome do projeto, o desenvolvedor deve
alterar o nome do diretório do projeto, o nome do arquivo Python principal e mudar alguns
campos do arquivo app.yaml, mais especificamente os correspondentes aos arquivos
renomeados e o campo application.
Após a escolha do nome de domínio para o projeto, preencha o campo Application
Title com qualquer título escolhido para ser exibido como nome principal do aplicativo. Em
seguida, se o aplicativo deverá ficar visível para qualquer usuário de contas do Google, clique
em Save. Caso contrário, para restringir o uso apenas a usuários de determinado domínio
utilizador do Google Apps, clique em Edit e informe o domínio, clicando em Save por fim.
Estes campos podem ser visualizados na Figura 8.
Finalmente, para fazer upload do projeto aos servidores do Google, executa-se o
seguinte comando no terminal, seguido de usuário e senha (da conta Google que o
desenvolvedor decidiu utilizar), quando requisitado:
appcfg.py update todolist-tcc
Figura 9 - Tela de Login do aplicativo-exemplo para Google App Engine
62
Figura 10 - Tela do Painel do Usuário do aplicativo-exemplo para Google App Engine
Para verificar o aplicativo em funcionamento, neste exemplo, basta acessar
http://todolist-tcc.appspot.com. O endereço do aplicativo será sempre o application-
id.appspot.com, onde application-id deve ser substituído pelo nome escolhido para o projeto.
As telas de login e de uso do aplicativo-exemplo podem ser visualizadas nas Figuras 9 e 10,
respectivamente. E ao utilizar o recurso de envio de tarefas por e-mail, o servidor de envio é o
apphosting.bounces.google.com, conforme pode ser visto na Figura 11.
Para efetuar atualizações em um aplicativo, o procedimento é o mesmo de upload. O
Google App Engine verifica a existência de outro projeto com o mesmo nome e, então,
sobrescreve os arquivos antigos pelos novos. Acessando a dashboard do Google App Engine,
o desenvolvedor tem acesso a uma variedade de informações sobre seus projetos, inclusive
versões anteriores.
63
Figura 11 - Exemplo de e-mail enviado através do aplicativo-exemplo
5.1.6 Avaliação dos Resultados
O uso do Google App Engine para desenvolvimento de aplicativos isenta o
programador da preocupação com infraestrutura de execução que atenda ao número de
clientes que farão uso do aplicativo. Como não é possível prever em que momento do dia o
aplicativo possuirá maior número de acessos concorrentes e nem quantos serão estes acessos,
o desenvolvedor precisa criar uma estrutura para suportar um grande número de usuários ao
mesmo tempo, o que muitas vezes exige investimentos em equipamentos que poderão não
consistir em retorno. Em muitos casos, as limitações devido ao custo fazem com que a
infraestrutura possua limitações de acesso, impedindo seu crescimento. O Google efetua
limitações para contas gratuitas, porém oferece a possibilidade de contratação de contas pagas
sem limites de acesso.
O framework, de modo geral, facilita a programação escalável, uma vez que o
desenvolvimento assemelha-se muito ao desktop e Web. Esta característica dá ao
desenvolvedor a liberdade de escolher IDEs e softwares para edição de código-fonte de sua
preferência. Existe já disponível um plugin para facilitar as tarefas de upload e controle de
versões do App Engine para Eclipse.
64
As APIs de desenvolvimento são claras e dão uma certa liberdade ao desenvolvedor,
apesar de o framework ser, de modo geral, um tanto fechado. Não há como saber exatamente
onde ficam armazenados os dados de usuários e nem sequer efetuar backup das informações
contidas no banco de dados do serviço.
Quanto à usabilidade, há uma estreita semelhança com qualquer outro sistema Web.
Para rodar os aplicativos do Google App Engine é necessário possuir um navegador Web com
acesso à Internet e, algumas vezes, uma conta do Google para autenticação e proteção de
informações pessoais. É responsabilidade do desenvolvedor preocupar-se com os paradigmas
ditados pelas heurísticas de usabilidade para softwares e sistemas Web, já que o Google App
Engine não dita padrões nem estabelece interfaces previamente desenvolvidas.
O painel de controle de estatísticas, versões e outras configurações de cada aplicativo é
bastante intuitivo e completo. Oferece gráficos de acesso, logs de erros ocorridos, logs de
acesso e tarefas desempenhadas por usuários, entre outras informações relevantes para
auxiliar na otimização do aplicativo por parte do administrador. É possível também convidar
novos colaboradores para desenvolvimento do aplicativo, alimentando uma ideia de
comunidade.
Concluindo a avaliação, pode-se afirmar que a infraestrutura oferece boas vantagens
em relação a outras soluções do mercado que não possuem módulos gratuitos para
desenvolvedores. Contudo, questões de segurança e detenção de dados ainda podem não
agradar aos mais céticos no momento da escolha do serviço.
5.2 ESTUDO DE CASO 2: PLATAFORMA GOOGLE DOCS
Um exemplo de empresa que possui diversos segmentos na Web é o Google. Além de
e-mail, agenda, bate-papo, sistema de buscas, existe também o Google Docs. Trata-se de uma
suíte de aplicativos para edição de textos, planilhas de cálculo e apresentações de slides que
roda diretamente no navegador e armazena documentos no banco de dados do Google,
tornando-os acessíveis de qualquer lugar com acesso à Internet, a qualquer momento.
Como já mencionado, a confiabilidade dos serviços Google e a preocupação com
constantes melhorias faz da empresa um modelo e uma ótima opção. Devido à importância da
marca, este trabalho efetuou testes de desempenho do sistema Google Docs em relação à
largura da banda de acesso à Internet e quanto ao comportamento da suíte em termos de
65
compatibilidade com as duas principais suítes de aplicativos para escritório desktop:
Microsoft Office e OpenOffice.
Se comparadas, a suíte da Microsoft é utilizada em maior escala, deixando as demais
em grande desvantagem. Para justificar esta afirmação, é possível verificar um gráfico de
volume de buscas no Google para os termos durante os últimos seis anos, na Figura 9.
Figura 12 - Volume de buscas no Google para os termos Google Docs, Microsoft Office e OpenOffice
Fonte: Google Trends
5.2.1 Testes de Desempenho em Relação à Velocidade de Acesso
Foram assumidas seis diferentes velocidades de acesso à Internet, abordando desde
uma velocidade semelhante à de um modem de Internet discada até um link de acesso banda
larga comum em ambientes empresariais. As velocidades foram: 56Kbps, 100Kbps, 400Kbps,
1Mbps, 2Mbps e 6Mbps, dedicados a apenas um microcomputador.
O material utilizado para os testes foram 9 tipos de arquivos, sendo três no formato-
padrão dos aplicativos do Microsoft Office 2003, três do Microsoft Office 2007 e outros três
do OpenOffice 3.1. Cada um deles com características diferentes, tais como tamanho e
quantidade de elementos avançados (tabelas, sumários automáticos, quebras de página,
figuras etc.). Cada um deles está detalhado na Tabela 3.
66
Tabela 3 - Características dos arquivos utilizados para os testes
Formato do Arquivo Tamanho Características
Microsoft Excel 2003 (.xls) 223KBPlanilha de cálculo com várias fórmulas utilizando operações básicas, uma figura e formatações especiais (bordas, títulos, cabeçalhos).
Microsoft PowerPoint 2003 (.ppt) 1,35MB Apresentação com 8 slides, diversas imagens, plano de fundo e vários estilos de formatação.
Microsoft Word 2003 (.doc) 1MBDocumento de texto com 4.153 palavras, 49 páginas, sumário automático, várias quebras de página, tabelas e figuras.
Microsoft Excel 2007 (.xlsx) 93KBPlanilha de cálculo com várias células contendo fórmulas utilizando operações básicas, uma figura e formatações especiais (bordas, títulos, cabeçalhos).
Microsoft PowerPoint 2007 (.pptx) - Não há suporte para este formato no Google Docs.
Microsoft Word 2007 (.docx) 878KBDocumento de texto com 4.153 palavras, 49 páginas, sumário automático, várias quebras de página, tabelas e figuras.
OpenOffice Calc 3.1 (.ods) 18KBPlanilha de cálculo com várias fórmulas utilizando operações básicas e formatações especiais (bordas, títulos, cabeçalhos).
OpenOffice Impress 3.1 (.odp) - Não há suporte para este formato no Google Docs.
OpenOffice Writer 3.1 (.odt) 422KBDocumento de texto com 12.482 palavras, 53 páginas, sumário automático, várias quebras de página, tabelas e figuras.
Os testes foram realizados em dias e horários diferentes, buscando encontrar variações
na banda de acesso em horários de maior e menor utilização da rede mundial, utilizando-se de
estatísticas para obtenção dos valores finais. Em todos os testes, o ambiente utilizado foi um
microcomputador com as seguintes especificações:
AMD Sempron(TM) 2400+
1.66 GHz, 512 MB de RAM
Microsoft Windows XP Professional SP3
Acesso à Internet por meio de link dedicado via Embratel
Os primeiros testes referem-se às variações de tempo de upload, carregamento e
impressão para arquivos de texto. Os gráficos das variações podem ser vistos nas Figuras 13,
14 e 15.
67
Figura 13 - Variação no tempo de upload de documentos de texto
Figura 14 - Variação no tempo de carregamento de documentos de texto
68
Figura 15 - Variação no tempo de impressão de documentos de texto
Na Figura 13 é possível perceber que o tempo de upload é maior para documentos
DOCX. Esta diferença se dá pelo fato de que, documentos do Microsoft Office 2007 possuem
um “novo formato de arquivo com base em XML, chamado Formatos XML Abertos do
Microsoft Office” (MICROSOFT, 2009). Arquivos deste formato “são compactados
automaticamente e, em alguns casos, podem ficar até 75 por cento menores”, de acordo com a
Microsoft (2009). Isto faz com que a conversão para o Google Docs seja mais demorada e,
como o processo de upload engloba também o processo de conversão, existe uma variação
significativa.
Em todos os gráficos relativos a documentos de texto pode-se perceber que, a partir da
marca de 1Mbps, os ganhos são mínimos. Isto permite afirmar que obtém-se o máximo
desempenho, não sendo possível diminuir muito significativamente este tempo, uma vez que
ele refere-se quase que completamente ao tempo de conversão para tarefas de upload e ao
tempo de geração de versão no formato PDF para tarefas de impressão. Outro fator que pode
interferir é a limitação imposta pelo servidor do serviço, neste caso do Google, que pode
estabelecer limites de banda por cliente, o que, quando atingido, não permite obter melhor
resultado no terminal cliente.
Em seguida, foram realizados testes com planilhas de cálculo contendo diversas
69
fórmulas com operações básicas. Os resultados estão disponíveis nas Figuras 16, 17 e 18.
Figura 16 - Variação no tempo de upload de planilhas de cálculo
Figura 17 - Variação no tempo de carregamento de planilhas de cálculo
70
Figura 18 - Variação no tempo de impressão de planilhas de cálculo
Nos testes com planilhas de cálculo há uma significante discrepância em arquivos
ODS em velocidades muito baixas, tanto para upload, quanto para carregamento e impressão.
O formato ODS, assim como o formato XLSX, possui um nível de compressão maior do que
arquivos do Microsoft Excel 2003 (XLS). Isto aumenta o tempo de upload, porque assim
como em documentos de texto, o processo de conversão do arquivo para o formato do Google
Docs é realizado no momento do upload, de maneira transparente ao usuário.
Analisando os gráficos acima exibidos é possível perceber uma grande variação entre
as velocidades mais baixas, diminuindo esta diferença conforme a velocidade de acesso à
Internet aumenta. Novamente, pode-se concluir que o aumento de velocidade implica em
vantagens até determinado limite, não sendo mais viável o aumento de velocidade da
conexão.
E por fim, a intenção foi também realizar testes de desempenho em torno de arquivos
de apresentação de slides. Contudo, a plataforma Google Docs não oferece suporte a arquivos
do tipo ODP e PPTX, sendo os testes, então, realizados apenas com um arquivo do Microsoft
PowerPoint 2003 (PPT). As variações de upload, carregamento e impressão podem ser
visualizadas na Figura 19.
71
Figura 19 - Variação no tempo de tarefas sobre apresentações de slides
Percebe-se que a variação de upload, neste caso, não apresenta considerável diferença.
Já tarefas de carregamento e impressão são bastante variáveis de acordo com a velocidade de
acesso. Como o Google Docs gera arquivos no formato PDF ao efetuar uma solicitação de
impressão, conclui-se que o serviço esconde outra tarefa de conversão dentro de uma tarefa
comum.
Os testes realizados levam ao entendimento de que velocidades muito baixas não são
aconselháveis para um sistema em nuvem, cujo qual tem seu desempenho diretamente
dependente de limitações de acesso à Internet. Por outro lado, o aumento indiscriminado de
links de acesso à Internet pode não ser aconselhável da mesma forma, uma vez que a
limitação ocorre no tempo despendido para execução da tarefa, cujo qual não pode ser
reduzido.
Outro teste realizado em torno da questão desempenho engloba apenas um documento
de texto vazio do Google Docs e visa obter uma projeção da variação do tempo de upload de
um arquivo de imagem (JPEG) de 1,06MB, entre as diferentes velocidades mencionadas
acima. Os resultados de variação no tempo podem ser observados na Figura 20.
72
Figura 20 - Variação no tempo de upload de uma imagem para o Google Docs
O tempo de upload do mesmo arquivo de imagem em diferentes velocidades mostra
novamente que, o aumento de links de acesso à Internet deve obedecer um limite mínimo e é
aconselhável que obedeça também um limite máximo. Efetuando uma análise pela ótica
custo-benefício, o aumento de um link de Internet para valores muito altos, pode não ser
interessante, já que o retorno é mínimo ou nulo.
O último teste realizado em torno da questão de desempenho baseado na plataforma
Google Docs consiste na utilização de três arquivos de texto com o mesmo conteúdo: um
deles ODT, o outro DOC e um terceiro DOCX. Os tamanhos são, respectivamente, 84KB,
362KB e 107KB. O tempo de upload de cada um deles, tarefa que inclui também conversão,
pode ser visualizado na Figura 21.
73
Figura 21 - Tempo de upload e conversão de arquivos de texto com o mesmo conteúdo
5.2.2 Testes de Compatibilidade
Os mesmos arquivos utilizados nos testes de desempenho, detalhados na Tabela 3,
foram avaliados após conversão para a plataforma Google Docs. Os resultados não apontam
bom nível de compatibilidade entre suítes tradicionais desktop e o serviço do Google. Por
exemplo, arquivos de texto perderam recursos importantes como sumário automático (não
atualiza automaticamente), espaçamento entre linhas, imagens, números de página e quebras
de página. Em planilhas de cálculo, algumas fórmulas foram prejudicadas e a disposição das
colunas foi afetada para os três formatos de arquivo utilizados. Estes fatores afetam
diretamente a versão para impressão, que fica igualmente modificada.
Os testes de compatibilidade também abordaram a transferência de alguns elementos
avançados entre planilhas de cálculo e documentos de texto, entre as suítes desktop e a
plataforma Google Docs. Os resultados obtidos podem ser visualizados na Tabela 4.
Em contrapartida, a formatação de documentos totalmente no serviço Google Docs
garante uma melhor experiência ao usuário. A orientação é um pouco diferente das
tradicionais suítes desktop, porém as funções mais comuns podem ser encontradas para os três
editores: Docs, Spreadsheets e Presentations.
74
Tabela 4 - Compatibilidade entre elementos das suítes
Origem Destino Compatível
Planilha de cálculo local Planilha de cálculo remota SimPlanilha de cálculo local Documento de texto remoto SimPlanilha de cálculo remota Planilha de cálculo local NãoPlanilha de cálculo remota Planilha de cálculo remota NãoPlanilha de cálculo remota Documento de texto local NãoPlanilha de cálculo remota Documento de texto remoto NãoFonte: o autor
5.2.3 Avaliação dos Resultados
A adoção de uma suíte de aplicativos para escritório implica, na maioria das vezes, na
necessidade de criação de novos documentos da etapa zero ou, em outros casos, na
necessidade de adaptação de documentos migrados. Esta premissa também é válida para
plataformas em nuvem, uma vez que a abordagem e a infraestrutura mudam para uma
orientação baseada e limitada ao navegador. Porém, recursos adicionais de edição
colaborativa, compartilhamento e portabilidade podem representar vantagens significativas
para determinados segmentos do mercado. Há a necessidade de uma avaliação dos recursos a
serem utilizados, a viabilidade destes e a realização de uma tentativa de migração de maneira
gradativa.
Da mesma forma, se torna necessário avaliar qual é a velocidade ideal para o número
de estações de trabalho em funcionamento na rede da empresa, em busca de uma relação
custo-benefício que melhor atenda às necessidades e não desperdice recursos. Desta maneira,
será possível obter um maior aproveitamento das vantagens econômicas e estruturais de
sistemas em nuvem. No caso do Google Docs, abordado neste capítulo, apesar de algumas
incompatibilidades entre suítes desktop e o serviço do Google, a mobilidade e a inexistência
de custos adicionais para a corporação, podem significar uma alternativa viável.
6 SOLUÇÃO EM NUVEM PARA AMBIENTES CORPORATIVOS
São vários os serviços já existentes no mercado dentro do modelo em nuvem, como
citado anteriormente. Grande parte deles é oferecida gratuitamente, com determinadas
limitações. Contudo, a qualidade de tais serviços não é afetada, sendo eles tão bons quanto
aplicativos desktop, porém com recursos incorporados para suprir problemas de colaboração e
compartilhamento enfrentados em modelos tradicionais.
Este capítulo propõe a associação de algumas ferramentas já citadas neste trabalho,
oferecidas gratuitamente, como opção de ambiente para utilização em estações de trabalho de
ambientes corporativos ou em ambientes domésticos. É sabido que esta proposta não é a única
possível, apenas uma sugestão de ambiente.
6.1 PROPOSTA DE AMBIENTE
O ambiente proposto roda sobre um microcomputador com as seguintes
características:
AMD Sempron(TM) 2400+
1.66 GHz, 512 MB de RAM
Microsoft Windows XP Professional SP3
Acesso à Internet por meio de link de 1Mbps
Os serviços utilizados nesta proposta buscam compor um ambiente que supra a
maioria das necessidades de um ambiente de trabalho de modo generalista, isto é, aplicativos
de uso comum em todos os segmentos corporativos e pessoais serão reunidos em uma solução
que atenda às necessidades básicas. Em casos onde há o uso de ferramentas avançadas para
edição de imagens, vídeos e arquivos de áudio, por exemplo, é imprescindível a adoção de
uma infraestrutura nos moldes do Amazon EC2 para obtenção do desempenho necessário em
tais atividades.
Para a proposta, as seguintes atividades foram atendidas:
76
• Navegação Web: O navegador escolhido é o Google Chrome. O motivo se deve ao
fato de que a engine de funcionamento do Chrome utiliza o modelo de threads, ou
seja, cada aba de navegação é tratada separadamente e uma é independente da outra.
Além disso, é possível criar atalhos de aplicativos Web, assemelhando-os a aplicativos
desktop, facilitando o acesso e aumentando a abstração de localização da infraestrutura
para o usuário.
• Edição de textos, planilhas de cálculo e apresentações de slides: A suíte online
escolhida é o Google Docs pelos mesmos motivos pelos quais foi objeto do estudo de
caso apresentado no capítulo anterior. Trata-se de um serviço de edição de documentos
de texto, planilhas de cálculo e apresentações de slides que oferece diversos recursos
semelhantes às suítes desktop tradicionais, mas possui adicionais de colaboração e
compartilhamento em tempo real.
• Gerenciamento de contatos profissionais: Alguns serviços em computação nas
nuvens para gerenciamento de contatos oferecem seus serviços sob pagamento, sendo
portanto descartados desta proposta. O serviço Google Contacts, integrado aos demais
serviços do Google, oferece uma plataforma completa para edição, gerenciamento e
exportação de contatos.
• Clientes de chat instantâneo: O cliente escolhido para a proposta é o Zoho Chat, um
serviço que é parte da plataforma Zoho, uma infraestrutura em nuvem com diversos
aplicativos para todos os grupos de usuários. O motivo da escolha pelo Zoho Chat é a
integração com Contas do Google, o que evita a necessidade de várias contas de
usuários, e a quantidade de clientes atendida pelo serviço, incluindo MSN Messenger,
Yahoo! Messenger, ICQ, entre outros.
• Cliente de e-mail: O e-mail escolhido foi o Gmail, o qual oferece excelente espaço de
armazenagem, integração com outros serviços, suporte a aplicativos externos e
possibilidade de upgrade de espaço em disco.
• Agendas de compromissos: Integrado ao Gmail, o serviço de agenda de
compromissos do Google, o Calendar, permite a criação de inúmeras agendas para
melhor organizar eventos, além de compartilhamento de informações e suporte à
disponibilização de versões públicas.
• Lista de tarefas: A lista de tarefas utilizada na proposta é a desenvolvida para o
Google App Engine no capítulo 5, cuja qual também utiliza login com Contas do
Google e uma interface simples para adição de pequenas tarefas individuais.
77
• Gerenciador de projetos: O sistema escolhido foi o Zoho Projects, que oferece um
ambiente de gerenciamento e compartilhamento de projetos, o qual pode ser útil para
criação de projetos dentro do meio corporativo, incluindo a possibilidade de
colaboração entre membros da empresa.
• Rede social: O serviço LinkedIn é sugerido para relacionamentos profissionais. Trata-
se de um adicional à proposta, um serviço já bem aceito por empresas para alavancar
seus negócios e interagir com clientes e outras empresas.
Figura 22 - Área de trabalho e barra de inicialização rápida com atalhos de aplicativos remotos apresentados de forma semelhante a aplicativos desktop tradicionais
A preocupação na formulação deste ambiente leva em conta limitações de hardware
locais, orientação ao usuário e tarefas voltadas para a Web, armazenamento de dados
remotamente e a ocultação de localização para o usuário. Com o uso de atalhos semelhantes
aos de aplicativos desktop tradicionais, há uma abstração de localização para o usuário, que
78
por sua vez, não deverá perceber diferenças muito grandes na execução de um aplicativo. A
Figura 22 mostra como ficariam organizados os elementos na Área de trabalho do ambiente
utilizado na proposta.
É possível observar também na Figura 22, a disposição dos elementos na barra de
inicialização rápida, ao lado do menu Iniciar, apresentando atalhos para os mesmos
aplicativos com ícones significativos e intuitivos. Outra localização de atalhos para o usuário
neste ambiente é dentro do menu Iniciar, como pode ser visualizado na Figura 23.
Figura 23 - Menu Iniciar com atalhos de aplicativos remotos apresentados de forma semelhante a aplicativos desktop
tradicionais
Cada um dos aplicativos utilizados neste ambiente sugerido, ao ser acessado pelo
usuário, é apresentado como um aplicativo, fugindo um pouco da ideia de apresentação de
páginas Web, graças a um recurso do Chrome onde o tratamento de aplicativos remotos é tido
como aplicações desktop. Exemplos desta apresentação ao usuário podem ser vistos nas
Figuras 24 a 31, onde é possível perceber a inexistência de barra de endereços, barra de
favoritos, entre outros elementos comuns a navegadores Web.
79
Figura 24 - Google Contacts apresentado de maneira semelhante a um aplicativo desktop
Figura 25 - Google Docs apresentado de maneira semelhante a um aplicativo desktop
80
Figura 26 - Zoho Projects apresentado de maneira semelhante a um aplicativo desktop
Figura 27 - Gmail apresentado de maneira semelhante a um aplicativo desktop
81
Figura 28 - LinkedIn apresentado de maneira semelhante a um aplicativo desktop
Figura 29 - Google Calendar apresentado de maneira semelhante a um aplicativo desktop
82
Figura 30 - To Do List apresentado de maneira semelhante a um aplicativo desktop
Figura 31 - Zoho Chat apresentado de maneira semelhante a um aplicativo desktop
83
O uso de uma abordagem em nuvem como a sugerida pode representar um melhor
aproveitamento de recursos de hardware obsoletos ou limitados, sem a necessidade de
investimento na aquisição de recursos novos. Este modelo também prioriza o
compartilhamento e a colaboração online entre duas ou mais pessoas, o que agiliza o processo
de troca de informações, não afetando a maneira como o usuário interage com tais aplicativos.
Vale ressaltar que a proposta apresentada não é única, uma vez que um sistema em
nuvem deve ser inteiramente customizável, adaptando-se às necessidades do usuário. Esta
proposta classifica-se como Software como Serviço (SaaS), uma vez que cada serviço é
independente do outro e todos eles comportam-se como softwares, capazes de trocar
informações entre eles.
6.2 SISTEMA TRADICIONAL X SOLUÇÃO EM NUVEM
Comparando o dominante e já bem conhecido sistema tradicional e uma abordagem
em nuvem é possível ressaltar algumas vantagens no uso do segundo modelo, tais como:
• colaboração em evidência;
• compartilhamento de informações facilitado;
• reaproveitamento de recursos obsoletos de hardware;
• diminuição da preocupação com servidores e consequente redução no consumo de
energia elétrica e com pessoal;
• eliminação da preocupação com backups de rotina;
• substituição e migração de estações de trabalho facilitadas;
• ampliação de número de estações de trabalho facilitada;
• integração entre serviços em evidência;
• sistemas sempre atualizados sem perda de tempo ou de informações;
• acesso a informações de dispositivos móveis, em qualquer lugar do mundo com acesso
à Internet.
CONCLUSÃO
Sistemas distribuídos têm como principal objetivo o ganho de desempenho na
associação de microprocessadores de maneira que seja possível dividir tarefas e processá-las
separadamente, promovendo paralelismo e encurtando o tempo de realização de tarefas de
processamento pesado. Após os clusters e grids, há poucos anos, surgiu a computação nas
nuvens, um novo modelo que visa reduzir principalmente os custos com tecnologia da
informação em ambientes corporativos.
A computação nas nuvens resgata a ideia antiga de cliente-servidor com pequenas
alterações. Neste novo modelo, o cliente realiza parte do processamento localmente e depende
de um servidor para um maior número de tarefas. Mais além, o cliente também depende do
servidor para armazenamento de dados e aplicações, os quais ficam localizados em servidores
fora das dependências da empresa, muitas vezes em áreas geográficas desconhecidas. Devido
a esta característica é que o nome computação nas nuvens foi adotado.
Entre as principais vantagens estão a facilitação da colaboração entre dois ou mais
usuários, o compartilhamento como item em evidência, a portabilidade e a redução de custos
com renovação de infraestrutura de TI. Em contrapartida, algumas preocupações ainda
consistem em desvantagens para o modelo, como questões de segurança no tráfego de dados
confidenciais via Internet e a dependência total de um link de acesso à Internet, cujo qual pode
ser interrompido a qualquer instante.
A solução ideal pode ser obtida com a contratação de serviços pagos de computação
nas nuvens, de acordo com a necessidade do usuário. Todos os sistemas são customizáveis e
se adaptam às exigências do modelo de negócio. Dentre os principais provedores, pode-se
citar IBM, Sun e Amazon. Cada um oferece uma ou mais soluções que podem ser
classificadas em tipos de acordo com a forma de entrega de serviços.
Para todos os tipos de computação nas nuvens, uma importante característica
prevalece: a redução do consumo de energia elétrica e, consequentemente, a redução na
emissão de poluentes na atmosfera. Esta é mais uma questão importante e alvo de muita
discussão, uma vez que o contexto atual sugere atitudes “verdes”. Uma vez desnecessária a
existência de servidores subutilizados nas dependências da empresa e a transferência de
processamento para servidores compartilhados entre diversos usuários ao redor do mundo, um
85
melhor aproveitamento é, por consequência, obtido.
Outro importante fator a ser citado é o desenvolvimento. Para um programador, o
desenvolvimento de aplicativos para as nuvens não foge muito dos padrões Web. Existem as
limitações impostas pelas linguagens, mas na maioria dos casos, provedores de computação
nas nuvens abstraem complexidades de banco de dados distribuído e implementação de
escalabilidade com o uso de APIs bem definidas. Isto permite que o desenvolvedor preocupe-
se com o aplicativo e seu funcionamento em si, esquecendo detalhes de hospedagem,
planejamento de crescimento ou armazenagem, como pôde ser comprovado com o estudo de
caso em torno da plataforma Google App Engine. O desenvolvimento utiliza a linguagem
Python e o framework disponibilizado pelo Google, o qual oferece espaço em seus servidores
gratuitamente para hospedagem de aplicativos e auxilia no monitoramento de estatísticas e
logs de acesso. O conjunto de vantagens apresentado no estudo de caso leva à conclusão de
que é recomendável o uso do Google App Engine para aplicações simples e não-críticas em
termos de segurança.
O segundo estudo de caso apresentou resultados em termos de compatibilidade e
desempenho da plataforma em nuvem Google Docs. Durante esse, foi realizada uma coleta de
dados em relação ao tempo de tarefas de upload, carregamento e impressão de documentos de
texto, planilhas de cálculo e apresentações de slides com diferentes tipos de arquivos,
condicionados a diferentes velocidades de acesso e em variados horários do dia. Os resultados
obtidos deixam clara a necessidade de investimento em aumento de links de acesso à Internet
de modo a obter uma relação custo/benefício aceitável, pois com o uso de velocidades muito
baixas há uma clara perda de desempenho. Por outro lado, um aumento indiscriminado de
velocidade do link pode ocasionar desperdícios, pois a banda ficará subutilizada. Contudo, o
uso de velocidades muito baixas pode comprometer o desempenho das aplicações, as quais
são extremamente dependentes desta banda. De uma maneira geral, ainda há grande
dificuldade quanto à compatibilidade de software entre sistemas desktop tradicionais e
sistemas em nuvem, o que dificulta a migração de dados para adoção do modelo. Entretanto,
fatores positivos como a colaboração e o compartilhamento de dados e documentos são
evidentes e podem representar benefícios substanciais.
Para concluir, pode-se afirmar que a adoção de modelos computacionais distribuídos
em nuvem ainda deverá levar alguns anos para atingir o amadurecimento completo, de modo
que possam se tornar de fato viáveis. Também dependerão do investimento de provedores em
técnicas de aumento de segurança da informação para suas infraestruturas, bem como em
86
melhorias de compatibilidade entre sistemas tradicionais e baseados em nuvem, facilitando
assim a migração de um ambiente para o outro, respectivamente.
REFERÊNCIAS
AKITA, Fabio. Google App Engine e Cloud Computing. Disponível em: <http://www.akitaonrails.com/2008/4/13/off-topic-google-app-engine-e-cloud-computing> Acesso em: 5 Nov 2009.
AMAZON. Amazon CloudFront. Disponível em: <http://aws.amazon.com/cloudfront/> Acesso em: 12 Out 2009.
AMAZON. Amazon Elastic Compute Cloud (Amazon EC2). Disponível em: <http://aws.amazon.com/ec2/> Acesso em: 12 Out 2009.
AMAZON. Amazon Elastic MapReduce. Disponível em: <http://aws.amazon.com/elasticmapreduce/> Acesso em: 12 Out 2009.
AMAZON. Amazon Simple Storage Service (Amazon S3). Disponível em: <http://aws.amazon.com/s3/> Acesso em: 12 Out 2009.
AMAZON. Amazon SimpleDB. Disponível em: <http://aws.amazon.com/simpledb/> Acesso em: 12 Out 2009.
AMAZON. Amazon Virtual Private Cloud (Amazon VPC). Disponível em: <http://aws.amazon.com/vpc/> Acesso em: 12 Out 2009.
BALDING, Craig. Cloud Computing Defined. Cloud Security. Disponível em: <http://cloudsecurity.org/2008/04/17/cloud-computing-defined-1/> Acesso em: 21 Maio 2009.
BARROS, Fabio. A Nuvem e suas Diferentes Formas. Computer World. v.16, n.507, p. 26-27, Dez. 2008.
BECHTOLSHEIM, Andy. Cloud Computing. Disponível em: <http://netseminar.stanford.edu/seminars/Cloud.pdf> Acesso em: 02 Set 2009.
BUTRICO, Maria; SILVA, Dilma Da; YOUSEFF, Lamia. Toward a Unified Ontology of Cloud Computing. Disponível em: <http://www.cs.ucsb.edu/~lyouseff/CCOntology/CloudOntology.pdf> Acesso em: 19 Jul 2009.
DANTAS, Mario. Computação Distribuída de Alto Desempenho: redes, clusters e grids computacionais. Rio de Janeiro: Axcel Books do Brasil, 2005.
DEITEL, Harvey M.; DEITEL, Paul J.; CHOFFNES, David R. Sistemas Operacionais. 3. ed. São Paulo: Pearson Prentice Hall, 2005.
88
EUCALYPTUS. Eucalyptus. Disponível em: <http://open.eucalyptus.com/> Acesso em: 2 Nov 2009.
FINGAR, Peter. Dot Cloud: The 21st Century Business Platform Built on Cloud Computing. Tampa, Florida, USA: Meghan-Kiffer Press, 2009.
GOOGLE. Google App Engine: Cotas. Disponível em: <http://code.google.com/intl/pt-BR/appengine/docs/quotas.html> Acesso em: 4 Out 2009.
GOOGLE. O que é o Google App Engine? Disponível em: <http://code.google.com/intl/pt-BR/appengine/docs/whatisgoogleappengine.html> Acesso em: 18 Maio 2009.
IBM. Cloud Computing. Disponível em: <http://www.ibm.com/ibm/cloud/> Acesso em: 29 Mar 2009.
IBM. DeveloperWorks Spaces. Disponível em: <http://www.ibm.com/developerworks/spaces/cloud?S_TACT=saasisv&ca=dth-cloud#moretags> Acesso em: 3 Nov 2009.
KUROSE, James F. ROSS, Keith W. Redes de computadores e a Internet. 3. ed. São Paulo: Pearson Addison Wesley, 2006.
LEAVITT, Neal. Is Cloud Computing Really Ready for Prime Time? Technology News. Disponível em: <http://www.computer.org/portal/cms_docs_computer/ computer/homepage/Jan09/r1tech.pdf> Acesso em: 2 Abr 2009.
MICROSOFT. Introdução a novas extensões de nome de arquivo e formatos XML abertos. Microsoft Office Online. Disponível em: <http://office.microsoft.com/pt-br/powerpoint/HA100069351046.aspx> Acesso em: 09 Nov 2009.
MICROSOFT. Windows Azure. Disponível em: <http://www.microsoft.com/windowsazure/windowsazure/> Acesso em: 4 Nov 2009.
MILLER, Michael. Cloud Computing: Web-Based Applications That Change the Way You Work and Collaborate Online. Indianapolis, Indiana: Que, 2008.
REESE, George. The Economics of Cloud Computing. O'Reilly Broadcast. Disponível em: <http://broadcast.oreilly.com/print/33903.html> Acesso em: 12 Set 2009.
RIGGOTT, Matt. Using Google App Engine as Your Own Content Delivery Network. Disponível em: <http://24ways.org/2008/using-google-app-engine-as-your-own-cdn> Acesso em: 16 Out 2009.
SHIMONSKI, Robert J. Network+: Study Guide and Practice Exams. Rockland, MA: Syngress Publishing, 2005.
SULLIVAN, Danny. Search Market Share 2008: Google Grew, Yahoo & Microsoft Dropped & Stabilized. Disponível em: <http://searchengineland.com/search-market-share-2008-google-grew-yahoo-microsoft-dropped-stabilized-16310> Acesso em: 5 Nov 2009.
89
SUN. Project Kenai: The APIs for the Sun Cloud. Disponível em: <http://kenai.com/projects/suncloudapis> Acesso em: 31 Out 2009.
SUN. Sun Microsystems anuncia plataforma aberta de Cloud Computing. Disponível em: <http://br.sun.com/sunnews/press/2009/20090324.jsp> Acesso em: 28 Out 2009.
TANENBAUM, Andrew S. Redes de Computadores. 4. ed. Rio de Janeiro: Elsevier, 2003.
TANENBAUM, Andrew S.; STEEN, Marteen Van. Sistemas distribuídos: princípios e paradigmas. 2. ed. São Paulo: Pearson Prentice Hall, 2007.
WAYNER, Peter. Cloud versus cloud: A guided tour of Amazon, Google, AppNexus, and GoGrid. InfoWorld. Disponível em: <http://www.infoworld.com/d/cloud-computing/cloud-versus-cloud-guided-tour-amazon-google-appnexus-and-gogrid-122> Acesso em: 23 Jul 2009.
WILLIS, John. Cloud Computing and the Enterprise. IT Management and Cloud Blog. Disponível em: <http://www.johnmwillis.com/cloud-computing/cloud-computing-and-the-enterprise/> Acesso em: 21 Maio 2009.
ANEXOS
91
ANEXO A – Limitações do Google App Engine
Tabela A.1 – Solicitações
Recurso Cota padrão gratuita Cota com faturamento ativado
Limite diário Taxa máxima Limite diário Taxa máxima
Solicitações 1.300.000 solicitações
7.400 solicitações/minuto
43.000.000 solicitações
30.000 solicitações/minuto
Largura de banda de saída (faturável, inclui HTTPS)
10 gigabytes 56 megabytes/minuto
10 gigabytes gratuito; máximo de 1.046 gigabytes
740 megabytes/minuto
Largura de banda de entrada (faturável, inclui HTTPS)
10 gigabytes 56 megabytes/minuto
10 gigabytes gratuito; máximo de 1.046 gigabytes
740 megabytes/minuto
Tempo de CPU (faturável)
46 horas de CPU 15 minutos de CPU/minuto
46 horas de CPU gratuito, máximo de 1.729 horas de CPU
72 minutos de CPU/minuto
Tabela A.2 – Armazenamento de dados
Recurso Cota padrão gratuita Cota com faturamento ativado
Limite diário Taxa máxima Limite diário Taxa máxima
Chamadas da API de armazenamento de dados
10.000.000 chamadas
57.000 chamadas/minuto
140.000.000 chamadas
129.000 chamadas/minuto
Dados armazenados (faturável)
1 gigabyte Nenhum 1 gigabytes gratuito; sem máximo
Nenhum
Dados enviados à API 12 gigabytes 68 megabytes/minuto
72 gigabytes 153 megabytes/minuto
Dados recebidos da API
115 gigabytes 659 megabytes/minuto
695 gigabytes 1.484 megabytes/minuto
Tempo de CPU do armazenamento de dados
60 horas de CPU 20 minutos de CPU/minuto
1.200 horas de CPU 50 minutos de CPU/minuto
92
Tabela A.3 – Mensagens
Recurso Cota padrão gratuita Cota com faturamento ativado
Limite diário Taxa máxima Limite diário Taxa máxima
Chamadas da API de mensagens
7.000 chamadas 32 chamadas/minuto
1.700.000 chamadas 4.900 chamadas/minuto
Destinatários de e-mail (faturável)
2.000 destinatários 8 destinatários/minuto
2.000 destinatários gratuito; máximo de 7.400.000 destinatários
5.100 destinatários/minuto
E-mail para administradores
5.000 e-mails 24 e-mails/minuto 3.000.000 e-mails 9.700 e-mails/minuto
Dados enviados no corpo da mensagem
60 megabytes 340 kilobytes/minuto
29 gigabytes 84 megabytes/minuto
Anexos enviados 2.000 anexos 8 anexos/minuto 2.900.000 anexos 8.100 anexos/minuto
Dados enviados como anexos
100 megabytes 560 kilobytes/minuto
100 gigabytes 300 megabytes/minuto
Tabela A.4 – Obtenção de URL
Recurso Cota padrão gratuita Cota com faturamento ativado
Limite diário Taxa máxima Limite diário Taxa máxima
Chamadas da API de obtenção de URL
657.000 chamadas 3.000 chamadas/minuto
46.000.000 chamadas
32.000 chamadas/minuto
Dados enviados para a obtenção de URL
4 gigabytes 22 megabytes/minuto
1.046 gigabytes 740 megabytes/minuto
Dados recebidos da obtenção de URL
4 gigabytes 22 megabytes/minuto
1.046 gigabytes 740 megabytes/minuto
Tabela A.5 – Manipulação de imagens
Recurso Cota padrão gratuita Cota com faturamento ativado
Limite diário Taxa máxima Limite diário Taxa máxima
Chamadas da API de manipulação de imagens
864.000 chamadas 4.800 chamadas/minuto
45.000.000 chamadas
31.000 chamadas/minuto
Dados enviados à API 1 gigabytes 5 megabytes/minuto 560 gigabytes 400 megabytes/minuto
Dados recebidos da API
5 gigabytes 28 megabytes/minuto
427 gigabytes 300 megabytes/minuto
Transformações executadas
2.500.000 transformações
14.000 transformações/minuto
47.000.000 transformações
32.000 transformações/minuto
93
Tabela A.6 – Cache de memória
Recurso Cota padrão gratuita Cota com faturamento ativado
Limite diário Taxa máxima Limite diário Taxa máxima
Chamadas da API do cache de memória
8,600,000 48.000 chamadas/minuto
96,000,000 108.000 chamadas/minuto
Dados enviados à API 10 gigabytes 56 megabytes/minuto
60 gigabytes 128 megabytes/minuto
Dados recebidos da API
50 gigabytes 284 megabytes/minuto
315 gigabytes 640 megabytes/minuto
94
ANEXO B – Código-fonte do aplicativo-exemplo para Google App Engine
app.yamlapplication: todolist-tccversion: 1runtime: pythonapi_version: 1
handlers:- url: /stylesheets static_dir: stylesheets
- url: /images static_dir: images
- url: /javascript static_dir: javascript
- url: /.* script: todolist-tcc.py
- url: /visualiza/.* script: visualiza.py
index.yamlindexes:
# AUTOGENERATED
# This index.yaml is automatically updated whenever the dev_appserver# detects that a new type of query is run. If you want to manage the# index.yaml file manually, remove the above marker line (the line# saying "# AUTOGENERATED"). If you want to manage some indexes# manually, move them above the marker line. The index.yaml file is# automatically uploaded to the admin console when you next deploy# your application using appcfg.py.
# Unused in query history -- copied from input.- kind: Usuario properties: - name: nome - name: categoria - name: date direction: desc
# Used 18 times in query history.
95
- kind: Usuario properties: - name: nome - name: categoria direction: desc - name: date direction: desc
# Unused in query history -- copied from input.- kind: Usuario properties: - name: nome - name: date direction: desc
index.html<html> <head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1"> <link type="text/css" rel="stylesheet" href="/stylesheets/main.css" /> <script src="/javascript/jquery-1.2.6.min.js" type="text/javascript"></script>
<title> TO DO LIST </title> </head>
<body> <ul>
{% if user %}Bem vindo ao <b>ToDoList</b>. Você está logado
como: <b> {{user}} </b>|{% endif %}<a href="{{ url }}">{{ url_linktext }}</a>
</ul>
<ul>{% if user %}
<table border="3" width=100% ><tr VALIGN=TOP><td width=565><h2>Nova tarefa:</h2>
<li> <form action="/toDoList" method="post">
<label>Tarefa: </label><br><input type="text" name="tarefa" size="80">
<br><label>Descrição: </label><br>
96
<div><textarea name="descricao" rows="3" cols="77"></textarea>
<br><label>Data Início: </label><br><input type="text"
name="dateInicio" size="10"><br><label>Data Término: </label><br><input type="text"
name="dateTermino" size="10"><br><label>Prioridade: </label><br><font color=black size="3" face="Arial">
<input type="radio" name=categoria value="1">1<input type="radio" name=categoria value="2">2<input type="radio" name=categoria value="3"
checked>3<input type="radio" name=categoria value="4">4<input type="radio" name=categoria value="5">5
</font><br><br><div><input type="submit" value="Incluir"></div>
</form> </td>
<td> <h2>Tarefas pendentes: {{tarefas}}</h2>
{% for usuario in usuarios %}{% if usuario.nome %}<li><label>Tarefa: </label> <font color=black size="3"
face="Arial"> {{ usuario.tarefa|escape }} </font><br><label>Descrição: </label> <font color=black
size="3" face="Arial"> {{ usuario.descricao|escape }}</font><br><label>Data Início: </label> <font color=black
size="3" face="Arial"> {{ usuario.dateInicio|escape }} </font><label>Data Término: </label> <font color=black
size="3" face="Arial"> {{ usuario.dateTermino|escape }} </font><br><label>Prioridade: </label> <font color=black size="3"
face="Arial"> {{ usuario.categoria|escape }} </font><br> <a class="done" href="/apaga?id={{usuario.key.id}}" ><img
border="0" src="/images/apagar.gif"></a><a class="email" href="/email?id={{usuario.key.id}}" ><img
border="0" src="/images/mail.gif"></a> {% else %} {% endif %}{% endfor %}
</td>
</tr>
97
</table> </ul>{% else %}
<h2> Efetue login com sua Conta do Google para criar e visualizar suas listas de tarefas. </h2>
{% endif %}</ul>
</table>
<center> <img src="http://code.google.com/appengine/images/appengine-silver-120x30.gif" alt="Powered by Google App Engine" /></center>
</body></html>
todolist-tcc.pyimport cgiimport os
from google.appengine.ext.webapp import templatefrom google.appengine.api import usersfrom google.appengine.ext import webappfrom google.appengine.ext.webapp.util import run_wsgi_appfrom google.appengine.ext import dbfrom google.appengine.api import mail
class Usuario(db.Model): nome = db.UserProperty() tarefa = db.StringProperty() descricao = db.StringProperty(multiline=True) date = db.DateTimeProperty(auto_now_add=True) dateInicio = db.StringProperty() dateTermino = db.StringProperty() categoria = db.StringProperty()
class ToDoList(webapp.RequestHandler): def post(self): usuario = Usuario()
if users.get_current_user(): usuario.nome = users.get_current_user()
usuario.tarefa = self.request.get('tarefa') usuario.descricao = self.request.get('descricao') usuario.dateInicio = self.request.get('dateInicio') usuario.dateTermino = self.request.get('dateTermino') usuario.categoria = self.request.get('categoria')
98
usuario.put()
self.redirect('/')
class Email(webapp.RequestHandler): def get(self): user = users.get_current_user() if user: raw_id = self.request.get('id') id = int(raw_id) usuario = Usuario.get_by_id(id) message = mail.EmailMessage(sender=user.email(), subject = usuario.tarefa ) message.to = user.email() message.body = usuario.descricao message.send() self.redirect('/')
class Apaga(webapp.RequestHandler): def get(self): user = users.get_current_user() if user: raw_id = self.request.get('id') id = int(raw_id) usuario = Usuario.get_by_id(id) usuario.delete() self.redirect('/')
class MainPage(webapp.RequestHandler): def get(self): consulta_usuario = Usuario.gql("WHERE nome = :1 ORDER BY categoria desc, date DESC", users.get_current_user()) usuarios = consulta_usuario.fetch(100) user = users.get_current_user() if users.get_current_user(): url = users.create_logout_url(self.request.uri) url_linktext = " Sair " else: url = users.create_login_url(self.request.uri) url_linktext = ' Fazer Login '
template_values = { 'usuarios': usuarios, 'user': user, 'tarefas': consulta_usuario.count(), 'url': url, 'url_linktext': url_linktext, }
99
path = os.path.join(os.path.dirname(__file__), 'index.html') self.response.out.write(template.render(path, template_values))
application = webapp.WSGIApplication( [('/', MainPage), ('/toDoList', ToDoList), ('/apaga', Apaga), ('/email', Email)], debug=True)
def main(): run_wsgi_app(application)
if __name__ == "__main__": main()
main.cssbody { font-family: arial; background-color: MediumTurquoise; margin-left: 10pt;}span { background:#def3ca; padding:3px; float:left; }h1{ color: red;}h2{ color: DarkSlateGray;}label{font-weight: bold;
color: RoyalBlue;} textarea{ font-family: arial; font-size: 10pt;} input{ font-family: arial; font-size: 10pt;} UL { background: Azure;
100
margin: 12px 12px 12px 12px; padding: 3px 3px 3px 3px; }LI { color: white; background: PowderBlue; margin: 12px 12px 12px 12px; padding: 12px 0px 12px 12px; list-style: none }
101
ANEXO C – Tabela de Dados Coletados nos Testes com Google Docs