Har Microservices ersatt SOA?

I det ständigt föränderliga landskapet av mjukvaruutveckling, utforskar arkitekter och utvecklare ständigt olika arkitektoniska paradigm för att bygga robusta och skalbara system och applikationer. Två populära tillvägagångssätt som har fått stor uppmärksamhet de senaste två decennierna är SOA (Service Oriented Architecture eller tjänsteorienterad arkitektur på svenska) och Microservices (mikrotjänster på svenska). Det är lätt att tro att något som ”uppfinns” efter något annat per default är bättre, men så enkelt är det långt ifrån alltid. Syftet med detta blogginlägg är att försöka utröna om Microservices har ersatt SOA. För att besvara frågan behövs först en kort bakgrund och lite terminologi.

Bakgrund

SOA var ett av de hetaste buzzworden och det populäraste arkitektoniska angreppssättet runt millennieskiftet. Många organisationer hoppade på trenden att bygga om sina system och integrationslandskap enligt det tjänstetänk som SOA innebär. Otaliga gigantiska projekt startades med syfte att ”göra om och göra rätt” från grunden. Många projekt pågick under flera år och kostade enorma summor. Lyckades man då med målet att tjänstefiera sitt systemlandskap? På den frågan går det naturligtvis inte att svara varken ja eller nej då frågan är så komplex och alla organisationer är olika. Det var dock många stora projekt som gick i graven efter ett antal år utan att ha uppnått målet med en tjänstefierad arkitektur. SOA som arkitektonisk approach fick ofta skulden och många propagerade för att SOA inte fungerar. Man pratade t.o.m. om ”SOA-döden”! Min syn på detta hoppas jag kunna knyta samman i slutet av denna blogg.

Tio år senare, runt 2010, blev Microservices ett av de hetaste arkitektoniska begreppen och detta var nu räddaren som skulle lösa upp de gamla monolitiska systemen.

Även om både SOA och Microservices syftar till att bemöta liknande utmaningar inom mjukvarudesign, har de distinkta egenskaper och tjänar olika syften. Det här blogginlägget försöker förklara innebörden av de två och hur de förhåller sig till varandra.

Monolitisk arkitektur

För att sätta diskussionen om SOA och Microservice i sitt sammanhang behöver vi även kort beröra begreppet monolitisk arkitektur. Monolitiska arkitekturer samlar alla funktioner i ett enda applikationsskikt. Det är den enklaste formen av arkitektur eftersom den inte involverar lika många aktörer som andra arkitektoniska stilar.

Den monolitiska modellen fungerar för små arkitekturer, men problemen uppstår vanligtvis när arkitekturen behöver skalas upp funktionsmässigt eftersom modulerna är mycket beroende av varandra.

Vad är SOA?

Amazons definition (fritt översatt till svenska) är:
SOA är en metod för mjukvaruutveckling som använder programvarukomponenter som kallas tjänster för att skapa affärsapplikationer.

IBMs definition (fritt översatt till svenska) är:
SOA definierar ett sätt att göra programvarukomponenter återanvändbara och kompatibla via tjänstegränssnitt.

För att sammanfatta det lite förenklat bygger konceptet med SOA i grunden på återanvändning, d.v.s. att inte behöva designa och utveckla nya lösningar för återkommande funktioner eller tjänster i en organisation (företrädelsevis på en övergripande organisatorisk nivå och inte mindre funktioner inom en applikation, där kommer Microservices in som vi återkommer till strax). Hög nivå av återanvändning uppnås bl.a. genom att tjänsterna är löst kopplade till varandra.

SOA-tjänster kommunicerar med varandra över ett nätverk, vanligtvis med standardiserade protokoll som exempelvis:

• SOAP Web Services (Simple Object Access Protocol)
• RESTful Web Services (JSON)
• Java Message Service (JMS)
• ActiveMQ eller RabbitMQ

Varje tjänst är utformad för att utföra en specifik affärsfunktion (ofta för att exponera en funktion från ett legacy-system, men tjänsterna kan även byggas från grunden) och kan utvecklas, distribueras och skalas oberoende.

Gudfadern inom SOA anses av många vara Thomas Erl och hans bok ”SOA Principles of Service Design” där han beskriver designprinciperna kring SOA:

1. Service Contracts: Tjänster skall definieras och uttryckas genom standardiserade kontrakt.
2. Service Coupling: Tjänster skall vara löst kopplade (granularitet) som kommunicerar med varandra genom väldefinierade gränssnitt, vilket minskar beroenden mellan tjänster samt möjliggör enklare underhåll, testning och skalbarhet.
3. Service Abstraction: Detaljer i den underliggande tjänsteimplementeringen skall abstraheras bort (döljas).
4. Service Reusability: Tjänsterna skall vara utformade för att vara återanvändbara över flera applikationer, vilket främjar modularisering och minskar dubblering av kod och funktionalitet.
5. Service Autonomy: Tjänsterna bör vara autonoma enheter med egen logik och datalagring. De kan således utvecklas och underhållas oberoende.
6. Service Statelessness: Tjänsten upprätthåller inget eget internt tillstånd. All data skickas in (förutom kanske referensdata), beräknas och resultat returneras. Det finns alltså inget att kopiera eller underhålla mellan flera instanser. Även om detta är idealiskt, är det inte alltid praktiskt genomförbart.
7. Service Discoverability: Tjänsten ska vara upptäckbar med metadata (maskinläsbar) som gör att en tjänstekonsument kan upptäcka och förstå tjänsten.
8. Service Composability: Tjänster bör kunna sättas samman till större enheter (sammansatta tjänster) såväl som orkestrering till en process.

SOA och ESB

Det går inte att prata SOA utan att även prata om ESB (Enterprise Service Bus) som i princip alltid är hjärtat i en SOA-implementation. ESB är ett arkitektoniskt mönster där en centraliserad mjukvarukomponent (ofta del av en större integrationsplattform) hanterar integrationer mellan applikationer. ESB kan exempelvis utföra datamappningar, hantera anslutningar, routa (fördelning av meddelanden), konvertering av kommunikationsprotokoll, hantera potentiell sammansättningen av flera förfrågningar och sammansatta tjänster (orkestrering).

Det är teoretiskt möjligt att implementera en SOA utan en ESB, men det skulle motsvara att bara ha ett gäng lösa tjänster. Varje applikationsägare skulle då behöva ansluta direkt till den tjänst den behöver och utföra nödvändiga datatransformationer för att möta vart och ett av tjänstegränssnitten. Det medför mycket arbete och skapar betydande underhållsutmaningar i framtiden eftersom varje anslutning är punkt till punkt (hårt kopplat).

Ett bolag som lyckades väldigt väl med sin SOA-satsning var flygbolaget Norwegian som bildades i början av 2000-talet. När de 2008 köpte det svenska flygbolaget FlyNordic lyckades de helt integrera verksamheten, inklusive schemaläggning och bokning, på tre månader, tack vare sin löst kopplade SOA-arkitektur baserad på en ESB. 2007 bestämde de sig för att även starta bankverksamhet och etableringen av banken genomfördes på 6 månader med 50 000 kunder under det första året.

Vad är Microservices?

Amazons definition (fritt översatt till svenska) är:

Mikrotjänstarkitekturer består av mycket små och helt oberoende programvarukomponenter, kallade mikrotjänster, som specialiserar sig och fokuserar på enbart en uppgift.

IBMs definition (fritt översatt till svenska) är:
Mikrotjänster, eller mikrotjänstarkitektur, är ett molnbaserat arkitektoniskt tillvägagångssätt där en enda applikation är sammansatt av många löst kopplade och oberoende distribuerbara mindre komponenter eller tjänster.

Microservices är således en arkitekturstil som strukturerar en applikation som en samling små, oberoende distribuerbara tjänster. Varje mikrotjänst är ansvarig för en specifik funktion och kommunicerar med andra tjänster genom lätta protokoll, som exempelvis REST eller meddelandeköer.

Termen "Micro-Web-Services" användes första gången redan 2005 av Peter Rodgers under en presentation på konferensen ”Web Services Edge”. Termen ”Microservices” myntades i mitten av 2011 på en workshop för programvaruarkitekter. Efter att James Lewis presenterade sina idéer om Microservices 2012 började flera IT-företag överväga idén och 2014 hade flera stora företag startat seriösa diskussioner om att investera i det. Konceptet fick fart i samband med att populariteten för virtualisering, molnlösningar, agila utvecklingsmetoder och DevOps kom. Netflix var ett av de första bolagen som framgångsrikt ersatte sin traditionella monolitiska arkitektur med en molnbaserad microservice-arkitektur.

Grundtanken med Microservices är att tjänster skall isoleras, d.v.s. köras i sin egen process inom samma server. Det säkerställer att endast en tjänst elimineras om processen återställs, men om servern startas om kommer den att eliminera alla tjänster. Om alla tjänster körs i samma process kommer alla tjänster att elimineras om processen återupptas.

Centrala egenskaper hos Microservices:

Tjänstedecentralisering: Microservices betonar decentralisering och autonomi, vilket möjliggör att team kan utveckla, distribuera och skala tjänster oberoende. Detta möjliggör snabbare utvecklingscykler och bättre anpassning till organisatoriska strukturer.

Granulär skalning: Microservices möjliggör granulär skalning, där enskilda tjänster kan skalas oberoende baserat på deras resurskrav och arbetsbelastning. Syftet är att förbättra resursutnyttjandet och minska kostnader.

Polyglot arkitektur: Microservices tillåter att varje tjänst implementeras med det mest lämpliga programmeringsspråket och den mest lämpliga teknologistacken för sina krav. Detta möjliggör för utvecklingsteamen att välja de bästa verktygen för uppgiften, vilket främjar innovation.

Felisolering: Microservices främjar felisolering genom att kapsla in varje tjänsts logik och data. Detta säkerställer att fel i en tjänst inte sprider sig till andra tjänster, vilket förbättrar applikationens övergripande robusthet.

Hur SOA och Microservices förhåller sig till varandra

Både SOA och Microservice (som ibland faktiskt även kallas ”Mini-SOA”) är arkitektoniska paradigmer med grundtanken att bygga skalbara, återanvändbara och flexibla system och applikationer som passar i en snabbrörlig värld av mjukvaruutveckling.

Rätt byggt (bl.a. genom lösa kopplingar) är både SOA-tjänster och Microservices autonoma enheter. Att en tjänst är löst kopplad innebär i optimala fall att den kan anropas utan någon kännedom om hur tjänsten är implementerad i bakgrunden, vilket minskar beroenden mellan applikationer och/eller tjänster. 

Även om SOA och Microservices delar flera gemensamma grundprinciper, skiljer de sig åt på några viktiga områden:

Omfattning (scope): SOA fokuserar primärt på verksamhetsomfattande integration av applikationer och system, medan Microservices syftar till att bygga individuella applikationer eller komponenter.

Granularitet: SOA-tjänster är ofta större och mer grovkorniga och kan omfatta flera funktioner eller förmågor (exempelvis lönehantering), medan Microservices är mindre och mer finkorniga, där varje tjänst endast sköter en enda funktion inom en applikation.

Styrning: SOA innebär ofta centraliserade styrningsmekanismer för hantering av tjänster, medan Microservices främjar decentraliserad styrning, vilket låter team fatta autonoma beslut om sina tjänster.

Bilden nedan illustrerar en jämförelse över hur nämnda arkitektoniska paradigm förhåller sig till varandra.

Sammanfattning

Sammanfattningsvis erbjuder både SOA och Microservices värdefulla tillvägagångssätt för att bygga skalbara och flexibla mjukvarulösningar. Den huvudsakliga skillnaden mellan de två tillvägagångssätten handlar om omfattning (scope). Enkelt uttryckt kan man sammanfatta det som att:

• SOA är en integrationsarkitektonisk stil och ett verksamhetsomfattande koncept. Det gör det möjligt att exponera befintliga applikationer över löst kopplade gränssnitt, som var och en ofta motsvarar en affärsfunktion, vilket gör det möjligt att återanvända funktionalitet i andra applikationer.
  
  
• Microservice-arkitektur är en applikationsarkitektonisk stil och ett applikationsomfattande koncept. Det gör det möjligt att dela upp insidan av en applikation i små bitar som kan ändras, skalas och administreras oberoende av varandra. Den definierar inte hur applikationer pratar med varandra, då är vi tillbaka till verksamhetsomfånget för tjänstegränssnitten som tillhandahålls av SOA.

Självklart är detta en förenklad bild men ur ett affärsperspektiv är omfattning (scope) den avgörande distinktionen. Om man förstår skillnaden i omfattning, inser man snabbt att de två med fördel kan komplettera varandra, snarare än att konkurrera.

Inledningsvis nämnde jag begreppet ”SOA-döden”. Varför var det så många stora SOA-satsningar som inte blev vad man hoppades på? Min åsikt är att satsningarna var för stora. Man gjorde big-bang-införanden där allt skulle tjänstefieras på en gång. Det blev helt enkelt för stort, tog för lång tid och kostade för mycket pengar. De satsningar som ofta lyckades var i mindre skala, där man startade med de viktigaste och mest återanvändbara tjänsterna som stora delar av verksamheten kunde nyttja, för att sen fortsätta att tjänstefiera efter behov. Tilläggas skall att en helt avgörande faktor för alla stora IT-satsningar (SOA eller ej) är att det måste finnas ett välförankrat stöd i vitala delar av verksamheten, det får inte bara vara en satsning från IT-håll (vilket det säkerligen också var i många av de stora SOA-satsningarna i början av 2000-talet).

Så tillbaka till ursprungsfrågan om Microservices har ersatt SOA?

Svaret är Nej, primärt för att de har olika scope. En liknelse kan göras med frågan: ”Har bilen ersatt cykeln?” Ja, kanske vissa säger. Men faktum är att även här är nyckeln olika scope. Bilen har i många fall ersatt cykeln för längre transporter medan cykeln i vissa fall har ersatt bilen (och för vissa alltid varit det enda intressanta alternativet) i det lilla scopet t.ex. i innerstan eller i byn. Så i min värld är SOA i allra högsta grad ett levande och mycket attraktivt arkitektoniskt angreppssätt som i rätt organisation och med rätt angreppssätt kan skapa mycket kostnadseffektiva och ”framtidssäkra” lösningar, gärna i kombination med applikationer byggda med Microservice-arkitektur.