Steeds meer organisaties zijn op zoek naar een manier om hun IT systemen zodanig op te zetten dat ze voldoende flexibiliteit bieden om snel (met een korte TTM) wijzigingen door te kunnen voeren. Denk daarbij aan zaken als wensen van de gebruikers, veranderende marktomstandigheden, wetswijzigingen, enzovoorts. Daarnaast zien we steeds vaker dat bedrijven het nieuwe werken introduceren. Mensen werken op afstand en op tijden dat het hen het beste uitkomt. Dit zorgt ervoor dat ook een hoge mate van beschikbaarheid van de systemen nodig is. Een compleet applicatielandschap een paar uur (of soms een heel weekend) uit de lucht halen voor onderhoud is dan niet acceptabel.

In 2013 heeft Gartner de term ‘Web-scale IT’ geïntroduceerd (zie het oorspronkelijke artikel). Hiermee wordt de IT bedoeld die bedreven wordt bij bedrijven als Amazon, Google, Netflix, Spotify, enzovoorts. De term is daarbij ietwat misleidend, aangezien het niet puur over grote schaal gaat. De kern zit hem in het feit dat deze bedrijven in staat zijn om continue met een korte TTM wijzigingen door te voeren en uit te rollen (te releasen naar eindgebruikers), zonder de beschikbaarheid van hun diensten te schaden (Continuous Delivery). Gartner stelt tevens dat niet alleen de genoemde Internetbedrijven met hun miljoenen gebruikers wereldwijd kunnen profiteren van Web-scale IT. Ook kleinere bedrijven kunnen voordeel halen uit de snelheid en flexibiliteit die Web-scale IT biedt. Belangrijke toevoeging hierbij is wel dat wordt gesteld dat een organisatie die Web-scale IT wil invoeren, bereid moet zijn om conventionele ideeën en werkwijzen te heroverwegen.

Wanneer we kijken naar de manier waarop de eerder genoemde Internetbedrijven zijn geëvolueerd tot Web-scale organisaties, dan zien we dat software architectuur hier een grote rol in speelt. De manier waarop zij hun software realiseren, bepaalt in grote mate het succes. Dit is waar Web-scale architecture (WSA) komt kijken. Info Support heeft Web-scale architecture geadopteerd als naam voor een software architectuur die Web-scale IT ondersteunt. Dit is uiteraard een vrij brede definitie, maar in dit artikel gaan we dieper in op wat wij onder WSA verstaan. Daarnaast geven we een aantal richtlijnen die u kunnen helpen om te bepalen of Web-scale IT voor uw organisatie van belang is en hoe dit uw organisatie kan helpen om op een Web-scale manier te gaan denken en acteren.

Definitie

Info Support positioneert Web-scale architecture als volgt:

Een Web-scale architecture stelt een organisatie in staat om op een Agile manier systemen te bouwen die een hoge mate van beschikbaarheid en flexibiliteit bieden en een Continuous Delivery werkwijze ondersteunen.

Uit de definitie is te destilleren dat we WSA niet zien als een top-level architectuurstijl zoals bijvoorbeeld SOA. We zien het meer als een verzameling patterns en practices. De meeste van deze patterns en practices zijn ook niet nieuw en sommigen daarvan kunnen prima gecombineerd worden met andere architectuurstijlen.

In relatie tot WSA wordt vaak ook het Reactive Manifesto genoemd. De eigenschappen van een systeem dat op basis van WSA is gebouwd, voldoet vaak aan (een deel van) de eigenschappen die in dit manifest zijn beschreven.

In de volgende paragraaf beschrijven we de patterns & practices die we ondersteunend aan WSA beschouwen.

Patterns & practices

Voor het realiseren van een IT systeem met Web-scale eigenschappen, is er een groot aantal software patterns en werkwijzen (practices) beschikbaar. Info Support heeft een selectie gemaakt van een aantal van deze patterns en practices op basis van de bijdrage die ze kunnen leveren bij het implementeren van op WSA gebaseerde systemen.

De volgende zaken hebben we als primaire enablers voor WSA onderkend:

• Domain Driven Design – een aanpak waarbij het systeem volledig wordt ontworpen en gebouwd rond domeinen die men kent in de business.
• Microservices – een architectuurstijl waarbij autonome specifieke services samenwerken en asynchroon communiceren.
• CQRS – een software pattern waarbij mutaties en lees-acties strikt van elkaar worden gescheiden.
• Event Driven Architecture – een architectuur stijl waarbij wordt gecommuniceerd middels events (asynchroon).
• Event Sourcing – een aanpak waarbij de state van een object niet wordt opgeslagen in een genormaliseerd database schema, maar als een lijst met de events die in de tijd zijn opgetreden.
• Polyglot persistence – een aanpak waarbij per situatie of context (ook binnen 1 systeem) de best passende opslagmethodiek wordt gehanteerd.
• NoSQL – een manier van gegevensopslag waarbij de gegevens niet in een relationeel model worden opgeslagen, maar op een andere manier (bijvoorbeeld als documenten of als een graaf van objecten).
• Actor Model – een manier om systemen te bouwen die een grote workload aan kunnen d.m.v. het verdelen van de workload over verschillende actors (parallellisatie). Elke actor is autonoom en kan indien nodig zelf nieuwe instanties van actors creëren om het werk te kunnen doen. Er zijn verschillende frameworks beschikbaar voor het bouwen en hosten van actors. Deze frameworks zorgen er o.a. voor dat een actor zelf geen rekening hoeft te houden met concurrency issues.

De beschrijvingen bij deze onderwerpen zijn slechts een korte introductie. Elk onderwerp behelst uiteraard veel meer. Het gaat echter te ver om deze zaken in dit artikel in detail te beschrijven. Dit hebben we wel gedaan in een boek over WSA. Download hier de PDF van het boek.

Is Web-scale architecture iets voor uw organisatie?

Veel organisaties zullen zich afvragen: “Moeten we nu weer een nieuwe hype volgen, we zijn net gewend aan SOA?”. Dit is op zich een logische vraag, maar de echte vraag zou moeten zijn: “Hebben we op dit moment problemen die we wellicht met een Web-scale architecture zouden kunnen oplossen?”. Kortom: als u en uw klanten tevreden zijn over de huidige werkwijzen en systemen, dan is er geen reden om naar WSA te kijken. Juist wanneer u het idee heeft dat er meer in zit wat betreft de IT systemen, dan is het wellicht handig om over het inzetten van WSA te gaan denken.

Daarnaast is een vuistregel dat WSA (en dan net name Domain Driven Design (DDD)) vooral kan helpen bij complexe systemen. Als het domein waarvoor een systeem wordt gebouwd weinig complexiteit kent, is de DDD aanpak vaak overkill. Hier wordt met name functionele complexiteit bedoeld, niet technische of infra-structurele complexiteit.

We zien in de praktijk namelijk dat het realiseren van systemen op basis van een WSA een stuk complexer kan zijn dan de inmiddels meer traditionele architecturen die we in het wild zien. SOA is bijvoorbeeld een veel gebruikte architectuurstijl die inmiddels redelijk uitgekristalliseerd is. Voor veel van de uitdagingen die in een dergelijke architectuur vaak van toepassing zijn, zijn inmiddels wel ergens in de literatuur of op het Internet oplossingen beschreven. Dit is voor WSA nog minder het geval. Alvorens blind voor WSA te gaan, moet in ieder geval helder zijn welke problemen opgelost moeten worden met WSA en moet men het eens zijn dat de voordelen opwegen tegen de extra investering die nodig is om WSA in te zetten.

Cloud Computing

Cloud Computing is een thema dat in veel organisaties een rol speelt. Organisaties die reeds stappen hebben gezet om (een deel van) hun systemen in de cloud te plaatsen, zullen beamen dat dit ook eisen stelt aan de architectuur van deze systemen. Goed om te weten is dat de eigenschappen van een systeem op basis van een WSA prima aansluiten bij de eigenschappen die nodig zijn om een systeem in de cloud te kunnen plaatsen.

WSA vs. SOA

De titel van deze paragraaf is enigszins misleidend. Info Support ziet WSA namelijk niet als een directe vervanger van SOA, maar als een mogelijke aanvulling op SOA. Dat betekent ook dat WSA prima kan worden ingezet binnen een organisatie die reeds SOA inzet. Daarnaast is het 100% adopteren van WSA voor alle systemen niet nodig om toch voordelen uit de WSA te kunnen halen. De reden waarom we de paragraaf toch zo hebben genoemd is dat we in de traditionele SOA architecturen wel een terugkerend probleem zien waar veel organisaties mee te kampen hebben. Dit probleem is de coupling tussen de verschillende services. Dit is tevens een van de issues die er voor zorgen dat de beschikbaarheid van een systeem niet gegarandeerd kan worden.

We zien in de praktijk namelijk vaak dat de SOA architectuur bij een organisatie compleet loosely-coupled wordt opgezet. De services hebben expliciete contracten, delen alleen deze contracten met de buitenwereld (en delen geen code), hebben hun eigen data-opslag die alleen via de service te benaderen is, enzovoorts. Op zich allemaal prima eigenschappen die ook in een WSA gelden. Echter, over het algemeen zien we dat in een SOA de gegevens die bij een bepaald domein horen slechts op 1 plek worden beheerd door een service (zeg de bron-service) en alle overige services deze bron-service moeten aanroepen om over deze gegevens te kunnen beschikken. Op zich is het goed om gegevens slechts op 1 plek vast te leggen en te muteren. Het probleem dat hierin echter schuilt is dat wanneer de bron-service om wat voor reden dan ook offline is, alle andere services hun werk niet kunnen doen. Dit betekent dat door het uitvallen van 1 service, het systeem als geheel niet beschikbaar is voor de gebruikers. Mocht dit iets zijn dat u herkent uit uw IT landschap, dan is WSA wellicht iets om naar te kijken.

Een pattern dat kan helpen bij het daadwerkelijk autonoom maken van services is CQRS. Door bepaalde afnemende systemen een lokale cache (in CQRS termen een ‘read-model’) te laten opbouwen van de gegevens die ze nodig hebben om hun werk te kunnen doen, worden deze systemen echt autonoom. Als de bron-service offline is, kunnen de overige systemen nog wel hun werk doen en zal slechts een klein deel van de beschikbare functionaliteit niet beschikbaar zijn voor de gebruikers. Gebruikers die in hun werk geen gegevens muteren die door de bron-service worden beheerd, zullen niet eens merken dat deze service offline is. Het bijwerken van de lokale caches kan bijvoorbeeld op basis van events die door de bron-service worden gepubliceerd bij iedere mutatie.

Wat is er nodig voor de invoer van WSA?

Zoals eerder aangegeven is een systeem bouwen op basis van een WSA complexer dan wanneer een meer traditionele architectuurstijl als SOA wordt gehanteerd. Dit zit hem o.a. in het feit dat services daadwerkelijk autonoom en losgekoppeld van elkaar worden ontwikkeld. Ondanks de voordelen die dit met zich meebrengt, levert het ook een aantal uitdagingen op waar een oplossing voor moet worden gevonden. Denk bijvoorbeeld aan het waarborgen van consistentie van de gegevens in een applicatielandschap (hoe om te gaan met transacties e.d.). De patterns en practices die eerder zijn genoemd kunnen vooral bij deze zaken uitkomst bieden.

De teams

Uiteindelijk gaat het vooral om het vakmanschap van de teams die de systemen bouwen. De mensen in deze teams moeten goed bekend zijn met de WSA patterns en practices. Hierover is veel informatie te vinden, zowel in boekvorm als op Internet. Daarnaast is hands-on ervaring van het team met de nieuwe concepten van grote waarde. Dit vergroot het vertrouwen van het team en maakt het team beter. Consultants van Info Support worden ook vaak in een coachende rol aan een team bij de klant toegevoegd om zodoende dit team te helpen bij de adoptie van WSA.

De aanpak

Een zeer belangrijk onderdeel van de aanpak in de transitie naar WSA, is het mogen maken van fouten (tevens een belangrijke pijler van Continuous Delivery). WSA is iets dat voor de lange termijn wordt ingevoerd. Zeker in het begin zullen teams nog erg worstelen met nieuwe concepten waarvan ze nog niet precies weten hoe ze deze moeten toepassen en wat de impact ervan is op hun werkwijze. Geef teams de ruimte en de tijd om klein te beginnen en te wennen aan de nieuwe concepten en werkwijzen. Reserveer daarom ook ruimte in uw planningen voor uitloop. Het is beter om technical debt direct aan te pakken en iets opnieuw te bouwen als het team er geen vertrouwen in heeft. Zelfs al gaat dat ten koste van de hoeveelheid functionaliteit die wordt opgeleverd. Help het team daarbij wel door telkens te vragen naar een heldere rationale achter elke implementatiekeuze. Dit zorgt ervoor dat het team telkens gedwongen wordt om een kosten / baten analyse te maken voor de gemaakte keuzes. Uiteindelijk moet alles namelijk leiden tot waarde voor de gebruikers in de vorm van betere beschikbaarheid en een kortere TTM van wijzigingen.

Hoe nu verder?

In dit artikel hebben we een overview gegeven van Web-scale architecture. We hopen dat u hiermee een beter beeld heeft gekregen en kunt bepalen of Web-scale architecture iets voor uw organisatie kan betekenen.

Zoals aangegeven zullen er een aantal artikelen met als thema WSA verschijnen waarin de verschillende patterns en practices die we als enablers voor WSA onderkennen in detail zullen worden beschreven.

Wilt u meer informatie over Web-scale architecture of heeft u hulp nodig bij de adoptie van Web-scale Architecture binnen uw organisatie, neem dan contact op met Info Support.

Web-scale Architectuur Boek

Info Support heeft een boek uitgebracht waarin de concepten van WSA worden beschreven en een beeld wordt geschetst van de problemen waarvoor WSA kan worden ingezet. Download hier de PDF van het boek.