Waarom je als CIO niet meer om Micro-Services heen kunt

27 mei, 2021 / Alex Wilbrink

Micro-services — Waarom kiest men voor deze architectuur?

Amazon kennen we als een van de grootste webshops ter wereld. Toch komt een aanzienlijk deel van hun revenuen voort uit het uitbaten van zogeheten micro-services. De overvloed aan publicaties hierover is overtuigend. Een enthousiaste collega begon met de Amazon micro-services gedachte aan het herontwerp van zijn kernapplicatie. Eén à twee jaar ontwikkelen verder is het verhaal genuanceerder. De micro-services architectuur keuze kostte veel extra tijd en was -volgens hem gebleken- zeker geen goede architectuur keuze voor geïntegreerde Enterprise applicaties.

We zetten op een rij wat micro-services zijn, waarom je als CIO voor dit type software-architectuur zou kiezen en kijken waarom de betreffende collega concludeerde dat micro-services niet optimaal zijn voor Enterprise Applicaties (ERP). Heeft hij gelijk? 

 

Wat zijn micro-services?

Er bestaan verschillende architecturen voor de bouw van business applicaties die allen voor- en nadelen hebben. Micro-services is een architectuur keuze, of beter: een architectuurstijl. Hoewel in diverse publicaties niet eenduidig over micro-services wordt gesproken, is de kern dat een grote applicatie opgedeeld wordt in kleinere applicaties – meerdere micro-services. De combinatie van deze micro-services doet functioneel hetzelfde als de oorspronkelijke ‘softwaremonoliet’. 

 

Waarom micro-services?

De argumenten in publicaties over micro-services, vaak gebaseerd op Amazon ervaringen, klinken logisch en aantrekkelijk:  

1. Betere performance 
Met een micro-services strategie deel je monolithische software dus op in kleinere, in zichzelf complexe onderdelen, die alleen noodzakelijke verbindingen hebben naar andere micro-services. Dit maakt het traceren van performance issues eenvoudiger, om deze vervolgens op te lossen.

2. Beter onderhoudbare software 
Kleine applicaties zijn sneller te doorzien, en het individuele kenmerk van micro-services maakt het aanpassingen eenvoudiger en er worden in de regel minder bugs geïntroduceerd. Dit betekent ook dat software sneller doorontwikkeld kan worden. Eindgebruikers kunnen de laatste aanpassingen en nieuwe features sneller ervaren.

3. Herbruikbaarheid
Hergebruik van code is voor softwarebedrijven van strategisch belang. En hoewel ook andere architectuurstijlen dit faciliteren biedt een micro-services aanpak ook dit belangrijke voordeel. De lego-blokjes metafoor, waarbij een product bestaat uit diverse onderdelen, kan op deze manier vormgegeven worden. 

4. Ontwikkelen in meerdere talen 
Micro-services hebben hun eigen codebase en ‘praten’ onderling via standaardprotocollen. Hierdoor is het mogelijk dat elke micro-service in een andere ontwikkeltaal geschreven wordt. Een voorbeeld uit de maakindustrie: de combinatie van MES functionaliteit met IoT gegevens kan met een micro-services opzet samenhangend worden aangepakt. IoT vraagt om een time-series database en een phyton-achtige interpretatie logica – naast de meer klassieke MES functionaliteit.   

5. Een hogere ontwikkelsnelheid
Naast de technische mogelijkheden van micro-services, biedt dit type softwarearchitectuur ook focus binnen het development team. Door te concentreren op een of meer specifieke micro-services krijgen de teams meer onafhankelijkheid van elkaar en wordt daarmee de ontwikkelsnelheid bevorderd.

 

Waarom zou je niet voor micro-services kiezen?

Bovenstaande argumenten lijken sterk en onweerlegbaar. Tegelijkertijd blijkt de keuze van de hierboven genoemde collega achteraf minder voor de hand liggend. Een en ander is afhankelijk van onderstaande condities: 

Toch weer complex – meer kans op fouten?
Een probleem met een micro-services -architectuur kan zijn dat de talrijke samenhangende micro-services als geheel weer veel complexer is dan een niet micro-services gebaseerde systeem. Een Enterprise Applicatie die bestaat uit een combinatie van op verschillende ontwikkeltalen gebaseerde micro-services, databases, logica, messaging, deployment, et cetera kan uiteraard ook op de veelheid aan raakvlakken fouten veroorzaken; daarmee kan het voordeel van een overzichtelijke architectuur teniet worden gedaan. De vraag is dus waar de balans doorslaat ten nadele van een micro-services georiënteerde architectuur. Een delicate keuze waarover je vooraf goed moet nadenken. 

Ontwikkelteams die er nog niet aan toe zijn?
In het geval van onze collega bleek dat het ontwikkelteam niet voldoende doordrongen was van de ontwerpprincipes van een micro-services gebaseerde architectuur. Er werd ook veel tijd besteed aan tooling om de nadelen van micro-services op te vangen met als gevolg veel vertraging en het onvoldoende waarmaken van de micro-services belofte. Het vergt een omslag in denken van ontwikkelaars en dus een degelijke voorbereiding van de ontwikkelteams.

 

Micro-services versus de maakindustrie

De vraag is nu: is het gebruik van micro-services zinvol binnen business applicaties in de maakindustrie? Je zou zeggen van wel. ERP staat voor velen gelijk aan complex, log, onderhoudsgevoelig en niet meer in staat tot innovatie. 

Het team van Togetr kent inmiddels de voordelen van een micro-services georiënteerde architectuur en heeft de nadelen goeddeels weten te neutraliseren. Het blijkt mogelijk om samenhang te bieden in een ERP systeem met een veel eenvoudigere architectuur. Klanten kunnen daarbij, afhankelijk van de behoefte, hun systeem uitbreiden met op micro-services gebaseerde Togetr applicaties. De verkoopafdeling implementeert Togetr CRM, een assemblagefabriek het moderne Togetr MES al dan niet gecombineerd met Togetr Planning en PLM; tegelijkertijd zijn deze ook als standalone applicaties beschikbaar. 

 

Onze statements over micro-services 

Het is inmiddels onweerlegbaar dat grote bedrijven succes hebben met micro-services. Ook voor business applicaties in de maakindustrie is deze benadering van belang. De toenemende heterogene eisen die gesteld worden aan technologie maakt een micro-services strategie namelijk onontkoombaar. 

De definitie van de grenzen van de micro-services volgen de business case en bieden een meer flexibel business systeem. Integraliteit en flexibiliteit moeten uiteraard gezamenlijk evenwichtig worden gewogen. Het bereik en afbakening van een micro-service zijn daarbij delicate keuzes met vergaande consequenties als het gaat om complexiteit versus  flexibiliteit.  

Micro-services bieden zowel klanten als ook development teams mogelijkheden om samenhangende onderdelen van het applicaties landschap, standalone te ontwikkelen en te implementeren.  

We denken dat ook de wat sceptisch geworden collega in de toekomst gebruik zal maken van micro-services. 

Wat vind jij? We zijn benieuwd wat jouw visie is op micro-services!

Neem contact met ons op >>