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.
Vad Pub/Sub lovar och inte lovar
Den som ersätter MessageBox med Pub/Sub behöver läsa leveransvillkoren innan arkitekturen ritas. Standardläget är at-least-once utan ordningsgarantier: ett meddelande kan levereras mer än en gång, i vissa fall även efter en lyckad kvittens, så mottagaren måste vara idempotent. Ordning finns som tillval via ordering keys och gäller per nyckel när prenumeranten ansluter i samma region. Exactly-once finns också, men bara för pull-prenumerationer, bara inom en region, och med dokumenterat högre latens och lägre genomströmning. Ett BizTalk-flöde som i dag tyst förlitar sig på ordnad leverans behöver alltså få det kravet nedskrivet och testat, inte antaget.
Vägen in till lokala system
BizTalk-flöden slutar sällan i molnet: de läser filareor, anropar interna ERP-system och når databaser som aldrig ska exponeras mot internet. Integration Connectors dokumenterar privat anslutning till on-premises-system via Private Service Connect, där en service attachment publicerar systemet bakom en lastbalanserare på er sida och en endpoint attachment konsumerar den från Googles sida. Det fungerar, men notera modellen: exekveringen ligger kvar i Googles moln och varje internt system måste göras nåbart genom nätverkskedjan. Google Cloud har ingen lokal exekveringsagent för Application Integration motsvarande den agentmodell vissa iPaaS-leverantörer använder. Räkna nätverksarbetet som en del av migreringen, inte som en detalj.
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. Vi har inte hittat någon importväg; det betyder inte att ingen finns, bara att ni inte ska räkna med en.
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.
Svensk region finns, men kontrollera tjänsterna
Sedan 2025 driver Google Cloud regionen europe-north2 i Stockholm; närmast därutöver ligger europe-north1 i Hamina i Finland. För verksamheter med krav på svensk eller nordisk datalokalisering är det ett verkligt argument som tidigare saknades. Två kontroller återstår dock innan det skrivs in i beslutet: att varje tjänst i målbilden faktiskt finns i regionen (nya regioner får tjänster stegvis) och att exactly-once- och ordningsvillkoren ovan, som är regionsbundna, går ihop med var era prenumeranter kör. Datalokalisering som utlovas per region men byggs över två regioner är ett dyrt sätt att upptäcka den läxan.
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 migreringsarbete, inte döljas i licensjämförelsen.