Quando vamos criar um logic app pelo portal do Azure, somos apresentados com duas opções de plano de hospedagem:
Standard: Melhor para aplicativos sem servidor (serverless) de nível empresarial, com dimensionamento baseado em eventos e isolamento de rede.
Consumo: Melhor para nível de entrada. Pague apenas quanto o fluxo de trabalho for executado.
Até ai parece tudo tranquilo, esta descrição nos leva a crer que devemos começar pelo plano de consumo, fazer nossas provas de conceito, laboratórios e quando estivermos prontos podemos passar para o plano standard.
Mas na prática, quando olhamos um pouco mais a fundo, percebemos que não conseguimos migrar de forma automática nossos fluxos criados em plano de consumo para o plano standard e além disso, encontramos outras sub-opções dentro de cada um destes planos.
Por que essa falta de conexão entre um plano e outro? E qual a vantagem de uso de cada plano? É isso que vamos descobrir hoje!
Porque não consigo migrar automaticamente?
Como já pontuei em artigos passados, existe uma diferença essencial entre os planos de hospedagem: o runtime.
Quando criamos um logic app em plano consumo, criamos um aplicativo sem servidor multi-locatário executado em um runtime de logic apps.
Quando criamos um logic app em plano standard, criamos um aplicativo de funções de locatário único, pré-configurado para utilizar uma extensão que permite execução dos logic apps. Somado a isso, seu aplicativo roda na infraestrutura do serviço de aplicativo do Azure.
Se você tem interesse em ver como essa extensão configurada e como conseguimos rodar nossos logic apps no runtime de funções, confira esse outro artigo.
Então acabam existindo pequenas diferenças entre o código gerado por cada um dos planos. É possível fazer uma migração manual, copiando e colando o código dos seus aplicativos entre os ambientes e fazendo pequenas alterações. Mas ainda não existe nenhuma maneira oficial de se fazer isso de forma automática.
Quais são minhas opções de hospedagem?
As opções de hospedagem contemplam as combinações de plano e ambiente disponíveis para os dois tipos de logic apps:
- Consumo sem servidor;
- Consumo em um ambiente de serviço de integração (ISE);
- Standard em um plano de serviço de aplicativo (ASP);
- Standard em um ambiente de serviço de aplicativo (ASEv3);
- Standard em containers.
Também é legal ressaltar que quando criamos uma tarefa de automação em algum recurso, o Azure nos provisiona um logic app em plano de consumo sem servidor.
E o que cada um me oferece?
Para chegarmos a uma resposta primeiro devemos avaliar a documentação oficial.
Aviso: as informações de uso, precificação e SLA listadas neste artigo estão sujeitas a mudanças. A intensão da comparação é a nível educational. A referência oficial sempre será a documentação.
Mas antes de fazermos a comparação precisamos entender alguns nomes:
-
Operações de gatilho: englobam apenas os gatilhos dos fluxos;
- Conectores de gatilho: são os conectores encontrados no designer do seu logic app no momento da configuração do gatilho;
-
Operações de ação: englobam a execução dos conectores;
- Conectores internos: são os conectores presentes no runtime do ambiente de hospedagem, você pode identifica-los no designer do seu logic app através da aba interno/built-in;
- Conectores padrão: são os conectores encontrados no designer do seu logic app através da aba padrão/standard;
- Conectores empresariais: são os conectores encontrados no designer do seu logic app através da aba enterprise;
- Conectores personalizados: são os conectores encontrados no designer do seu logic app através da aba personalizado/custom;
-
Operações de armazenamento: operações de armazenamento de estado e histórico de execução do logic app. Se aplica para todos os aplicativos no plano de consumo e para os aplicativos de tipo stateful no plano standard;
-
Conta de integração: é um produto do Azure destinado ao armazenamento de artefatos de integração.
E essa é uma prévia do que é incluso e cobrado em diferentes planos de logic apps, estimados para a região sul do Brasil:
Plano | Consumo | Consumo | Standard | Standard | Standard |
---|---|---|---|---|---|
Hospedagem | Sem servidor | Ambiente de serviço de integração (ISE) | Plano de serviço de aplicativo (ASP) | Ambiente de serviço de aplicativo (ASEv3) | Contêineres |
Operações de armazenamento | R$0.63 por GB por mês | Gratuito | R$0.63 por GB por mês | Gratuito* | Gratuito* |
Tipo de armazenamento | Integrado | Integrado | Conta de armazenamento | Conta de armazenamento | Conta de armazenamento |
Conectores internos | R$0.000131 | Gratuito | Gratuito | Gratuito | Gratuito |
Conectores Padrão | R$0.000653 | Gratuito | R$0.000653 | R$0.000653 | R$0.000653 |
Conectores Enterprise | R$0.005220 | Gratuito | R$0.005220 | R$0.005220 | R$0.005220 |
Conectores Personalizados | R$0.000653 | Gratuito | R$0.000653 | R$0.000653 | R$0.000653 |
Conta de integração | Não incluso | 1 instância inclusa | Não incluso | Não incluso | Não incluso |
SLA** | 99.9% | 99.9% | 99.9% | 99.9% | N/A |
*Consulte o preços das contas de armazenamento;
**Consulte sempre o termo oficial de SLA dos produtos.
Um ponto importante quando vamos estimar custo de execução é que para operações de ação, serão contadas a quantidade de execução final de cada conector, em outras palavras, se você for executar algum loop que roda diversos conectores várias vezes, o Azure vai contar a quantidade de conectores executados em loop multiplicados pelo número de voltas.
É sempre recomendado uso da calculadora de preços do Azure para estimativa dos custos de suas cargas de trabalho.
Não se esqueça de adicionar os preços do ISE, ASP, ASEv3 e AKS/ACI (se for hospedar seus containers no Azure) à sua conta, caso escolha uma opção que depende destes serviços de hospedagem.
Como escolher?
Agora chegamos na parte mais interessante: qual opção é a melhor para mim?
A resposta é bem interpretativa e vai variar de acordo com seu caso de uso.
Na minha opinião, deveríamos separar desta maneira:
Consumo sem servidor: Criação de fluxos mais básicos mais voltados a provas de conceito, laboratórios e integrações B2B. Trás poucas opções de configuração em relação ao ambiente de execução, DevOps e não pode ser executada em uma rede virtual. É a opção ideal para quem busca um modelo de cobrança por uso e para fluxos que vão rodar com pouca frequência. Outro caso de uso interessante é usar esse modelo como uma camada de lógica de negócios entre o APIM e seu backend, já que ele é facilmente integrado.
Consumo em ISE: Se você já tem uma gama de fluxos criados em plano de consumo sem servidor e precisa integrá-los com uma rede virtual, esta é a opção que você procura, principalmente se tem artefatos que podem ser armazenados em uma conta de integração. Dispõe de conectores exclusivos que dispensam uso de um gateway de dados on-premisses.
Standard em ASP: Quando precisa de mais escala e resiliência. Acredito que esta seja a melhor opção para a maioria dos casos, principalmente se está criando seus primeiros fluxos agora. Vai te possibilitar trabalhar dentro de uma rede virtual e conectar em recursos a sua intranet, utilização de mais estratégias de DevOps, além de já ser um ambiente familiar para quem usa funções e serviço de aplicativos.
Standard em ASEv3: Quando você já possui um ASEv3 provisionado para outros aplicativos esta opção se torna bem atrativa. Mas quando ainda não possui, recomendaria caso tivesse necessidade isolamento total dos seus fluxos.
Standard em Containers: Quando você já possui uma arquitetura baseada em containers e deseja extrair do potencial de orquestração dos logic apps.
E ai, o que você acha? Espero que tenha te ajudado a tomar uma decisão mais assertiva!
Próximos passos
Se você gostou do tema e quer continuar discutindo sobre logic apps, fique ligado no blog porque teremos mais artigos com estes temas em breve.
- Conexão de fluxos no Azure com endpoints on-premisses;
- Construção de conectores personalizados;
- Logic Apps com APIM;
- Estratégias de troubleshooting para Logic Apps;
- Integration Service Environment (ISE).