Marc Blok

Marc Blok

Thought Leader Open Banking

Grootbanken willen meer en meer microservices gebruiken als onderdeel van IT Modernization. Is het gebruik van microservices alleen van toepassing bij het herbouwen van een monoliet applicatie of wil men microservices ook binnen een enterprise omgeving inzetten waar vele relaties bestaan tussen legacy applicaties? Kunnen we überhaupt wel microservices gebruiken zoals ze bedoeld zijn? Deze vraag is vooral van toepassing als wel veel afhankelijkheden hebben met legacy applicaties (buiten de scope van de afdeling die de microservice maakt). Welk probleem willen we eigenlijk oplossen? En is het dan erg als we microservices niet gebruiken zoals ze bedoeld zijn? APIs zijn tevens een belangrijk middel om functionaliteit van de bank aan te kunnen bieden aan de buitenwereld, zowel in context van PSD2 als van commerciële proposities. De CGI Open Finance oplossing draagt bij aan het implementeren van deze proposities.

Wat is een microservice?

Microservices is een architectuur stijl waarbij een applicatielandschap onderverdeeld wordt in kleine services. De services binnen een microservice architectuur dienen een specifieke business functie. Daarbij zijn microservices autonoom, dat houdt in dat ze in de meest pure vorm een eigen datastore hebben.

Microservice 1

Welk probleem lossen we op met microservices?

Microservices zijn zo populair omdat ze een aantal problemen oplossen. De voordelen van microservices hebben veelal te maken met het feit dat microservices in hoge mate autonoom zijn. De belangrijkste voordelen zijn:

  • De verbetering van de maintainability van een applicatie in vergelijk met een als monoliet ontworpen applicatie
  • De enorme schaalbaarheid die voor veel gebruikte microservices mogelijk is (in een cloud omgeving). Dit heeft een kostenaspect in zich, het gaat ook om down-scaling.
  • De grote mate van teamautonomie waardoor een team onafhankelijk releases kan plannen en zelf de technology stack kan kiezen die het beste bij de microservice past. De mate waarin dit mogelijk is hangt ook af van de standaarden binnen de organisatie. Microservices gaan dus prima samen met het DevOps gedachtengoed. Deze teamautonomie verkort de time-to-market.

Wat zijn nadelen van microservices? Microservices hebben natuurlijk niet alleen maar voordelen:

  • Het aantal microservices kan binnen een organisatie explosief stijgen waardoor een spaghetti aan services ontstaat
  • Niet alleen is het complex om een gedistribueerd systeem te ontwikkelen maar ook het beheer is erg complex
  • Het feit dat microservices een eigen data store hebben leidt tot nieuwe uitdagingen bij een ingewikkeld datamodel binnen de organisatie.
  • Integratietesten kunnen ook ingewikkelder worden en version management (verschillende versies van services tegelijkertijd in productie) wordt dan erg belangrijk.
  • Bij microservices wordt vaak voor RESTful webservices gekozen voor de interface. Het gebruik van vele microservices kan daarom tot een vermindering van de performance leiden in vergelijk met een monoliet applicatie.

Bij de bank waar ik gedetacheerd ben is de time-to-market een belangrijke driver om na te denken over hoe de organisatie en architectuur verder verbeterd kunnen worden. Een microservices architectuur in combinatie met DevOps teams is één van de dingen waar we nu naar kijken.

Hoe ziet het architectuur landschap er vaak uit?

Een veel voorkomende multitier architectuur bestaat uit de volgende lagen:

Mircoservice 2
  • presentation layer: een front-end (soms met back-end for front-end)
  • application layer: hier vindt vaak een vorm van orchestratie plaats
  • business layer: de business logica bevindt zich hier. In menig bedrijf zou je hier de (legacy) backend systemen kunnen plaatsen.
  • persistence layer

Waar worden microservices toegepast?

Legacy systemen zijn mainframe applicaties en worden vaak buiten beschouwing gelaten bij de introductie van een microservice architectuur. Het buiten beschouwing laten van deze componenten kan ook een eenvoudige reden hebben: deze componenten horen bij een ander organisatieonderdeel. Binnen een grote organisatie gaat het daarom in de praktijk vooral om de application layer waarbij de specialistische applicaties in stand gehouden worden. Het vervangen van legacy systemen is desalniettemin een belangrijk onderwerp van IT Modernization.

Microservice 3

Zijn het wel microservices?

De vraag is of hetgeen ontwikkeld wordt wel echt microservices zijn. Volgens de eerdere definitie kunnen de services wel voldoen aan een business wens en komt het erop neer dat de bestaande APIs verder opgeknipt worden. Naast specifieke microservices die een back-end systeem aanroepen zijn er vaak bovenliggende services die feitelijk niets anders doen dan orchestratie. Een alternatief hiervoor is een event driven architectuur (choreography pattern).

Eigenlijk is het een soort mix tussen een Service-Oriented Architecture (SOA) en Microservices Architecture:

  • de services zijn meer finegrained dan bij SOA maar niet echt klein
  • de focus lijkt steeds meer op re-use te liggen zoals bij SOA door hergebruik van microservices in de architectuur met de orchestratie van microservices
  • de organisatie kiest nog vaak voor centrale standaarden en technology stack zoals bij SOA
  • DevOps teams blijken in de praktijk lastig te organiseren dus blijft het oude model nog gehandhaafd

Als er sprake is van grote datastores dan kan er gekozen worden voor een oplossing waarbij een bepaalde datastore gesynchroniseerd wordt met een nieuwe datastore bijhorende bij een specifieke microservice. Deze synchronisatie kan op diverse manieren plaatsvinden.

Microservice 4

Worden de doelen dan wel behaald?

De onderhoudbaarheid wordt verbeterd als we de huidige business logica / process services opknippen in kleine microservices met een goed omschreven doel. Maar het zal geen enorme verbetering zijn zoals bij het re-designen van een grote monoliet applicatie.

De schaalbaarheid wordt inderdaad groter en de infrastructuurkosten kunnen omlaag gebracht worden (denk hierbij vooral aan cloud omgevingen). Hier heb ik zelf echter nog geen harde cijfers over.

De team autonomy zal niet veel verbeteren, vaak ontwikkelt het team dat vroeger de grotere service maakte nu de microservices. Een nog belangrijker aspect is echter de dependency met (legacy) back-end systemen waarvan de functionaliteit ontsloten moet worden. Het helpt als er voor een microservice een eigen datastore gebruikt kan worden welke gesynchroniseerd wordt met onderliggende (grote) datastores.

Conclusie

Het lijkt erop alsof we in de praktijk niet altijd echte microservices kunnen maken. In principe is dit niet erg, we moeten eigenlijk nadenken of we de doelen kunnen behalen. De doelen worden gedeeltelijk bereikt maar nog niet allemaal. Als we binnen een organisatie echte stappen willen maken dan moeten we de organisatie erbij betrekken. Het toewerken naar feature teams is hierbij een must. Als we een team verantwoordelijk willen maken voor een deel van de functionaliteit zouden we ook wat moeten doen aan de (legacy) applicaties in de business layer en aan de oplossingen in de persistence layer. Dit zal een grotere uitdaging zijn dan de introductie van een microservices architectuur.

Referenties

Over de auteur

Marc Blok

Marc Blok

Thought Leader Open Banking

Marc Blok werkt sinds 1998 bij CGI, maar zijn belangstelling voor ICT bestaat al veel langer . Na eerst als ontwikkelaar, ontwerper en projectleider te hebben gewerkt, is hij sinds 10 jaar als architect werkzaam binnen de bancaire wereld. Hij ...

Bekijk profiel