Enfim, não me alongarei mais, e quero finalizar essa minuta dizendo que a festa foi MA-RA-VI-LHO-SA! Simplesmente perfeita. Pra arrematar tudo, depois das duas da madrugada a balada começou e as festividades terminaram sabe lá Deus que horas.

Com o surgimento da chamada Web 2.0, um termo popularizado em 2004, surgiu igualmente o conceito de mashup. Baseado na utilização de padrões e tecnologias web (como HTTP, REST, XML, RSS/Atom e Ajax), um mashup é uma aplicação web que combina conteúdo de várias fontes e APIs para criar um novo serviço, com essa combinação a ser feita tipicamente num web browser. Exemplos clássicos deste tipo de aplicações envolvem enriquecimento de mapas geográficos como novas camadas de informação: fotos tiradas em cada local, localização de farmácias ou hotéis, local onde foram feitas as últimas compras em sites de comércio electrónico. Um cenário de Presentation Integration, portanto.
Um termo relacionado surgido pouco depois foi o de Service-Oriented Architecture (SOA). Aplicável principalmente a cenários empresariais, é um padrão de arquitectura – ou filosofia de desenho de aplicações, para alguns – segundo o qual uma aplicação é montada pela composição de serviços autónomos que encapsulam lógica e que podem ser acedidos usando mecanismos e formatos padrão (o SOAP e o WSDL são normas intimamente ligadas à materialização de arquitecturas SOA). Uma das ideias geralmente associada a SOA é a de que os serviços têm granularidade elevada, ou seja, os serviços devem encapsular muita funcionalidade e não ser chamadas atómicas do tipo Create-Read-Update-Delete, dado que são operações pesadas (desde a serialização de/para XML ao transporte pela rede). Este tipo de arquitecturas tem como dois dos grandes atractivos a criação de aplicações loosely-coupled e em que existe um ganho pela reutilização de serviços existentes.
A noção de SOA tem evoluído tanto pelas lições da sua utilização em contextos empresariais – em que o sucesso das implementações nem sempre foi o melhor (vejam-se por exemplo as promessas não cumpridas de padrões como o BPEL ou o UDDI, e a complexidade de normas como WS-Trust ou WS-Federation) –, como com a própria evolução natural da web e a adopção de formatos mais simples e abertos como REST ou JSON.
Nos últimos dois anos esta história tem mais um capítulo, a noção de Microserviços. Construído sobre as ideias anteriores e popularizada mais recentemente por pessoas como Martin Fowler, as principais diferenças face ao SOA talvez sejam a granularidade de cada serviço, que agora se entendem frequentemente como devendo ser mais atómicos e simples, como a utilização de padrões “CRUD” sobre HTTP/REST. Os serviços continuam a ser independentes entre si (podendo ser desenvolvidos sobre qualquer tecnologia), e a dever estar organizados em torno de conceitos ou operações relevantes para o negócio.
Uma materialização desta abordagem de Microserviços no espaço de consumidor final é o IFTTT (If this then that, https://ifttt.com/). Este sistema, usado tipicamente via apps para telemóvel, permite a criação de pequenos workflows (“receitas”), em que caso se verifique uma determinada condição monitorizada pelo IFTTT, é despoletado um evento/acção de resposta. Alguns exemplos seriam: sempre que um determinado utilizador colocar uma foto nova para o Instagram, gravá-la para o OneDrive; sempre que receber um email marcado como Urgente, enviar um SMS para um determinado número, etc. O número de acções disponíveis é muito elevado, e cada uma delas pode ser vista como um microserviço.