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.

Exemplo

Apresentam-se de seguida dois exemplos de Logic Apps criadas com actions disponibilizadas nativamente. Para exemplos passo-a-passo recomenda-se a consulta da documentação em https://azure.microsoft.com/en-us/documentation/services/app-service/logic/.

A figura abaixo apresenta provavelmente o que é o exemplo mais simples possível de uma Logic App.

Esta Logic App é composta apenas por duas acções, ambas utilizações de uma API App que permite fazer pedidos HTTP.

A primeira é uma acção de HTTP/Get, que a cada minuto faz um pedido HTTP a um URL configurado (no caso, “http://www.example.com”), e obtém tanto o conteúdo HTML da página (“body”) da resposta como os cabeçalhos HTTP (“headers”). A segunda acção é um HTTP/Post, em que se envia a informação obtida no HTTP/Get anterior como corpo do pedido para um serviço gratuito (http://requestb.in) que por sua vez permite consultar o que está a receber via HTTP Post.

De notar que a configuração de que o resultado da 1ª acção deve ser usado como input da 2ª é feito via uma dropdown que apresenta todos valores possíveis de utilizar, não sendo necessário regra geral a introdução de texto. Quando se faz esta escolha, a representação textual interna substitui a dropdown (no caso acima, @triggers().output.body).

A imagem acima é um screenshot retirado do novo Portal de Azure (http://portal.azure.com), onde são efectuadas as operações realizadas tanto com Logic Apps como com API Apps. Além do designer visual na parte central, são visíveis as opções de topo do editor (onde se inclui uma opção “Code View” que permite consultar a especificação do processo em formato JSON passível de armazenamento em source control), como a paleta de API Apps do lado direito, onde se vêm algumas das dezenas de opções já disponíveis.

A figura abaixo apresenta um exemplo um pouco mais complexo que o anterior.

No exemplo acima são usadas 4 acções:

Recurrence: acção de trigger da Logic App, indica que a mesma vai ser executada a cada minuto.
Twitter Connector: procura no Twitter por algum texto (no caso, “Philae”). Quando se adiciona esta action é necessário realizar autenticação no Twitter, que fica guardada internamente à Logic App.
Dropbox Connector: action que pega no resultado da acção de Twitter e cria um ficheiro numa conta Dropbox com o conteúdo do tweet encontrado. Tal como no caso do HTTP/Post no exemplo anterior, esta acção tem uma dependência criada implicitamente pelo facto de usar dados de outra acção, sendo também necessário – como no caso da action de Twitter – fazer autenticação no Dropbox.
Office365 Connector: action que pega no resultado da acção de Twitter e envia um email para o endereço email configurado, com o conteúdo do tweet. Mais uma vez, é necessário fazer autenticação no serviço (agora o Office 365) quando se usa esta acção.

Cada uma das acções anterior tem opções de refinamento que permitem especificar comportamento mais complexo, e a que se acede através do botão de reticências no seu canto superior direito.

No caso anterior, é possível por exemplo indicar que esta acção apenas é executada caso se verifique uma determinada condição, ou que se pretende que iterar a sua utilização sobre uma lista de itens de informação.

A figura abaixo apresenta um excerto da Code View, mostrando o JSON que representa a Logic App descrita acima. Neste JSON podemos ver uma secção de triggers que desencadeiam a execução, e uma sequência de actions, cada uma com o seu tipo e configuração específica. Como se pode reparar também, cada action tem um atributo type que no caso do twitterconnector é uma ApiApp.

"triggers": {
  "recurrence": {
    "recurrence": {
      "frequency": "Minute",
      "interval": 1
    },
    "type": "Recurrence"
  }
},
"actions": {
  "twitterconnector": {
    "type": "ApiApp",
    "inputs": {
      "apiVersion": "2015-01-14",
      "host": {
        "id": "/subscriptions/..."
	"gateway": "https://devtechrefreshlisboa..."
      },
      "operation": "SearchTweets",
      "parameters": {
        "Query": "philae",
        "MaxResults": 20
      },
      "authentication": {
        "type": "Raw",
        "scheme": "Zumo",
        "parameter": "@parameters('/subscriptions/...')"
      }
    },
    "conditions": []
  },
  "dropboxconnector": {
    "type": "ApiApp",
    "inputs": {

Um dos pontos mais curiosos das Logic Apps é a forma como lidam com controlo de fluxo. Por omissão, todas as acções executam em paralelo umas com as outras, não existindo – como sucede nos fluxogramas ou workflows tradicionais – um controlo de fluxo explícito. Este controlo de fluxo é criado implicitamente com base em dependências de dados. Assim, se a acção B depende da acção A, B vai ser executado depois de A. Se não depende, vai ser executado em paralelo.

Na implementação actual, as formas de controlo de fluxo que existem são as 4 já referidas: a) recorrência; b) dependência de dados; c) execução condicionada a uma condição; d) repetição sobre lista. Uma outra action disponibilizada, o “Wait”, pode igualmente ser utilizada neste contexto, mas o mecanismo como um todo é muito diferente daquilo a que estamos habituados, lembrando a forma de funcionamento altamente paralelizável de motores de regras (como o do BizTalk Server ou do Windows Workflow Foundation v2).

Conclusão

Neste artigo procurou-se dar uma introdução às Logic Apps, no seu contexto histórico e arquitectural, sem entrar em detalhe de implementação, e omitindo aspectos como monitoria no Portal Azure, custos, tratamento de erros, escalabilidade, bem como a integração profunda com as Web Apps e vários outros temas. Existem no entanto três aspectos que vale a pena referir como conclusão:

Primeiro, as Logic Apps são uma oferta Empresarial/Premium, tendo origem no mesmo universo empresarial de onde vêm produtos business-critical como o BizTalk Server. São portanto de esperar potencialidades como escalabilidade, tolerância a falhas, tratamento de erros ou robustez, entre outros. Apesar de estarem disponíveis actualmente muitas actions orientadas para o consumidor final (como Facebook ou Twitter), sendo estas sempre usadas nas demonstrações públicas, o foco arquitectural é empresarial.

Segundo, as Logic Apps são materializações de arquitecturas baseada em microserviços, e dependem de API Apps, em que se podem tanto usar as disponibilizadas nativamente pela Microsoft, mas também desenvolver novas, sendo este um processo que se reveste de uma enorme simplicidade (uma API App é essencialmente uma WebApi alojada em Azure, com um contracto de utilização descrito em formato Swagger/JSON). Apesar de ainda não disponível completamente, está previsto um Marketplace de API Apps, onde ISVs poderão disponibilizar as suas próprias APIs e monetizar a sua utilização, quer sejam usadas directamente quer via Logic Apps. Alguns exemplos poderão ser serviços de detecção de rostos, acesso a informação como bolsa ou meteorologia, motores de recomendações, entre muitos outros.

Finalmente, deve salientar-se o facto de as Logic Apps ainda estarem em Preview e com evoluções frequentes (ver por exemplo as alterações mais recentes em http://azure.microsoft.com/en-us/updates/schedule-logic-apps-to-run-in-the-future/), existindo limitações como sejam a impossibilidade de criar workflows em Visual Studio, e de o processo de sincronização com repositórios de código como o TFS ser manual, entre outras. Ainda assim, as Logic Apps são provavelmente a novidade mais interessante de entre as últimas que têm surgido no universo Microsoft Azure, e vale a pena tanto perceber que cenários suportam, como acompanhar o rumo e evolução dos próximos meses.

Revista PROGRAMAR