Businessuitdagingen bij een microservice-architectuur

De afgelopen periode is er intensief gewerkt aan de basis van een nieuw TrueCare, het communicatiesysteem voor alle services en support die True biedt. We hadden namelijk een flinke uitdaging: legacy moest samengevoegd worden tot één nieuwe interface. Al snel wisten we dat een microservice-architectuur zou helpen in de transitie naar één TrueCare. In dit artikel deelt Peter van Kleef, Project Manager & Product Owner van TrueCare, de inzichten, uitdagingen en afwegingen bij de architectuur vanuit een businessperspectief.

Lees ook ons vorige artikel over legacy en een microservice-architectuur. 'Hoe een microservice-architectuur ons helpt om legacy te tackelen'. Dit artikel gaat in op het businessperspectief van microservices. Ben je benieuwd naar onze technische aanpak? Lees dan 'De technische aanpak van onze microservice-architectuur'.

Tijd voor een plan

In de vorige blogpost ben ik ingegaan op het waarom van een microservice-architectuur bij True. De uitdagingen waren bekend maar hoe maak je vervolgens een begin aan het traject van het herbouwen van bestaande applicaties en functionaliteiten?

Alle bestaande functionaliteit herschrijven is een gigantische klus. Dat gaat niet over een nacht ijs, en doe je niet even tussen de bedrijven door – dat wisten we vanaf het begin. Om tot een werkbare oplossing te komen hebben we daarom eerst drie basisregels gedefinieerd.

Regel 1 – “We gebruiken een vaste stack frameworks”

We kozen voor een vaste set van front-end en back-end frameworks. In een microservice-architectuur helpt dit om efficiënter te ontwikkelen. Ook haalt het een hoop complexiteit weg. Een paar voordelen:

• Het aanleren van (en wijzigingen in) frameworks is eenvoudiger, ook bij nieuwe developers
• Standaardisatie is binnen handbereik; iedereen in het team spreekt dezelfde talen
• Je hoeft niet constant opnieuw uit te zoeken welke frameworks je gebruikt per functionaliteit
• Je creëert ruime voor het ontwikkelen van een vaste basis – in ons geval de AppSkeleton

Regel 2 – “We gebruiken een AppSkeleton”

De AppSkeleton is onze basis geworden voor het ontwikkelen van iedere nieuwe microservice. Zie dit als de prefab-onderdelen voor een huis. De fundering, de muren en de plafonds zijn klaar. Het in elkaar zetten, borgen en decoreren is wat we daarna nog moeten doen. De AppSkeleton heeft nog meer grote voordelen:

• Het is de basis voor iedere microservice die we ontwikkelen
• Nieuwe microservices kunnen apart geüpdatet worden bij wijzigingen aan de skeleton
• Is gelijk de basis voor ieder (nieuw) te ontwikkelen microservice;
  • Er zijn CI/CD-parameters gedefineerd
  • Er is bepaald hoe we omgaan met Event Sourcing
  • Er is een basis gelegd voor de API-structuur
  • OAuth2-implementatie – een autorisatieframework – zit erin verwerkt

Regel 3 – “We passen Event Sourcing toe”

We zagen Event Sourcing als een manier om bij te houden welke wijzigingen er plaatsvinden. De voordelen van Event Sourcing:

• Je hebt een volledige audit trail – Wie doet wat? Welke wijzigingen zijn er gemaakt? Hoe veel wijzigingen zijn er doorgevoerd?
• Je kunt eenvoudig zien hoe het er voor staat qua performance

De vervolgstappen

Na de basisregels en het helder schetsen van de technische wensen en eisen, wisten we als business en developmentteam waar we naartoe wilde werken. Na het afwegen van de voor- en nadelen ging de kogel door de kerk.

1. 1. Kansen – Een eerste kans om het plan in werking te stellen bood zich al snel aan. Vanuit verschillende stakeholders (klanten, de business en medewerkers) kwamen veel wensen en eisen naar voren met betrekking tot de DNS en SSL-functionaliteiten. Deze functionaliteiten waren onderdeel van de ‘oude’ TrueCare en het ‘oude’ administratiepaneel en dat moest veranderen. Dit was een mooi startschot om verdere functies te onderzoeken.
   2. Onderzoek – Na een onderzoek naar de huidige werking en functionaliteiten en een (volledige) inventarisatie van de wensen en eisen met betrekking tot de toekomst kam er een eerste backlog op gang. Hier stonden alle functionaliteiten op die we aan wilden pakken.
   3. Planning- Uit deze backlog kwam een planning voort. In deze planning namen we ook het opzetten van Event Sourcing en de ontwikkeling van de AppSkeleton mee. We wisten dat de oplevering van de eerste microservices daardoor vertraging zou oplopen. Desondanks zagen we het als valide investering met het oog op de toekomst. Hierdoor kunnen we nu slimmer nieuwe microservices toepassen.
   4. Iteraties – Naar aanleiding van deze samengestelde backlog en planning (samengesteld uit zowel user stories en developmentstories) is ons developmentteam aan de slag gegaan met de eerste microservices.

Uitdagingen en afwegingen

Uiteraard waren er ook een aantal uitdagingen en afwegingen die we gaandeweg zijn tegengekomen.

Zo was het investeren in de ontwikkeling van de AppSkeleton een belangrijke afweging. De basis moest in orde zijn omdat we toekomstige microservices goed en snel wilde uitrollen. Dit had echter nog wel impact op de microservices die we op wilden leveren. Het was een redelijk complexe exercitie en bracht veel overleg met zich mee. Maar het werd wel gezien als legitieme investering.

We besloten ook om Event Sourcing toe te passen, maar dan op een andere manier. Tijdens de implementatie van Event Sourcing kwam men namelijk ook achter wat nadelen. Die nadelen deden zich vooral voor op het gebied van performance en het snel en eenvoudig kunnen opzoeken van de huidige staat. Daarom kozen we voor een hybride vorm van Event Sourcing: we slaan ook de huidige staat op.

Door de events op te slaan is er een volledige audit-trail. Ook kunnen onze Data Scientists veel meer bruikbare informatie uit de verschillende systemen halen. Door het opslaan van de huidige staat kunnen we informatie sneller tonen, ontstaan er geen performance problemen en kunnen queries makkelijker op de database losgelaten worden.

Een andere uitdaging was een logisch gevolg van de toepassing van microservices, namelijk complexe omgevingen. Iedere microservice heeft in principe een eigen omgeving nodig. Zeker als je een OTAP-straat (ontwikkeling/test/acceptatie/productie) hanteert, zoals True dat doet. Dan moet je op elk niveau een omgeving inrichten. Bij True hebben we gekozen om Kubernetes (containersoftware) in te zetten voor onze test- en acceptatie-omgevingen.

Daarnaast is communicatie tussen microservices ook complex. Je wil niet dat het hele proces vastloopt op het moment dat een van de microservices tijdelijk onbereikbaar is. Om dat op te lossen heeft het Development-team een combinatie van API’s, Message Brokers (RabbitMQ) en Webhooks ingericht.

Aanpassing van het plan

Aanvankelijk besloten we de bestaande front-end van de diverse systemen te behouden. Een nieuwe front-end zou uiteindelijk veel tijd kosten, dachten we. Toch konden we het niet geheel laten gaan. Een nieuwe front-end zou beter zijn voor de gebruikerservaring en daarnaast vonden we het ook een leuk project om te doen.

Wat begon als een hobbyproject in eigen tijd, werd uiteindelijk een proof of concept van de nieuwe front-end die we nu nu hebben ingelijfd bij de developmentafdeling. Deze nieuwe front-end leidt er toe dat er een nieuwe front-end zal komen voor de microservices die ontwikkeld worden. Het blijkt weinig impact te hebben op de tijd die geïnvesteerd moet worden, maar biedt wel betere voorwaarden voor de toekomst.

Door de opzet van de nieuwe front-end wordt het mogelijk dezelfde functionaliteiten aan alle klanten van True aan te bieden. Daarnaast wordt duplicatie van code tegen gegaan en is de front-end op de nieuwste standaarden gebaseerd.

TrueCare steeds completer

In dit artikel hebben we het gehad over het plan om onze legacy om te bouwen naar een microservice-architectuur. Een vaste set aan front-end en back-end frameworks, de AppSkeleton en het toepassen van (onze manier van) Event Sourcing helpt ons om TrueCare steeds completer te maken en om nieuwe microservices toe te passen.

Dit hebben we redelijk high-level omschreven. Volgende week gaan we wat meer in op de technische uitdagingen die we tot nu toe zijn tegengekomen. Daar vertellen we onder andere ook wat meer over hoe we omgegaan zijn met autorisatie en authenticatie, een van de eerste microservices die we toe hebben gepast.