Vad är skillnaden mellan iPaaS och ESB?
Ett ESB (Enterprise Service Bus) är ett centralt integrationslager som ni själva installerar, driftar och förvaltar, vanligtvis i egen miljö. En iPaaS (Integration Platform as a Service) löser samma grundproblem, men levereras som en molnbaserad tjänst där leverantören ansvarar för drift, uppdateringar och infrastruktur.
Skillnaden handlar alltså mindre om vad som kopplas ihop och mer om var lösningen körs och vem som bär ansvaret för den över tid.
Ett sätt att förstå skillnaden är att titta på när begreppen uppstod. Termen enterprise service bus fick fäste 2002, när Gartner-analytikern Roy Schulte började använda den om en produktkategori som då fanns på marknaden. Begreppet iPaaS definierades av samma analyshus 2011. Däremellan flyttade företagens system ut i molnet, och det är i praktiken hela förklaringen till varför modellerna skiljer sig åt.
Båda finns i drift idag. ESB är fortfarande vanligt i större organisationer med omfattande interna systemlandskap, medan iPaaS blivit standardvalet för verksamheter som blandar molntjänster och lokala system.
Vad är ett ESB?
Ett ESB fungerar som en gemensam buss mellan system. Varje applikation kopplas in en gång, mot bussen, och kan sedan skicka och ta emot data från övriga anslutna system genom den. Bussen sköter dirigering, översättning mellan format, köhantering och regler för hur meddelanden ska behandlas.
Modellen är en del av ett större arkitekturtänkande som kallas service-oriented architecture, ofta förkortat SOA. Grundtanken där är att verksamhetens funktioner ska byggas som fristående tjänster som kan anropas av varandra, i stället för att ligga inbakade i varje enskild applikation. Bussen är det som binder ihop tjänsterna.
ESB löste ett verkligt problem. Fram till dess kopplades system ihop direkt med varandra, och antalet kopplingar växte snabbare än antalet system. Med ett ESB samlades integrationerna i ett lager i stället för att ligga utspridda som separata punkt-till-punkt-lösningar.
Så fungerar ett ESB tekniskt
Ett ESB installeras i organisationens egen miljö och körs på egen infrastruktur. Det innebär att ni själva ansvarar för servrar, kapacitet, uppdateringar och säkerhetsrättningar.
Kommunikationen bygger på de protokoll som var etablerade när modellen växte fram, framför allt SOAP-baserade webbtjänster och meddelandeköer som JMS och MQ. Det är robusta protokoll byggda för hög volym och garanterad leverans inom ett kontrollerat nätverk.
Skalningen sker vertikalt. Behöver bussen klara mer läggs kraftfullare hårdvara till, alltså mer minne och fler processorer på befintlig server. Det fungerar bra upp till en gräns, men gränsen är fysisk och kapacitetsplaneringen är er uppgift.
Installationen är dessutom enkelkundsbaserad. Ni kör er egen instans, med er egen version, som ni själva uppgraderar när ni har tid och resurser.
Styrkor och svagheter
Styrkan ligger i kontroll och robusthet. All data stannar i er miljö, ni bestämmer själva när något ska ändras, och lösningen kan anpassas i detalj efter era förutsättningar.
Svagheten visar sig när systemlandskapet flyttar ut. Ett ESB är i grunden byggt för integrationer inom en organisations infrastruktur. Många leverantörer har byggt ut sina produkter med stöd för molntjänster, men arkitekturen utgår fortfarande från att de viktigaste systemen finns innanför brandväggen.
Till det kommer förvaltningsbördan. Ett ESB kräver specialistkompetens internt, både i plattformen och i den underliggande infrastrukturen.
Vad är iPaaS?
En integrationsplattform som tjänst löser samma uppgift, men flyttar plattformen till molnet och ansvaret till leverantören. Systemen kopplas till plattformen, som hanterar anslutningar, datatransformation, affärslogik, schemaläggning och felhantering.
Gartner definierar iPaaS som en leverantörsdriven molntjänst som gör det möjligt att bygga integrationer mellan applikationer, tjänster och datakällor, både inom och utanför den egna organisationen. Just den sista delen är kärnan i skillnaden mot ESB.
Så fungerar en iPaaS tekniskt
En integrationsplattform körs hos leverantören och delas mellan flera kunder, alltså i en modell som brukar kallas multi-tenant. Det är förklaringen till både den lägre kostnaden och till att förbättringar och säkerhetsuppdateringar kommer alla kunder till del samtidigt, utan att någon behöver planera ett uppgraderingsprojekt.
Kommunikationen utgår från moderna protokoll, framför allt REST-baserade API:er och webhooks. Skillnaden mot ESB är inte bara teknisk. Ett ESB är konstruerat för att hämta information enligt schema från kända system, medan en iPaaS också kan ta emot händelser i det ögonblick de inträffar. När en betaltjänst eller e-handelsplattform skickar en notifiering behöver det finnas något som lyssnar.
Skalningen sker horisontellt. Behöver integrationsplattformen klara mer läggs fler resurser till parallellt, och det hanteras av leverantören snarare än av er. Volymtoppar blir därmed en driftfråga hos någon annan.
Nya kopplingar byggs dessutom ofta med färdiga integrationsmoduler som redan är testade i drift, vilket gör att varje ny integration i regel blir billigare än den förra i stället för dyrare.
Modellen är i grunden molnbaserad, men on-prem-varianter förekommer när systemlandskapet eller säkerhetskraven inte tillåter molndrift. Skillnaden mot ett ESB är då inte var plattformen står, utan att det fortfarande är en färdig produkt med färdiga moduler och att drift och förvaltning kan ligga kvar hos leverantören.
Läs mer i vår kompletta guide: Vad är en integrationsplattform (iPaaS)?
De viktigaste skillnaderna
Var lösningen körs
Ett ESB körs vanligtvis on-premise, alltså i egen serverhall eller i en molnmiljö som ni själva ansvarar för. En iPaaS körs hos leverantören. Vissa leverantörer erbjuder on-prem-varianter när systemlandskapet eller säkerhetskraven kräver det, men grundmodellen är molnbaserad.
Vem som ansvarar för drift
Det här är den skillnad som märks mest över tid. Med ett ESB ligger drift, övervakning, uppdateringar och säkerhetsrättningar hos er. Med en iPaaS ligger de hos leverantören, som också ansvarar för att plattformen utvecklas.
Konsekvensen syns i personberoendet. Ett ESB kräver att någon internt kan plattformen på djupet. Slutar den personen försvinner en del av förståelsen, och kvar finns flöden som fungerar men som ingen vågar röra.
Vad som går att koppla in
Ett ESB fungerar bäst i slutna miljöer med kända system och stabila protokoll. En iPaaS är byggd för att nå både inåt och utåt, vilket gör det enklare att ansluta molntjänster, handelspartner och externa API:er utan särskilda arrangemang för varje anslutning.
Skillnaden blir tydligast när något utanför er kontroll förändras. När en molnleverantör släpper en ny API-version är det en normal del av förvaltningen i en plattform. I ett ESB blir det ett internt utvecklingsuppdrag.
Hur de skalar
Ett ESB skalar vertikalt och en iPaaS horisontellt. Praktiskt betyder det att en volymökning i det första fallet är en fråga om hårdvara och kapacitetsplanering hos er, medan den i det andra fallet hanteras av leverantören.
För en verksamhet med jämna volymer spelar det liten roll. För en med säsongstoppar, kampanjer eller snabb tillväxt är skillnaden märkbar.
Kostnadsmodell
Ett ESB innebär en större initial investering i licenser, infrastruktur och implementation, följt av löpande kostnader för drift och förvaltning som är svårare att förutse. En iPaaS innebär en lägre uppstartskostnad och en löpande avgift där infrastruktur och uppdateringar ingår.
Vilken modell som blir billigast beror på tidshorisonten och på hur mycket intern kompetens ni redan har. Det som skiljer mest är förutsägbarheten.
Kompetens som krävs
Att förvalta ett ESB kräver specialistkompetens internt. En iPaaS kräver framför allt att ni förstår era egna processer och flöden, medan det tekniska ansvaret ligger hos leverantören.
Det är den skillnaden som sänkt tröskeln för mindre och medelstora företag, som historiskt avstod från integrationsplattformar eftersom de var kostsamma och krävde egen kompetens att förvalta.
Jämförelse: iPaaS och ESB
Notera att raderna hänger ihop. Att en iPaaS är multi-tenant är förklaringen till både den lägre kostnaden och till att alla kunder ligger på samma version. Att ett ESB körs i egen miljö är förklaringen till både kontrollen och förvaltningsbördan. Det är samma egenskap sedd från två håll.
Är ESB föråldrat?
Nej, men användningsområdet har smalnat.
Ett ESB löser fortfarande sitt ursprungliga problem väl, alltså att samla många interna integrationer i ett gemensamt lager i en miljö ni kontrollerar fullt ut. För organisationer med omfattande lokala systemlandskap, reglerade branscher eller krav på att data aldrig lämnar den egna infrastrukturen är det ett fullt rimligt val.
Det som förändrats är omvärlden. När merparten av verksamhetens system låg i egen drift var ESB det naturliga svaret. Idag ligger affärssystem, CRM, e-handel och analysverktyg ofta hos olika leverantörer i molnet, och då arbetar man i motvind med en arkitektur byggd för det motsatta.
Många organisationer har därför inte bytt ut sitt ESB utan kompletterat det. Bussen hanterar de interna flödena medan en plattform hanterar det som pekar utåt.
När passar vilket?
Ett ESB kan vara rätt val när merparten av era system körs i egen miljö, när ni har regulatoriska krav som gör molndrift olämplig, när ni redan har plattformen och kompetensen på plats, eller när volymerna är så stora att egen infrastruktur blir mer ekonomisk.
En iPaaS är oftast rätt val när systemlandskapet blandar molntjänster och lokala system, när ni behöver koppla mot externa parter som kunder, leverantörer eller fakturaväxlar, när verksamheten förväntas växa eller byta system, och när ni inte vill bygga upp och behålla egen integrationskompetens internt.
För de flesta små och medelstora företag pekar svaret åt samma håll. Tröskeln för iPaaS är låg, ansvaret ligger hos någon annan och kostnaden är förutsägbar. Ett ESB förutsätter en organisation som både vill och kan bära plattformen själv.
Kan man ha båda?
Ja, och det är vanligare än man tror.
Organisationer som investerat i ett ESB byter sällan ut det över en natt. En vanlig väg framåt är att låta bussen fortsätta hantera de interna flöden den redan sköter, samtidigt som en plattform tar hand om nya integrationer, särskilt de som går mot molntjänster och externa parter.
Över tid flyttas ofta fler flöden över allt eftersom underliggande system byts ut. Det är en betydligt lugnare övergång än att göra allt på en gång, och den låter er utvärdera i praktiken innan ni bestämmer er.
Den tyngsta posten i en migrering är sällan själva kopplingarna utan affärslogiken. Ligger valideringar, beräkningar och flödesregler inbakade i bussen behöver de byggas om. Ligger de i ett eget lager är det bara anslutningarna som ska flyttas.
Vanliga frågor om iPaaS och ESB
Vad står ESB för?
Enterprise Service Bus, alltså ett centralt integrationslager där system kopplas in en gång och sedan kan utbyta data med övriga anslutna system genom bussen. Termen etablerades 2002
Vad står iPaaS för?
Integration Platform as a Service, en molnbaserad integrationsplattform där leverantören ansvarar för drift, uppdateringar och infrastruktur. Begreppet definierades av Gartner 2011.
Vad är skillnaden mellan ESB och SOA?
SOA, service-oriented architecture, är det övergripande arkitekturtänkandet där verksamhetens funktioner byggs som fristående tjänster. Ett ESB är den tekniska komponent som binder ihop tjänsterna.
Är iPaaS säkrare än ESB?
Ingen av modellerna är i sig säkrare. Ett ESB ger full kontroll över infrastrukturen men förutsätter att ni själva håller den uppdaterad. En iPaaS lägger det ansvaret hos leverantören, vilket kräver att ni kontrollerar var data behandlas och att ett personuppgiftsbiträdesavtal finns på plats.
Kan ett ESB ersättas av en iPaaS?
Ja, men sällan över en natt. Vanligast är att befintliga flöden ligger kvar medan nya integrationer byggs i plattformen, och att flöden flyttas efter hand som underliggande system byts ut.
Vad kostar det att gå från ESB till iPaaS?
Det avgörs av hur många flöden som ska flyttas och hur mycket affärslogik som sitter inbyggd i bussen. Ligger logiken hårt knuten till ESB:et behöver den byggas om, vilket är den tyngsta posten i en migrering.
Sammanfattning
Både ESB och iPaaS löser samma grundproblem, alltså att samla integrationerna i ett gemensamt lager i stället för att bygga separata kopplingar mellan varje par av system. Skillnaden ligger i var lösningen körs och vem som ansvarar för den.
Ett ESB ger full kontroll men kräver att ni själva bär drift, uppdateringar och kompetens. Det är byggt för slutna, lokala miljöer och för de protokoll som dominerade när modellen växte fram. En iPaaS flyttar ansvaret till leverantören och är byggd för landskap där system finns både i molnet och lokalt.
Frågan är alltså inte vilken modell som är modernast, utan vilken som matchar ert systemlandskap och era resurser. Har ni redan ett ESB och kompetensen att förvalta det finns sällan skäl att riva upp något som fungerar. Står ni inför nya integrationer mot molntjänster eller externa parter är det däremot värt att fundera på var de hör hemma.
Vill ni resonera kring vad som passar ert systemlandskap är ni välkomna att boka en kostnadsfri och förutsättningslös demo, så går vi igenom förutsättningarna tillsammans.