Azure Logic Apps: o futuro dos backends?

Introdução

Em Março de 2015 a Microsoft anunciou o Azure App Service, uma evolução da oferta aplicacional Azure que funde dois serviços existentes – Web Sites e Mobile Services – com dois novos serviços: as Logic Apps, destinadas ao desenvolvimento rápido e visual de processos de negócio, e as API Apps que encapsulam funcionalidades autónomas reutilizáveis, consistindo ambos numa concretização tecnológica de uma arquitectura baseada em Microserviços.

O objectivo deste artigo é apresentar as Logic Apps, tanto em termos do seu contexto e arquitectura, como na utilização concreta e simbiose com as API Apps.

Contexto

O caminho que nos traz às Logic Apps começou muito antes de Março de 2015.

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.

No mundo Microsoft, e depois de uma história que inclui actores como o BizTalk Server, Azure Service Bus, Windows Workflow Foundation, e todo um foco em evoluir as tecnologias para abordagens cloud, foram pré-apresentados no Integrate 2014 em Redmond os BizTalk Microservices, componentes atómicos cloud-based utilizáveis para integração de sistemas, a que estava associado um motor de Workflow e uma ferramenta de modelação de processos web-based.

Finalmente, com o anúncio de Março de 2015 tornou-se finalmente público o quadro todo: as API Apps (apresentadas no artigo Criar uma API no Azure App Service de Guilherme Ferreira na revista PROGRAMAR nº 49 de Junho 2015) são a implementação da Microsoft do conceito de Microserviços, e as Logic Apps a forma de os orquestrar para a criação de aplicações de negócio.  

Azure Logic Apps

Como referido, as Logic Apps são uma das componentes do Azure App Service, e o seu objectivo é permitir a automação de processos de negócio ou workflows, realizando uma modelação gráfica dos mesmos. Ao contrário de abordagens como o IFTTT, os destinatários principais são tanto o mercado empresarial/start-ups como utilizadores com know-how técnico ou programadores.

Os processos de negócio são modelados usando peças de uma paleta onde se encontram as API Apps já mencionadas, e que incluem conectores para sistemas como bases de dados ou ofertas SaaS variadas como o Salesforce ou Office 365, suportando desta forma cenários de integração de sistemas Cloud-based.

As componentes das Logic Apps são os seguintes:

Workflow
modelação gráfica dos vários passos de um processo de negócio, e respectivo motor de execução. Esta modelação é feita (por agora) exclusivamente em ambiente web browser no portal Azure, e internamente ao sistema os processos são representados como JSON.
Triggers
um trigger é um caso particular de uma acção, e permite desencadear a execução de uma Logic App. Alguns exemplos de triggers são: execução recorrente (ex: a cada 5 minutos), resposta a um evento (ex: aparece um registo novo numa determinada tabela SQL) ou a pedido (ex: invocação de uma Logic App via pedido HTTP, como se fosse um Web Service).
Actions
de uma forma genérica, uma Action é um passo do workflow, executada numa sequência depois de um Logic App ser iniciada via trigger. As actions são essencialmente API Apps, sendo que se podem tanto usar as disponibilizadas pela Microsoft como simplesmente ser desenvolvidas à medida em .Net/C#. De entre as primeiras (ver lista completa em https://azure.microsoft.com/en-us/documentation/articles/app-service-logic-connectors-list/), por vezes chamadas “Connectors” na documentação, existem dois tipos: as ‘Standard’ que oferecem funcionalidades como integração com Facebook, Office 365, SQL, FTP, SharePoint/Yammer, Salesforce ou Twitter, e as ‘Premium’ que se destinam a cenários de integração de sistemas e são provenientes da oferta de BizTalk Services. Estas últimas incluem potencialidades de processamento de EDI/AS2, EDIFACT, mapeamentos JSON-XML, validação de formatos de mensagem, ou integração com Informix, WebSphere MQ, Oracle ou SAP, entre outras. A utilização de actions Premium tem requisitos adicionais em termos de subscrição Azure e respectivos custos.

Internamente, as Logic Apps dependem de módulos já existentes em Azure como sejam as WebApps e o Resource Manager, que ficam fora do âmbito deste artigo.

Publicado na edição 50 (PDF) da Revista PROGRAMAR.