Två hypade teknologier, SOA och molntjänster (på engelska Cloud Computing) . SOA har många förklarad som dött. Delvis fel enligt mig. Sedan finns det de som fyllt begreppet med så många associationer att man tycker begreppet i sig är dött. SOA har inget buzz längre, men innehåller viktiga principer för att kunna bygga hållbara distribuerade system. Molntjänster, å andra sidan, är på toppen av sin hype, och där väntar vi fortfarande på en accepterande majoritet.

För att lyckas i sin molnsatsning är SOA en nödvändig pusselbit. Jag ska förklara min syn på detta.

Vadå SOA?

SOA handlar om att skapa tydligare koppling mellan verksamhet och IT. Det handlar mer om informationsarkitektur än att skapa web services eller slänga in en broker (t ex BizTalk) och skapa nya orkestreringar ovanpå sin arkitektur med tjänsteändpunkter. Det handlar om att skapa autonoma och löst kopplade informationsdomäner (eller allmänt kallat services).

Udi Dahan har som alltid en förnuftig syn på det här, exempelvis. Han blandar in event-driven arkitektur med artefakter som commands och events (distribution med pub/sub och service bus). För att reda ut begreppsförvirring mellan SOA och DDD har han dessutom myntat begreppet ABC (Autonomous Business Component = service (SOA) = bounded context (DDD)). Inom en ABC kan vi i vissa passande fall välja att använda CQRS.

En tidig ikon inom SOA är Pat Helland, metaforernas mästare. Mest känd för Metropolis. Helland har skrivit en annan artikel som diskuterar distribuerade system och SOA. Utgångspunkten är löst kopplade (meddelande-baserade) system med minskade krav på konsistens (eller om jag för göra en egen tolkning, det vi kallar eventual consistency) till skillnad från att lägga en distribuerad transaktion och få synkronicitet och konsistens.

Vad har det här med molnet att göra?

Först ett konstaterande. De flesta företag kommer inte att gå all-in vad gäller molnet. Nej. De kommer inte flytta alla sina system till molnet. Möjligtvis med undantag av start-up-företag, som inte har något arv med legacysystem osv. Om ett företag inte har en bra SOA, hur kan man då börja partitionera ut delar till molnet? Det går att bryta isär system med ”forcerad integration”. Men det optimala är att kunna välja vad som kan flyttas ut i molnet utifrån verksamhetens behov. Fundera på det en stund. Det borde inte vara IT som hindrar verksamheten när nya behov uppstår. Och tvärtom. Om vi har alignment mellan verksamhet och IT borde inga hinder uppstå. I den bästa av världar i alla fall.

En annan aspekt på detta är molnets karaktär. Molnet är instabilt. Molnet kostar pengar utifrån förbrukning. För att vårt system ska klara av denna miljö behöver vi ett system som klarar att maskiner går ner oväntat (lösa kopplingar, asynkrona meddelanden, durabilitet). Vi behöver kunna skala upp och ut och ner och in vartefter behoven varierar vad gäller resurser. Olika delar belastas olika, vi vill kunna styra detta utifrån verksamhetens behov, dvs styra det på ABC-nivå.

Ytterligare en aspekt är att ett företag har möjlighet att köpa vissa funktioner som en software-as-a-service. Kanske för att nytt behov uppstår. Kanske för att minska kostnad. Kanske för att klara av mer last.

Hur menar du egentligen?

Jag tror ett konkret exempel kan belysa hur jag menar. Kraftigt förenklat, men det är nödvändigt för att inte trassla in sig i det oväsentliga.

Tänk dig ett ordersystem som håller information om ett företags ordrar. Systemet har utvecklats evolutionärt så att det även innehåller information om företagets kunder. Då det uppkom krav att meddela kunder via e-post byggdes även en notifikationsfunktion in i ordersystemet. Figur 1 visar systemet.

Figur 1. Ordersystem med mycket ansvar (inte SOA)

Tänk dig istället följande arkitektur av ordersystemet. Företaget har en duktig arkitekt som byggt upp en löst kopplad eventdriven asynkron arkitektur. Kundhanteringen sköts i en informationsdomän och kommunicerar med omgivande system enbart med hjälp av events. Pub/sub av events kan ske via en service bus (troligen flera instanser, kanske NServiceBus). Se figur 2.

Figur 2. Ordersystem med uppdelat ansvar

Tillbaka till företagets situation. Då företaget växer märker man att olika avdelningar har olika behov. Marknadsavdelningen vill ha tillgång till kundinformation och planera marknadsåtgärder och bearbeta prospekts. Ekonomiavdelningen är mer intresserad av färdiga ordrar och det belopp som ska faktureras.  Försäljningsavdelning (säljarna) vill kunna lägga in prospekts och när de träffar kunder på fältet vill de direkt kunna fylla i den här informationen.

I detta scenario tänker vi oss att företaget skulle vilja prioritera kundhanteringen och börja använda ett CRM-system i molnet. På så sätt kan säljarna komma åt CRM-systemet var de än är och marknadsavdelningen får stöd i sin process att skapa efterbearbetning av kunderna och göra riktade marknadsåtgärder mot vissa segment.  Företaget behöver dessutom inte köpa in ny hårdvara för att drifta CRM-systemet och skapa infrastruktur för att skapa åtkomst för säljarna på fältet.

Vilken arkitektur (figur 1 eller 2) passar bäst om företaget vill genomföra detta?

Slutlösningen med en hybrid av on-premise och molnet kan se ut enligt bilden nedan.

Figur 3. Ordersystem med användning av molntjänst

Vad har vi uppnått?

Det finns många fördelar med vår SOA-style hybrid arkitektur.

  • Flexibel arkitektur. Vi kan när som helst välja att flytta tillbaka CRM-hanteringen on-premise. Vi kan dessutom välja att flytta ut andra delar, t ex Notifikationsfunktionen, till molnet.
  • Säkerhet. Vi slipper öppna upp åtkomst till det interna kundsystemet mot internet. Vi kan använda t ex Windows Azure Appfabric Service Bus för att skapa koppling mellan molnet och on-premise.
  • Skalbarhet. Molnet har ”oändlig” skalbarhet. Den asynkrona hanteringen tillåter en elastisitet och att vi kan ha kontroll på var flaskhalsar uppstår i systemet och då vidta lämpliga åtgärder (skala upp och ut).
  • Tillgänglighet.  Det asynkrona lösningsmönstret tillåter att maskiner startas om när som helst utan att andra system påverkas. Molnet är oförutsägbart på det sättet att vi inte har kontroll över infrastrukturen, uppgraderingar på plattformsnivå gör att instanser placeras om i datacentret, nätverksteknik (switchar, mm) går sönder, osv.

Slutsatsen

Molnet är en möjlighet; t ex för att skapa skalbarhet, åtkomstbarhet, kostnadsminskning, flexibilitet.

Företag har olika förutsättningar att lyckas med molnet. En viktig förutsättning är att de har en arkitektur som baseras på lösa kopplingar; helst event-drivet, helst asynkront, helst i alignment med verksamheten. En bra SOA helt enkelt.

Att bygga system enligt ovan principer är viktigt om man har molnet i åtanke. Det finns ramverk och lösningsmönster som hjälper oss, några redan nämna. Ett spännande ramverk är Lokad-cqrs, som bygger på dessa principer och dessutom gör det möjligt att sömlöst flytta sitt system mellan molnet och on-premise.

//Peter