De anarchie van microservices

Klein, kleiner, kleinst

Een microservice, in de context van software-ontwikkeling, zou je kunnen zien als een applicatie
die zelfstandig kan worden ontwikkeld, afzonderlijk kan worden geïnstalleerd en onafhankelijk kan worden getest. Belangrijk is dat een microservice een goed gedefinieerde vastomlijnde functie uitvoert. Om te voorkomen dat we –bijvoorbeeld- Internet Bankieren ook een microservice gaan noemen, moet wel worden opgemerkt dat de “vastomlijnde functie” klein en overzichtelijk is.

Waarom microservices?

Waarom zou je eigenlijk microservices willen doen? Allereerst omdat het helpt om de wereld begrijpbaar te maken… door het op te delen in kleine overzichtelijke brokken. En het helpt het bij het bedenken en het bouwen van het geheel, brokje voor brokje. Niet alleen omdat de brokken klein en overzichtelijk zijn, maar omdat alle brokken onafhankelijk van elkaar zijn.

Onafhankelijk?

Zijn al die brokken onafhankelijk? Niet helemaal, of niet allemaal… tenminste, ik hoop dat een groot deel van die brokken iets doen of iets opleveren wat als geheel toegevoegde waarde heeft. Er is dus integratie nodig om de delen samen te laten werken in een groter geheel. Dat zit ‘m dan dus vooral in de afspraken over hoe die brokken samen werken, de taal die ze onderling spreken en welke informatie ze uitwisselen. Een stip op de horizon, een roadmap, een grand design.

Muiterij

Er zijn dus wel regels nodig om al die microservices in toom te houden, anders gaan ze muiten. Muiten? Microservices kunnen niet muiten! Nope, maar als microservices kunnen worden gedefinieerd als onafhankelijke brokken, die zelfstandelijk kunnen worden gebouwd, afzonderlijk worden geïnstalleerd, afzonderlijk kunnen werken, getest en noem-maar-op… dan zou je agile teams, scrum teams of devops teams (bingo!) kunnen zien als de organisatorische variant van microservices. En die teams kunnen wel degelijk muiten.

Anarchie dus?

De product owners die écht onafhankelijke dingen bouwen kunnen we hun gang laten gaan. Maar het andere deel, het deel waarbij wel een gezamenlijk doel is… hoe zorgen we er voor dat die geen brokken maken? Natuurlijk heeft elke organisatie daar dan weer een tool voor… JIRA bijvoorbeeld is hip tegenwoordig.

Maar als ik zo es in JIRA grasduin dan zie ik ongelofelijk veel brokken… waar is het grand design?

Richard Bliek