Trabalho de Conclusão de Curso de Graduação
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Trabalho de Conclusão de Curso de Graduação

  • 28,317 views
Uploaded on

TCC que propiciou a conclusão da graduação em Ciência da Computação.

TCC que propiciou a conclusão da graduação em Ciência da Computação.

More in: Education , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
28,317
On Slideshare
28,310
From Embeds
7
Number of Embeds
3

Actions

Shares
Downloads
969
Comments
2
Likes
6

Embeds 7

http://www.linkedin.com 5
http://www.lmodules.com 1
http://www.techgig.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 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
  • 2. 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
  • 3. 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.
  • 4. "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." Antoine de Saint-Exupery
  • 5. 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.
  • 6. 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.
  • 7. LISTA DE FIGURAS Figura 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
  • 8. 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
  • 9. 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
  • 10. 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
  • 11. 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
  • 12. SUMÁRIO 1 INTRODUÇÃO....................................................................................................................13 2 SISTEMAS DISTRIBUÍDOS.............................................................................................15 2.1 METAS...............................................................................................................................16 2.1.1 Acesso a recursos............................................................................................................16 2.1.2 Transparência da distribuição......................................................................................17 2.1.3 Abertura..........................................................................................................................18 2.2 REDES DE INTERCONEXÃO.........................................................................................19 2.2.1 Organização das Redes..................................................................................................20 2.2.2 Tipos de Redes................................................................................................................20 2.2.3 Protocolos de Rede.........................................................................................................21 2.2.3.1 Modelo de referência OSI.............................................................................................22 2.2.3.2 Protocolo TCP/IP..........................................................................................................23 2.2.4 Segurança em Redes......................................................................................................24 2.3 ESCALABILIDADE..........................................................................................................25 2.4 SISTEMAS DE COMPUTAÇÃO DISTRIBUÍDOS..........................................................26 3 COMPUTAÇÃO NAS NUVENS........................................................................................30 3.1 CONCEITUAÇÃO.............................................................................................................30 3.2 CARACTERÍSTICAS........................................................................................................31 3.3 MODELOS DE SERVIÇO.................................................................................................32 3.3.1 Nível de Aplicação..........................................................................................................33 3.3.2 Nível de Ambiente de Software.....................................................................................33 3.3.3 Nível de Infraestrutura de Software.............................................................................34 3.3.4 Nível de Kernel de Software..........................................................................................36 3.3.5 Nível de Hardware e Firmware.....................................................................................37 3.4 ECONOMIA.......................................................................................................................38 3.5 APLICAÇÕES E PÚBLICO-ALVO...................................................................................40 3.5.1 Usuários Domésticos......................................................................................................41 3.5.2 Comunidades e Grupos.................................................................................................42 3.5.3 Corporações....................................................................................................................42 4 PROVEDORES DE SERVIÇOS EM NUVEM................................................................44 4.1 AMAZON WEB SERVICES..............................................................................................44 4.1.1 Amazon Elastic Compute Cloud (Amazon EC2)........................................................44 4.1.2 Amazon SimpleDB.........................................................................................................45 4.1.3 Amazon Simple Storage Service (Amazon S3)............................................................45 4.1.4 Amazon CloudFront.......................................................................................................45 4.1.5 Amazon Elastic MapReduce.........................................................................................46 4.1.6 Amazon Virtual Private Cloud (Amazon VPC)...........................................................46 4.2 SUN.....................................................................................................................................46 4.3 IBM.....................................................................................................................................47 4.4 EUCALYPTUS...................................................................................................................48
  • 13. 4.5 VMWARE...........................................................................................................................48 4.5.1 VMware vCloud.............................................................................................................48 4.5.2 VMware vSphere............................................................................................................49 4.6 MICROSOFT......................................................................................................................50 4.7 GOOGLE............................................................................................................................50 5 ESTUDOS DE CASO..........................................................................................................51 5.1 ESTUDO DE CASO 1: FRAMEWORK GOOGLE APP ENGINE....................................51 5.1.1 Conjunto de APIs...........................................................................................................52 5.1.2 Limitações.......................................................................................................................54 5.1.3 Vantagens........................................................................................................................54 5.1.4 Desvantagens..................................................................................................................55 5.1.5 Tutorial de Desenvolvimento de Aplicativo-exemplo..................................................55 5.1.5.1 Preparação do ambiente de desenvolvimento...............................................................56 5.1.5.2 Criando um novo projeto..............................................................................................56 5.1.5.3 Testando o projeto.........................................................................................................58 5.1.5.4 Efetuando upload do projeto.........................................................................................60 5.1.6 Avaliação dos Resultados...............................................................................................63 5.2 ESTUDO DE CASO 2: PLATAFORMA GOOGLE DOCS...............................................64 5.2.1 Testes de Desempenho em Relação à Velocidade de Acesso.......................................65 5.2.2 Testes de Compatibilidade.............................................................................................73 5.2.3 Avaliação dos Resultados...............................................................................................74 6 SOLUÇÃO EM NUVEM PARA AMBIENTES CORPORATIVOS...............................75 6.1 PROPOSTA DE AMBIENTE.............................................................................................75 6.2 SISTEMA TRADICIONAL X SOLUÇÃO EM NUVEM.................................................83 CONCLUSÃO.........................................................................................................................84 REFERÊNCIAS......................................................................................................................87 ANEXOS..................................................................................................................................90 ANEXO A – Limitações do Google App Engine......................................................................91 ANEXO B – Código-fonte do aplicativo-exemplo para Google App Engine..........................94 ANEXO C – Tabela de Dados Coletados nos Testes com Google Docs................................101
  • 14. 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
  • 15. 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.
  • 16. 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
  • 17. 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.
  • 18. 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
  • 19. 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
  • 20. 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.
  • 21. 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
  • 22. 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
  • 23. 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
  • 24. 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.
  • 25. 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.
  • 26. 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.
  • 27. 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
  • 28. 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.
  • 29. 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)
  • 30. 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.
  • 31. 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.
  • 32. 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
  • 33. 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.
  • 34. 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
  • 35. 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
  • 36. 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.
  • 37. 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).
  • 38. 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)
  • 39. 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
  • 40. 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 0 Custos de Implantação 10.000 5.000 Serviços Mensais 0 4.000 Trabalho Mensal 3.200 0 Custo após 3 anos 149.000 129.000 Fonte: 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.
  • 41. 40 Tabela 2 - Comparativo entre Serviços Terceirizados e Computação nas Nuvens Serviços Terceirizados ($) Computação nas Nuvens ($) Investimento de Capital 0 0 Custos de Implantação 5.000 1.000 Serviços Mensais 4.000 2.400 Trabalho Mensal 0 1.000 Custo após 3 anos 129.000 106.000 Fonte: 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.
  • 42. 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).
  • 43. 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
  • 44. 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
  • 45. 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.
  • 46. 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
  • 47. 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
  • 48. 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.
  • 49. 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.
  • 50. 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)
  • 51. 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).
  • 52. 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
  • 53. 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.
  • 54. 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)
  • 55. 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,
  • 56. 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.
  • 57. 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:
  • 58. 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.html stylesheets/ main.css images/ apagar.gif mail.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-tcc version: 1 runtime: python api_version: 1
  • 59. 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
  • 60. 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.
  • 61. 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
  • 62. 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
  • 63. 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.
  • 64. 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.
  • 65. 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
  • 66. 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.
  • 67. 66 Tabela 3 - Características dos arquivos utilizados para os testes Formato do Arquivo Tamanho Características Planilha de cálculo com várias fórmulas utilizando Microsoft Excel 2003 (.xls) 223KB operações básicas, uma figura e formatações especiais (bordas, títulos, cabeçalhos). Apresentação com 8 slides, diversas imagens, plano de Microsoft PowerPoint 2003 (.ppt) 1,35MB fundo e vários estilos de formatação. Documento de texto com 4.153 palavras, 49 páginas, Microsoft Word 2003 (.doc) 1MB sumário automático, várias quebras de página, tabelas e figuras. Planilha de cálculo com várias células contendo fórmulas Microsoft Excel 2007 (.xlsx) 93KB 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. Documento de texto com 4.153 palavras, 49 páginas, Microsoft Word 2007 (.docx) 878KB sumário automático, várias quebras de página, tabelas e figuras. Planilha de cálculo com várias fórmulas utilizando OpenOffice Calc 3.1 (.ods) 18KB 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. Documento de texto com 12.482 palavras, 53 páginas, OpenOffice Writer 3.1 (.odt) 422KB 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.
  • 68. 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
  • 69. 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
  • 70. 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
  • 71. 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.
  • 72. 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.
  • 73. 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.
  • 74. 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.
  • 75. 74 Tabela 4 - Compatibilidade entre elementos das suítes Origem Destino Compatível Planilha de cálculo local Planilha de cálculo remota Sim Planilha de cálculo local Documento de texto remoto Sim Planilha de cálculo remota Planilha de cálculo local Não Planilha de cálculo remota Planilha de cálculo remota Não Planilha de cálculo remota Documento de texto local Não Planilha de cálculo remota Documento de texto remoto Não Fonte: 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.
  • 76. 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:
  • 77. 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.
  • 78. 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
  • 79. 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.
  • 80. 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
  • 81. 80 Figura 26 - Zoho Projects apresentado de maneira semelhante a um aplicativo desktop Figura 27 - Gmail apresentado de maneira semelhante a um aplicativo desktop
  • 82. 81 Figura 28 - LinkedIn apresentado de maneira semelhante a um aplicativo desktop Figura 29 - Google Calendar apresentado de maneira semelhante a um aplicativo desktop
  • 83. 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
  • 84. 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.
  • 85. 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
  • 86. 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
  • 87. 86 melhorias de compatibilidade entre sistemas tradicionais e baseados em nuvem, facilitando assim a migração de um ambiente para o outro, respectivamente.
  • 88. 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.
  • 89. 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.
  • 90. 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.
  • 91. ANEXOS
  • 92. 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 7.400 43.000.000 30.000 solicitações solicitações/minuto solicitações solicitações/minuto Largura de banda de 10 gigabytes 56 10 gigabytes 740 saída (faturável, inclui megabytes/minuto gratuito; máximo de megabytes/minuto HTTPS) 1.046 gigabytes Largura de banda de 10 gigabytes 56 10 gigabytes 740 entrada (faturável, megabytes/minuto gratuito; máximo de megabytes/minuto inclui HTTPS) 1.046 gigabytes Tempo de CPU 46 horas de CPU 15 minutos de 46 horas de CPU 72 minutos de (faturável) CPU/minuto gratuito, máximo de CPU/minuto 1.729 horas de CPU 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 10.000.000 57.000 140.000.000 129.000 armazenamento de chamadas chamadas/minuto chamadas chamadas/minuto dados Dados armazenados 1 gigabyte Nenhum 1 gigabytes gratuito; Nenhum (faturável) sem máximo Dados enviados à API 12 gigabytes 68 72 gigabytes 153 megabytes/minuto megabytes/minuto Dados recebidos da 115 gigabytes 659 695 gigabytes 1.484 API megabytes/minuto megabytes/minuto Tempo de CPU do 60 horas de CPU 20 minutos de 1.200 horas de CPU 50 minutos de armazenamento de CPU/minuto CPU/minuto dados
  • 93. 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 7.000 chamadas 32 1.700.000 chamadas 4.900 mensagens chamadas/minuto chamadas/minuto Destinatários de e- 2.000 destinatários 8 2.000 destinatários 5.100 mail (faturável) destinatários/minuto gratuito; máximo de destinatários/minuto 7.400.000 destinatários E-mail para 5.000 e-mails 24 e-mails/minuto 3.000.000 e-mails 9.700 e-mails/minuto administradores Dados enviados no 60 megabytes 340 29 gigabytes 84 megabytes/minuto corpo da mensagem kilobytes/minuto Anexos enviados 2.000 anexos 8 anexos/minuto 2.900.000 anexos 8.100 anexos/minuto Dados enviados como 100 megabytes 560 100 gigabytes 300 anexos kilobytes/minuto 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 657.000 chamadas 3.000 46.000.000 32.000 obtenção de URL chamadas/minuto chamadas chamadas/minuto Dados enviados para a 4 gigabytes 22 1.046 gigabytes 740 obtenção de URL megabytes/minuto megabytes/minuto Dados recebidos da 4 gigabytes 22 1.046 gigabytes 740 obtenção de URL megabytes/minuto 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 864.000 chamadas 4.800 45.000.000 31.000 manipulação de chamadas/minuto chamadas chamadas/minuto imagens Dados enviados à API 1 gigabytes 5 megabytes/minuto 560 gigabytes 400 megabytes/minuto Dados recebidos da 5 gigabytes 28 427 gigabytes 300 API megabytes/minuto megabytes/minuto Transformações 2.500.000 14.000 47.000.000 32.000 executadas transformações transformações/min transformações transformações/minu uto to
  • 94. 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 8,600,000 48.000 96,000,000 108.000 cache de memória chamadas/minuto chamadas/minuto Dados enviados à API 10 gigabytes 56 60 gigabytes 128 megabytes/minuto megabytes/minuto Dados recebidos da 50 gigabytes 284 315 gigabytes 640 API megabytes/minuto megabytes/minuto
  • 95. 94 ANEXO B – Código-fonte do aplicativo-exemplo para Google App Engine app.yaml application: todolist-tcc version: 1 runtime: python api_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.yaml indexes: # 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.
  • 96. 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&ecirc; est&aacute; 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&ccedil;&atilde;o: </label><br>
  • 97. 96 <div><textarea name="descricao" rows="3" cols="77"></textarea> <br> <label>Data In&iacute;cio: </label><br><input type="text" name="dateInicio" size="10"> <br> <label>Data T&eacute;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&ccedil;&atilde;o: </label> <font color=black size="3" face="Arial"> {{ usuario.descricao|escape }}</font> <br> <label>Data In&iacute;cio: </label> <font color=black size="3" face="Arial"> {{ usuario.dateInicio|escape }} </font> <label>Data T&eacute;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>
  • 98. 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.py import cgi import os from google.appengine.ext.webapp import template from google.appengine.api import users from google.appengine.ext import webapp from google.appengine.ext.webapp.util import run_wsgi_app from google.appengine.ext import db from 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')
  • 99. 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, }
  • 100. 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.css body { 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;
  • 101. 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 }
  • 102. 101 ANEXO C – Tabela de Dados Coletados nos Testes com Google Docs