BizTalk/Migrering

Google Cloud som målplattform

Google Cloud har flera integrationsprodukter med skilda roller. Application Integration är Googles iPaaS för applikationsflöden; Apigee är API management. Den skillnaden behöver vara tydlig innan någon av dem kallas BizTalk-ersättare.

Rätt namn på rätt ansvar

Application Integration är en serverless, hanterad iPaaS med visuell editor, triggers, tasks och färdiga connectors. Apigee lägger en proxy framför backend-API:er och hanterar bland annat säkerhet, kvoter och analys. Ett API-kontrakt kan därför höra hemma i Apigee medan ett applikationsflöde byggs i Application Integration.

Kompletterande tjänster

Google beskriver Workflows för att orkestrera Google Cloud-tjänster och HTTP-baserade API:er. Pub/Sub används för asynkron meddelandedistribution. Cloud Run kan bära egen kod. Det är separata drift- och kostnadsytor; välj dem bara när flödets sekvensering, messaging eller specialkod kräver det.

Ingen publicerad BizTalk-importväg

De granskade Google-källorna beskriver produkterna men ingen parser för BizTalk-projekt, orkestreringar, maps, pipelines eller bindings. Slutsatsen är att en migrering måste modelleras om från inventerade flöden. Det är en inferens från dokumentationsläget, inte ett påstående om att en tredjepartslösning inte finns.

Vad en pilot måste bevisa

Visa åtkomst till on-premises-system, identitet, schema- och formatvalidering, felhantering, återkörning och övervakning. För EDI och AS2 krävs dessutom en uttrycklig produkt- eller partnerlösning; en stark API-demo bevisar inte partneravtal, acknowledgements eller certifikatbyte.

När Google Cloud passar

Spåret är rimligt när teamet redan driver Google Cloud, har ägarskap för Apigee eller Application Integration och kan stödja den sammansatta målbilden. Om plattformsvalet samtidigt kräver ny identitetsmodell, ny messagingkompetens och ny supportorganisation ska det synas som migrationsarbete, inte döljas i licensjämförelsen.

Räkna på er miljö →