Arquitetura Orientada a Serviços (SOA)
E para que todos esses recursos possam ser acessados de forma ampla e fácil, de qualquer lugar, foi fundamental o desenvolvimento de um jeito diferente de pensar a arquitetura de software: a Arquitetura Orientada a Serviços, ou SOA. Imagine que, em vez de construir um grande sistema único e engessado, nós quebrássemos todas as suas funcionalidades em pequenos serviços independentes, como peças de Lego. Cada serviço faz uma coisa específica e faz bem feito. A grande vantagem é que esses "tijolinhos" podem ser reutilizados inúmeras vezes para formar diferentes aplicações, sem precisarmos reinventar a roda a cada projeto novo.
O principal objetivo dessa ideia é permitir que aplicações completamente diferentes, feitas em linguagens distintas e rodando em sistemas operacionais diversos, possam se conversar e trabalhar juntas sem problemas. Para que essa conversa funcione, os serviços precisam se comunicar de uma forma padrão, universal, que todos entendam. Foi aí que surgiram os Serviços Web. É importante não confundi-los com sites que acessamos no navegador. Eles são, na verdade, componentes de software que ficam disponíveis na internet e cujas funções podem ser acionadas por outras aplicações.
Pense em um serviço web como o sistema de pedidos de um restaurante. Você (a aplicação cliente) não vai até a cozinha buscar sua comida. Você faz um pedido (uma requisição) seguindo um cardápio padrão (a interface do serviço), e o garçom (o serviço web) leva seu pedido até a cozinha e depois traz o prato pronto (a resposta) para você. Dois modelos principais se popularizaram para fazer esse "pedido": o SOAP e o REST.
O SOAP foi o primeiro, muito formal e organizado. Ele é como enviar uma carta registrada, com todo o conteúdo muito bem especificado dentro de um envelope XML, seguindo regras rígidas. Já o REST é um conceito mais flexível, um estilo de arquitetura que aproveita a simplicidade da web como nós já a conhecemos. Os serviços que seguem esse estilo são chamados de RESTful.
A beleza do REST está na sua simplicidade e no uso de coisas que já funcionam na internet. Ele funciona basicamente com URLs (chamadas de URIs), que são os endereços de tudo. Todo dado ou informação que queremos acessar – seja um cliente, um produto ou uma foto – é tratado como um "recurso" e tem seu próprio endereço único. Para interagir com esse recurso, usamos os verbos simples do HTTP, o mesmo protocolo que usamos para navegar na web: GET para buscar uma informação, POST para criar algo novo, PUT para atualizar e DELETE para remover.
E a linguagem que esses serviços usam para trocar dados é usually o JSON, que é um formato leve e de fácil leitura, tanto para humanos quanto para máquinas. Por exemplo, um aplicativo de previsão do tempo no seu celular não tem a informação da temperatura. O que ele faz é enviar um GET para o endereço do serviço web de meteorologia, que retorna um JSON simples com os dados: {"cidade": "São Paulo", "temperatura": 22, "condicao": "nublado"}. O aplicativo então pega esses dados e mostra para você de forma bonita.
Como o REST usa padrões abertos e amplamente conhecidos como HTTP e JSON, ele se tornou a forma preferida pela maioria dos provedores de nuvem para disponibilizar seus serviços. Quando você precisa criar um servidor virtual, por exemplo, seu sistema envia uma requisição POST em formato JSON para a URL da API do provedor de nuvem, e ele magicamente provisiona esse servidor para você. Essa interoperabilidade e independência de plataforma são absolutamente essenciais para a computação em nuvem, pois garantem o amplo acesso que define o modelo.
Com isso, fechamos esta introdução sobre as tecnologias que alicerçaram a nuvem, desde a virtualização até os serviços web. A seguir, mergulharemos em um tópico crucial para qualquer projeto real: entender os custos dos serviços em nuvem e os aspectos práticos de como migrar e hospedar uma aplicação em um provedor público.
