Bewust kiezen voor Web-scale Architecture

Meer doen in minder tijd. Of het nu gaat om snel doorvoeren van wijzigingen met een korte time-to-market, aanpassen van applicaties op basis van de wensen van gebruikers of anticiperen op veranderingen in de markt; de IT-afdeling krijgt steeds minder tijd om wijzigingen door te voeren en moet daardoor flexibeler werken. Alsof dat nog niet alles is, wordt ook de beschikbaarheid van systemen steeds belangrijker. Een compleet applicatie-landschap een paar uur uit de lucht halen voor onderhoud is vandaag de dag onacceptabel.

Gartner heeft de term ‘Web-scale IT’ geïntroduceerd om te beschrijven hoe bedrijven als Amazon, Google, Netflix en Spotify bovengenoemde uitdagingen het hoofd bieden. Toch is de term enigszins misleidend. ‘Web-scale’ gaat namelijk niet alleen over schaalbaarheid. De kern zit hem namelijk in het feit dat deze bedrijven in staat zijn om continu wijzigingen door te voeren en uit te rollen, zonder de beschikbaarheid van hun diensten te schaden (continuous delivery). Dit is ook zeker voor kleinere bedrijven relevant.

Wat is het?
Een Web-scale Architecture (WSA) 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. WSA is niet een eenduidige architectuurstijl, zoals SOA. Het betreft een combinatie van architectuur, design patterns en best practices. WSA is volledig ingericht op flexibiliteit en schaalbaarheid en dit betekent onder andere dat de architectuur zó is opgebouwd dat het doorvoeren van wijzigingen of het uitvallen van services minimale gevolgen heeft voor de beschikbaarheid van het systeem als geheel. De eindgebruiker merkt hier zo min mogelijk van.

Enablers
De flexibiliteit om voortdurend nieuwe functionaliteit uit te rollen en aanpassingen te doen is dus een groot voordeel van WSA. Er zijn inmiddels diverse technieken en practices die ingezet kunnen worden als onderdeel van WSA. Enkele voorbeelden zijn: microservices, Domain Driven Design, Event Driven Architecture en CQRS.

Bij microservices worden applicaties gebouwd op basis van gespecialiseerde onafhankelijke services die onderling communiceren, maar als het ware als losse bouwstenen ingezet kunnen worden. Doordat de services gespecialiseerd zijn in een bepaald deel van de bedrijfslogica (en dus vaak kleiner zijn dan typische services in een SOA), zijn deze eenvoudiger en met minder consequenties te vervangen. Dit zorgt voor meer flexibiliteit.

Domain Driven Design betreft een methodiek voor softwareontwerp die zich primair richt op de onderhoudbaarheid van software op de lange termijn. Door een systeem te ontwerpen op basis van een model dat zo dicht mogelijk bij de daadwerkelijke bedrijfsprocessen ligt (wat betreft gedrag en terminologie), wordt onnodige technische complexiteit vermeden.

Event Driven Architecture (EDA) is een architectuurstijl waarbij applicaties (services) niet direct aan elkaar gekoppeld zijn. Wanneer zich een event voordoet (een specifieke verandering, zoals: ‘klant plaatst bestelling’) wordt er een notificatie afgegeven op basis waarvan relevante services in actie komen. De geringe koppeling tussen services levert flexibiliteit op.

CQRS, oftewel Command Query Responsibility Segregation is een patroon waarbij het muteren van gegevens (via commands) en het lezen van gegevens (middels queries) strikt van elkaar gescheiden worden. Er wordt gewerkt met twee verschillende datamodellen – en vaak zelfs verschillende databases. Eén model voor het lezen van data en één voor het schrijven van data. Deze aanpak zorgt ervoor dat schrijven en lezen apart van elkaar kunnen schalen. Daarnaast kan het leesmodel worden geoptimaliseerd voor de specifieke manier waarop de gegevens moeten worden weergegeven. Dit levert een betere performance op.

Lange termijn
WSA is een keuze voor de lange termijn. Zeker in het begin zullen ontwikkelteams 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 daarom de ruimte en de tijd om klein te beginnen en te wennen aan de nieuwe concepten en werkwijzen. Het is beter om functionaliteit opnieuw te bouwen (refactoring) als het team er geen vertrouwen in heeft, dan achteraf aanpassingen door te voeren. Zelfs als dat ten koste gaat van de hoeveelheid functionaliteit die wordt opgeleverd. Iedere implementatiekeuze moet wel helder worden onderbouwd. Hierdoor moet je wel steeds opnieuw een kosten-batenanalyse maken, bij iedere keuze.

Uiteindelijk moet de ingebruikname van WSA leiden tot waarde voor gebruikers (intern, partners en eindklanten) in de vorm van betere beschikbaarheid en het sneller doorvoeren van wijzigingen. Het is een leerproces, maar met WSA kunnen organisaties uiteindelijk op een agile manier systemen bouwen die een hoge mate van beschikbaarheid en flexibiliteit bieden, en een werkwijze omarmen die is gebaseerd op continuous delivery. Op basis van de juiste afweging is WSA dan ook absoluut de investering waard.

Door Edwin van Wijk, IT solution architect bij Info Support