Att molnutveckling är poppis är något som de flesta märker av i dag, även äldre plattformar anpassas till det. En anledning till populariteten är att det är enkelt att komma i gång. Men det kan snabbt bli rörigt, som alltid krävs det ett arkitekturtänk i botten när man bygger applikationer, även i molnet.

Men vilken arkitektur ska man välja för sin molnapplikation? Microsoft har en idé om det. På företagets utvecklarblogg presenteras de vanligaste arkitekturmodellerna i molnet, som man ser det på Microsoft. Håll till godo:

Lager på lager

N-tier (flerlager) är en traditionell arkitekturmodell. Applikationer delas upp i flera lager, med olika ansvarsområden. Exempel på lager är presentation, affärslogik och dataåtkomst. Ett vanligt sätt att organisera lagren är att ett visst lager bara kan anropa lager som finns ”under” det i modellen.

Ett problem med den här modellen är att det kan vara svårt att ändra i ett lager utan att andra lager påverkas. Det innebär att det blir problem med kontinuerliga leveranser.

Läs också: Nästa år är det hybrida moln som gäller

Flerlagersmodellen används av naturliga skäl ofta när man migrerar existerande applikationer till molnmiljöer, eftersom det blir, eller åtminstone känns, enklast. Det innebär också att flerlagersmodellen oftast används för applikationer som körs på infrastrukturtjänster, till skillnad från plattformstjänster.

Webbköer

Om man bygger applikationer som körs på plattformstjänster är arkitekturmodellen Web-Queue-Worker (webbköer) ett alternativ. Den bygger på att man har en webbfront som hanterar http-förfrågningar och en serverdel som hanterar uppgifter som är processorintensiva och/eller tar lång tid att köra. Frontdelen kommunicerar med serverdelen via en asynkron meddelandekö.

Den här modellen passar för enkla lösningar som inbegriper resurskrävande uppgifter. Men för mer komplexa lösningar kan det bli problem med att hantera beroenden. Det finns en fara att både frontdelen och serverdelen blir stora, svårhanterliga monoliter. Det kan leda till problem med kontinuerliga leveranser.

Mikrotjänster

Ju mer komplex en applikation är, desto större anledning finns det att använda en arkitektur baserad på mikrotjänster. En sådan består av många små tjänster, som var och en är en implementation av viss funktion. Tjänsterna är löst kopplade till varandra och kommunicerar via kontrakt för api:er.

Olika team kan bygga olika tjänster och de olika tjänsterna kan tas i drift utan att det behövs så mycket koordinering mellan teamen. Det underlättar kontinuerliga leveranser. Den här typen av arkitektur ställer högre krav på mognad, speciellt vad gäller devopskunskaper. Belöningen om man lyckas är snabbare leveranser och en stabilare arkitektur.

Separera stenhårt

Arkitekturmodellen CQRS (Command and Query Responsibility Segregation) innebär att man separerar läs- och skrivoperationer i en applikation, i olika modeller. Att läsning och uppdatering av data separeras får flera konsekvenser. En är att man enklare kan skapa vyer av data som inte direkt speglar databaser som finns, en annan att man kan uppdatera läs- och skrivdelar separat och även använda olika teknik för att bygga dem. Dessutom kan man ha olika grader av skalbarhet för olika delar.

Läs också: Tung bank går mot strömmen – satsar med full kraft på molnet

På Microsoft tycker man att CQRS passar bäst för delsystem, till exempel när många användare ska ha åtkomst till en viss datamängd. Om man tillämpar den för en hel applikation blir komplexiteten onödigt hög.

När det händer

Händelsedriven (event-driven) arkitektur innebär att man använder en modell för att publicera och prenumerera på (konsumera) händelser. Producenterna av händelser är oberoende av konsumenterna och konsumenterna är oberoende av varandra.

Den här modellen passar för applikationer som tar emot och hanterar stora datamängder, med krav på låga fördröjningar, till exempel iot-lösningar. Den passar också om olika delsystem behöver hantera en viss datamängd på olika sätt.

Specialfall

Ibland pratar man om ”big data” och ”big compute” som arkitekturmodeller. Det handlar om hantera stora volymer av data och beräkningar i parallella miljöer.