De weg naar een microservice-architectuur

ABF groeit hard. En gezonde groei vergt voorbereiding zodat je op de nieuwe situatie berekend bent. Enerzijds vraagt dat extra mankracht. Anderzijds praat je over systemen die alles bij kunnen benen. Hier ligt een schone taak voor onze Developers. Zij moeten voldoen aan de constante vraag naar nieuwe functionaliteiten. Om het maximale uit de beschikbare tools te halen, is gekozen voor het opzetten van een microservice-architectuur.   

Een klein stukje geschiedenis

We beginnen met een klein stukje geschiedenis om een beeld te schetsen van ons uitgangspunt. De applicaties waar we al langere tijd mee werken, zijn geschreven op basis van C# (.NET Framework 4.6.1) – een mix van MVC, API en consoleapplicaties. Voor het uitrollen van deze applicaties was een deel van de OTAP-straat aanwezig – automatisch uitrollen naar acceptatie en semiautomatisch (met een druk op de knop) uitrollen naar productie. Een geschikte basis om de dagelijkse werkzaamheden succesvol uit te voeren.

“Meer Developers alleen is niet genoeg”

Begin dit jaar is echter besloten dat het development-team sneller (en meer) moet ontwikkelen om aan de alsmaar groeiende vraag naar nieuwe functionaliteiten te voldoen. Met de huidige softwareopzet is teamuitbreiding alléén niet genoeg om de beoogde ontwikkelsnelheid te halen. Fundamentele aanpassingen zijn daarom nodig, zoals het opzetten van een nieuwe architectuur. En dat is makkelijker gezegd dan gedaan. Zoals Marc Mathijssen al in een eerder blog beschreef brengen microservices een hoop complexiteit met zich mee. Maar met een dergelijke microservice-architectuur lijken we wel aan de beoogde vraag te kunnen voldoen. Alle reden dus om uiterst zorgvuldig een vervolgtraject uit te stippelen. Hoe nemen we de complexiteit van een microservice-architectuur weg? Stoppen we met de ontwikkelingen van de huidige applicaties? Zetten we alle uren op nieuwe architectuur in? Uitgesloten. De zaken gaan tenslotte gewoon door.

Oud en nieuw naast elkaar

De oplossing zoeken we dan ook in een andere hoek. We richten onze pijlen op een én-én-situatie: een hybride omgeving waarin oud en nieuw naast elkaar kunnen bestaan. We creëren eerst een landschap waarin we microservices kunnen draaien. Hiermee vangen we de complexiteit van een microservice-architectuur in automatische processen. Zo hoeven we de ontwikkelaars hier niet mee te belasten. Denk hierbij o.a. aan het opzetten van een volledige OTAP-straat. Ook moeten we de werkwijze, waarmee we tot nu toe hebben gewerkt, aanpassen om ‘continuous integration’ te omarmen. Het grote voordeel hiervan, in goed Nederlands: op het moment dat een ontwikkelaar zijn code pusht gaat dit automatisch naar productie. Quality gates moeten daarbij waarborgen dat de code voldoet aan onze standaarden. En vanaf daar kunnen we starten met het overhevelen van bedrijfsprocessen van “oud” naar nieuw.

“Met de microservice-architectuur kan een commit van een ontwikkelaar direct naar productie worden gepusht”

Inmiddels hebben we de basis van onze microservice-architectuur staan. En zijn twee belangrijke stromen overgezet: de offertes en bestellingen.

De blauwdruk van onze structuur ziet er als volgt uit:

• De microservices zijn ontwikkeld met .NET Core 3.1 (REST API, C#) – zodat we niet gebonden zijn aan een Windows-hosting-omgeving
• De communicatie met en tussen de microservices verloopt via een messagebus – zodat de services onderling niet te “hard” met elkaar gekoppeld zijn
• Microsoft DevOps gebruiken we voor het inrichten van de OTAP-straat
• Dit alles draaien we in Kubernetes – in een Azure-cluster

We zijn er nog niet, maar hebben we al grote sprongen gemaakt. Waarbij we zowel onze microservice-architectuur verder opzetten, als nieuwe functionaliteiten introduceren.

Meebouwen aan onze microservicce-architectuur?

We zoeken developers! Je bent van harte welkom. Zie onze vacatures voor meer informatie.