Porque migrar do BizTalk Server para o Azure Logic Apps Standard?

Azure Logic Apps é o sucessor do BizTalk Server. O Azure Logic Apps Standard oferece orquestração de fluxos de trabalho, integração empresarial e extensibilidade para soluções cloud e híbridas. Este artigo resume as razões para migrar, as opções de alojamento disponíveis e as capacidades do BizTalk que precisa de avaliar.

Para estratégias de migração, considerações de planeamento e orientações de entrega, consulte Migrate BizTalk Server with Azure Logic Apps Migration Agent.

Ciclo de vida do BizTalk Server

BizTalk Server 2020 é o lançamento final do BizTalk Server. A Microsoft espera que as vendas do BizTalk Server 2020 terminem a 31 de março de 2027. O suporte mainstream continua até 12 de abril de 2028, após o que o produto permanece sujeito à Política de Ciclo de Vida Fixo da Microsoft.

A Microsoft também planeia oferecer aos clientes elegíveis suporte opcional e pago e alargado de 13 de abril de 2028 a 10 de abril de 2030. Esta oferta destina-se a uma cobertura temporária de migração, espera-se que exclua algumas funcionalidades do BizTalk e permanece sujeita à elegibilidade final, cobertura, preços e termos de compra.

Comece a planear a migração cedo, especialmente se as suas soluções dependerem do Business Activity Monitoring (BAM), do Enterprise Service Bus (ESB) Toolkit, aceleradores de indústria, adaptadores empresariais legados, ferramentas específicas de gestão do ciclo de vida de aplicações BizTalk ou versões do Visual Studio após o Visual Studio 2022. Espera-se que estas capacidades sejam excluídas do suporte alargado pago ou possam necessitar de redesenho.

Para as datas e termos mais recentes, veja:

Porque é que o Logic Apps Standard se adapta às cargas de trabalho do BizTalk

As aplicações BizTalk combinam frequentemente orquestração duradoura, mensagens, transformações, processamento business-to-business (B2B), código personalizado e acesso a sistemas privados. O Azure Logic Apps Standard oferece estas capacidades de integração num runtime de inquilino único e suporta fluxos de trabalho com estado e sem estado. Ao contrário de uma aplicação de lógica de consumo, uma aplicação de lógica Standard pode conter múltiplos fluxos de trabalho que partilham computação, armazenamento, rede e configuração.

As seguintes capacidades fazem do Standard o tipo de recurso preferido para Logic Apps na maioria dos projetos de modernização do BizTalk:

Requisito de BizTalk Capacidade padrão do Logic Apps
Processos empresariais duráveis e de longa duração Fluxos de trabalho com estado mantêm o estado de execução e podem recuperar execuções interrompidas. Fluxos de trabalho sem estado suportam processamento em memória com menor latência quando persistência não é necessária.
Processos de integração relacionados Múltiplos fluxos de trabalho podem correr numa única aplicação de lógica Standard e partilhar recursos, configuração e limites de implementação.
Formatos de mensagens e dados empresariais Conectores e ações incorporados suportam serviços como Azure Service Bus, Event Hubs, SQL Server, XML, ficheiros planos, transformações e cenários B2B.
Lógica de implementação personalizada As funções locais .NET executam código com âmbito de workflow juntamente com fluxos de trabalho no mesmo limite de projeto e aplicação. Scripts em linha, conetores incorporados personalizados e serviços externos oferecem outras opções de extensibilidade.
Conectividade privada e local A execução dedicada num único locatário suporta a integração em redes virtuais e endpoints privados. A implementação híbrida executa fluxos de trabalho numa infraestrutura gerida pelo cliente quando é necessário processamento local.
Gestão do ciclo de vida das aplicações O desenvolvimento do Visual Studio Code, testes locais, infraestrutura como código e CI/CD separam a implementação de aplicações de workflow do provisionamento de infraestrutura.
Escolha de implantação Use o Workflow Service Plan para alojamento Azure gerido, Ambiente do Serviço de Aplicações v3 para alojamento Azure isolado, ou Hybrid para ambientes Kubernetes geridos pelo cliente.

O Logic Apps Standard fornece a maioria das capacidades essenciais para modernizar as soluções BizTalk e serve como a principal plataforma de orquestração e integração para a arquitetura alvo, quer alojada no Azure quer implementada num ambiente híbrido. Outros serviços não são necessários por defeito. Para soluções alojadas no Azure, adicione serviços Azure como Azure Service Bus, API Management do Azure ou Azure Event Grid apenas quando a solução refatorada requer intermediação independente de mensagens, gestão do ciclo de vida da API ou distribuição de eventos. Para implementações híbridas, utilize serviços geridos pelo cliente compatíveis para quaisquer capacidades ou limites arquitetónicos que a solução exija fora do Logic Apps Standard.

Razões para migrar

Benefício Descrição
Plataforma de integração moderna Construa fluxos de trabalho com orquestração gerida, conectores empresariais, capacidades B2B, integração com APIs e segurança e monitorização cloud-native. Avaliar a automação assistida por IA e a automação baseada em agentes, sempre que tal seja suportado.
Preservar investimentos selecionados Reutilizar ou adaptar muitos esquemas, mapas, regras, assemblies e componentes .NET personalizados do BizTalk, em vez de reconstruir todos os artefactos.
Alojamento flexível Execute fluxos de trabalho padrão no Azure ou utilize implantação híbrida para processamento local, acesso à rede, residência de dados ou requisitos regulamentares.
Desenvolvimento low-code e pro-code Combine o estruturador visual de fluxos de trabalho com definições de fluxo de trabalho sob controlo de código-fonte, scripts inline, funções locais .NET, conectores personalizados e serviços externos.
Operações modernas Utilize o controlo de acesso baseado em funções do Azure (Azure RBAC), a infraestrutura como código e pipelines automatizados. Os fluxos de trabalho alojados no Azure integram-se com o Azure Monitor e o Application Insights, enquanto as implementações híbridas utilizam OpenTelemetry e têm diferentes limitações de funcionalidades.
Controlo de custos Partilhe capacidade entre fluxos de trabalho relacionados, escolha um modelo de alojamento que corresponda à procura de carga de trabalho e utilize operações e funções locais incorporadas o máximo possível.

Construir uma arquitetura alvo económica

A relação custo-benefício depende do volume de trabalho, isolamento necessário, infraestrutura existente, utilização de conectores e responsabilidades operacionais. Compare o custo total de propriedade em vez de considerar apenas o custo de alojamento das Logic Apps. Uma linha de base BizTalk pode incluir licenças BizTalk Server, Windows Server e SQL Server; computação e armazenamento; alta disponibilidade e recuperação de desastres; patches; monitorização; ferramentas de implementação; e suporte operacional especializado.

Use as seguintes práticas ao construir o modelo de custo-alvo:

  • Agrupe fluxos de trabalho relacionados com requisitos compatíveis de segurança, ciclo de vida e escalabilidade na mesma aplicação lógica Standard, para que possam partilhar recursos de computação reservados e recursos de suporte. Mantenha as cargas de trabalho separadas quando precisarem de escalabilidade, isolamento, implementação ou propriedade independente.
  • Prefira operações de conectores incorporados quando cumprem os seus requisitos. O modelo Standard inclui execuções ilimitadas de operações integradas, enquanto as operações de conectores geridos são faturadas por chamada.
  • Mantém o código .NET com escopo de workflow nas funções locais quando apropriado. As funções locais utilizam a fronteira da aplicação Logic Apps Standard e não requerem uma Function App separada, endpoint, fluxo de autenticação, pipeline de implementação ou fronteira de monitorização separada. O código ainda consome capacidade no plano Standard.
  • Ajuste corretamente a capacidade do Plano de Serviço de Fluxo de Trabalho e reveja a utilização à medida que as ondas de migração passam à produção. O plano é faturado pela capacidade reservada mesmo quando os fluxos de trabalho estão inativos.
  • Use o Ambiente do Serviço de Aplicações v3 quando requisitos de isolamento, redes dedicadas, conformidade ou consolidação justificam um Plano de Serviço de Aplicação Isolado v2. Não assumas que o ASE v3 é a opção de menor custo para cargas de trabalho menores.
  • Utilize Híbrido quando a execução local, a residência de dados ou a infraestrutura existente oferecerem vantagens suficientes. Inclua no cálculo o ambiente Kubernetes com Azure Arc ativado, o licenciamento do SQL Server, o armazenamento SMB, a rede, as operações e a utilização de vCPU do Logic Apps.
  • Considere as operações de armazenamento, contas de integração, redes, monitorização e o custo temporário de executar BizTalk e Logic Apps em paralelo durante a migração.

Para detalhes sobre preços, consulte os modelos de preços e faturação do Azure Logic Apps e a página de preços do Azure Logic Apps.

Escolha uma opção de alojamento

O Azure Logic Apps tem tipos de recurso de Consumo e Padrão separados. Para a migração do BizTalk, utilize as capacidades do Azure Logic Apps Standard e escolha uma opção de alojamento Azure ou híbrida de acordo com as suas necessidades.

Importante

Se atualmente utiliza o Azure Logic Apps Consumption e planeia migrar cargas de trabalho do BizTalk Server, deve migrar para o Azure Logic Apps Standard. As capacidades de migração do BizTalk não são suportadas em fluxos de trabalho no escalão Consumo.

Opção de hospedagem Melhor ajuste Custo e propriedade Principais considerações
Plano de Serviço de Fluxo de Trabalho A escolha padrão para migrações BizTalk hospedadas no Azure que necessitam de capacidade Standard dedicada e capacidades Azure geridas. Capacidade reservada para WS1, WS2 ou WS3 num ambiente gerido pela Microsoft. Suporta múltiplos fluxos de trabalho por aplicação lógica, integração com redes virtuais, endpoints privados e acesso a capacidades de monitorização do Azure.
Ambiente do Serviço de Aplicações v3 Cargas de trabalho que requerem alojamento Azure isolado, redes dedicadas, limites de conformidade ou consolidação com outras cargas de trabalho de Serviços de Aplicação. Instâncias isoladas do Plano de Serviços de Aplicações v2 num ambiente dedicado. Requer um ASE v3 existente ou novo e deve ser justificado por requisitos de isolamento, escala ou consolidação.
Híbrido Cargas de trabalho que requerem processamento local, acesso de baixa latência a sistemas locais, residência dos dados, implementação na periferia ou infraestrutura gerida pelo cliente. Uso de vCPU em Logic Apps mais Kubernetes, SQL Server, armazenamento SMB, redes e operações geridos pelo cliente. Utiliza Kubernetes com Azure Arc e a extensão Azure Container Apps e requer conectividade Azure de saída. Algumas funcionalidades cloud não são suportadas.

Considerações de implementação híbrida

A implantação híbrida está parcialmente conectada, não isolada da rede. O ambiente requer conectividade de saída para operações do Azure Arc e operações de gestão do Azure. Os conectores geridos alojados na cloud também requerem conectividade ao Azure. Interrupções temporárias de conectividade não impedem necessariamente o processamento local de fluxos de trabalho, mas podem afetar a gestão, telemetria e operações dependentes da cloud.

Para infraestrutura necessária, configurações suportadas, preços e limitações atuais, consulte Configurar a sua própria infraestrutura para aplicações de lógica padrão usando implantação híbrida.

Mapear as funcionalidades do BizTalk com o Logic Apps

O BizTalk Server e o Azure Logic Apps usam arquiteturas diferentes. Use o Agente de Migração para inventariar cada aplicação BizTalk, mapear os seus artefactos e padrões de integração para as capacidades das Logic Apps e identificar componentes que precisa de reutilizar, refatorar, substituir ou redesenhar.

Capacidade BizTalk Caminho de modernização das Aplicações Lógicas Avaliação típica Orientação relacionada
Orquestrações Fluxos de trabalho padrão com ou sem estado Refatorem a lógica dos processos de negócio em fluxos de trabalho. Criar um fluxo de trabalho padrão
Cadeias de processamento e código auxiliar Ações de fluxo de trabalho, funções locais .NET, código inline, conectores personalizados ou serviços externos Reutilizar ou refatorar de acordo com o ciclo de vida necessário e o limite de escalabilidade. Criar e executar funções locais .NET
Encaminhamento de MessageBox tópicos e subscrições do Azure Service Bus, intercâmbios do RabbitMQ, tópicos do Apache Kafka ou encaminhamento de fluxos de trabalho Redesenhar a mensagem independentemente do tempo de execução do fluxo de trabalho. Filas do Service Bus, tópicos e subscrições
Esquemas e mapas Artefactos do projeto, mapas XSLT, modelos Liquid e Data Mapper Reutilizar artefactos compatíveis e validar transformações. Esquemas e mapas
Regras de negócio Motor de Regras do Azure Logic Apps Reutilizar políticas suportadas pelo BizTalk Business Rules Engine ou refatorar factos não fundamentados. Visão geral do Azure Logic Apps Rules Engine
EDI e B2B Fluxos de trabalho padrão, conectores e contas de integração Avalie parceiros, acordos, certificados, esquemas e requisitos de protocolo. Fluxos de trabalho de integração empresarial B2B
Adaptadores Conectores e APIs integrados, geridos ou personalizados Confirme a disponibilidade do conector, a autenticação, a capacidade de processamento e o suporte de alojamento. Descrição geral dos conectores
BAM Rastreio de processos empresariais do Azure para soluções alojadas no Azure suportadas, ou uma arquitetura de observabilidade externa Redesign para implementação híbrida, onde o Acompanhamento de Processos de Negócios do Azure não é suportado. Visão geral do Acompanhamento de Processos de Negócios do Azure
Rastreio e monitorização Histórico de execuções, propriedades rastreadas, Azure Monitor, Application Insights e OpenTelemetry Refatorar o modelo operacional e de apoio. Monitorizar aplicações lógicas e fluxos de trabalho

O diagrama seguinte oferece outra perspetiva das capacidades comuns do BizTalk Server e dos seus caminhos de modernização alojados no Azure:

Diagrama que mapeia as capacidades comuns do BizTalk Server para Azure Logic Apps Standard, Azure Service Bus, API Management do Azure e outros serviços do Azure.

Para disponibilidade detalhada de funcionalidades, consulte conectores Azure Logic Apps, visão geral da integração empresarial e limites e configuração do Azure Logic Apps.

Principais considerações sobre migração

Arquitetura e fiabilidade

  • Comece com o Azure Logic Apps Standard como aplicação-alvo. Use capacidades nativas de fluxo de trabalho, conectores incorporados e funções locais quando apropriado, e adicione outros Serviços de Integração Azure apenas quando um requisito arquitetónico específico os justificar.
  • Para padrões de publicação-subscrição, use um corretor de mensagens como Azure Service Bus, RabbitMQ ou Apache Kafka em vez de reproduzir a BizTalk MessageBox dentro de um fluxo de trabalho.
  • Conceber para repetições e para processamento pelo menos uma vez. Utilize idempotência, deduplicação e operações de escrita seguras para evitar efeitos duplicados quando as operações são repetidas ou as execuções são submetidas novamente.
  • Revise os limites de mensagens e conectores. Para cargas grandes, use a fragmentação no conector, quando suportada, ou implemente o padrão claim-check.
  • Use Gateway de VPN, ExpressRoute ou outro design de conectividade híbrida para ligar redes locais ao Azure. O peering de redes virtuais estabelece a ligação entre redes virtuais do Azure; por si só, não estabelece a ligação entre uma rede no local e o Azure.

Código personalizado

Ter código personalizado numa solução BizTalk não significa automaticamente que a arquitetura alvo necessite de um recurso Funções do Azure separado. Use funções locais .NET para código que pertença a um fluxo de trabalho de integração. As funções locais residem no mesmo projeto que os fluxos de trabalho e correm dentro do limite da aplicação Logic Apps Standard. Os fluxos de trabalho, conectores, configuração e código podem ser construídos, implementados, escalados e operados em conjunto.

As funções locais são adequadas para validação de mensagens com âmbito de fluxo de trabalho, enriquecimento, cálculos, análise personalizada, formatação e processamento específico do negócio. Também podem ajudar a modernizar assemblies auxiliares do BizTalk, utilitários de orquestração e lógica associada ao pipeline quando esse código fizer parte de uma aplicação de integração específica. Esta abordagem evita a introdução de um endpoint separado, fluxo de autenticação, recurso de alojamento, pipeline de implementação e fronteira de monitorização apenas para executar código específico do workflow.

Use as seguintes orientações para selecionar o modelo de alojamento de código apropriado:

Usar funções locais quando Use um recurso separado do Funções do Azure quando
O código é específico para uma aplicação do Logic Apps Standard. O código é partilhado por múltiplas aplicações, fluxos de trabalho ou equipas.
O código valida, enriquece, analisa, formata ou calcula dados dentro de um fluxo de trabalho. O código fornece uma API, serviço ou capacidade de computação orientada a eventos gerida de forma independente.
O fluxo de trabalho e o código devem ser implementados, escalados e operados em conjunto. O código requer escalabilidade, versionamento, implementação ou propriedade operacional independentes.
O código não precisa de um endpoint de rede separado ou de um limite de autenticação. O código deve expor e proteger o seu próprio ponto final ou limite de identidade.
O auxiliar do BizTalk ou a lógica associada ao pipeline pertence ao fluxo de integração migrado. O código constitui a principal carga de processamento e o fluxo de trabalho do Logic Apps é apenas um dos consumidores.

As funções locais consomem a capacidade de computação atribuída à aplicação de lógica padrão e não substituem todas as funções ou serviços autónomos. A sua vantagem de custo e operacional advém de evitar uma fronteira desnecessária de recursos quando o código faz parte do fluxo de trabalho. Os fluxos de trabalho padrão também suportam JavaScript inline, C# e PowerShell para código de curta duração, além de conectores personalizados e chamadas para APIs externas. Para orientações arquitetónicas, consulte Coding with Logic Apps Standard: Local Functions.

Segurança e identidade

Use Microsoft Entra ID, Azure RBAC, Azure Key Vault, redes privadas e entradas e saídas seguras para proteger fluxos de trabalho e dados. As ligações OAuth utilizam autorização baseada em token e podem exigir login e consentimento interativos. Não trate o OAuth como armazenar o endereço de email e a palavra-passe do utilizador no fluxo de trabalho.

Para conectores suportados em fluxos de trabalho Standard alojados no Azure, as identidades geridas eliminam a necessidade de armazenar credenciais ou tokens de acesso. Durante o desenvolvimento local, a extensão Azure Logic Apps Standard pode utilizar a identidade do programador com sessão iniciada através da cadeia de credenciais do Azure Identity, enquanto o fluxo de trabalho implementado utiliza a respetiva identidade gerida atribuída pelo sistema ou pelo utilizador. Ambas as identidades requerem permissões apropriadas sobre o recurso alvo. Esta funcionalidade do Visual Studio Code não altera a limitação híbrida atual para autenticação de identidade gerida nas operações de conectores. Para mais informações, consulte Usar conectores com identidade gerida na extensão Logic Apps Standard.

Implantação e operações

Armazene definições de fluxos de trabalho, configuração e artefactos no controlo de código-fonte e utilize pipelines automatizados de construção e implementação. O Bicep é compilado para modelos do Azure Resource Manager. Terraform e Pulumi são ferramentas alternativas de infraestrutura como código que gerem os recursos do Azure através dos respetivos fornecedores.

Planeie monitorização, controlo de acessos, configuração do ambiente, recuperação de desastres e propriedade de suporte antes da primeira vaga de migração em produção. Proteja as entradas e saídas de ações sensíveis para que não apareçam no histórico de execução ou na telemetria.

Próximos passos

Utilize uma abordagem de migração iterativa para inventariar as dependências, priorizar as cargas de trabalho, validar as arquiteturas de destino e implementar por fases geríveis. O Azure Logic Apps Migration Agent pode ajudar na descoberta, análise, planeamento, conversão, validação e implementação, enquanto mantém o controlo da arquitetura e das decisões de implementação.