Waar grote tech-bedrijven hun softwareplatformen al ontwikkelen op basis van een microservices-architectuur met containers, komt de adoptie hiervan bij grote, traditionele bedrijven nu pas echt op gang. De voordelen van microservices en containerisatie vallen niet langer te ontkennen.
Je kunt software sneller ontwikkelen en releasen, in kortere cycli. Daardoor wordt het makkelijker om businessfunctionaliteiten te wijzigen of nieuwe functionaliteiten beschikbaar te stellen. Je kunt hiernaast efficiënter omgaan met je resources door individuele services onafhankelijk van elkaar te schalen.
Containers zijn op ieder gewenst platform te hosten en zijn makkelijk te migreren van bijvoorbeeld een private naar een public cloud, waardoor je een haast oneindige portabiliteit krijgt. Je kunt bovendien per service kiezen in welke taal je de code schrijft, wat ontwikkelaars veel meer flexibiliteit geeft om de juiste code te kiezen bij de use case. En ook als het gaat om storage maak je veel flexibeler keuzes omdat je per container bepaalt of je de data opslaat in bijvoorbeeld een object database of een relationele database.
Beter nadenken vooraf
Door deze lange lijst aan voordelen lijkt het vaak alsof er geen nadelen zijn. Het lijkt alleen maar eenvoudiger en goedkoper te worden. Dat is echter niet waar. De complexiteit is er nog altijd, alleen verschuift deze naar het architectuurniveau. Een gedistribueerd systeem is namelijk per definitie complexer. Je zult dus vooraf beter moeten nadenken over wat je aan het doen bent, want anders kun je de complexiteit achteraf niet meer overzien en wordt het geheel aan services onoverzichtelijk en onbeheersbaar.
Een container omvat namelijk niet alleen de applicatie, maar ook de randvoorwaarden die nodig zijn om de applicatie te laten draaien. Het beveiligen en monitoren van een omgeving met containers is veelomvattender en complexer dan een traditionele situatie met virtual machines en bare metal. Hiernaast vinden traditionele ops-taken nu eerder plaats in de development lifecycle. Dev en ops zullen dus veel nauwer moeten samenwerken. Ontwikkelaars zullen al bij de start van de ontwikkeling in conclaaf moeten met de operations-specialisten om te begrijpen aan welke randvoorwaarden ze moeten voldoen om de software veilig te ontwikkelen en te beveiligen in productie. Het ontwikkelproces zelf is ook anders en brengt vragen met zich mee als: welke image gebruik ik? Is deze van een vertrouwde bron? Hoe blijven mijn besturingssysteem en runtime up-to-date? Maar ook: hoe beveilig ik mijn registry? Hoe organiseer ik role-based access control op de orchestratielaag? Et cetera.
Integratiediensten worden microservices
Dit alles heeft uiteraard gevolgen voor integratieservices. Er komen immers steeds meer databronnen bij. Om in de behoeften van de business te voorzien, is het noodzakelijk om die bronnen snel, flexibel, herbruikbaar en veilig te kunnen ontsluiten. Hierbij helpt een agile integratie-aanpak, waarbij de integratieservices zelf ook microservices worden die in containers beschikbaar worden gesteld. Deze gedecentraliseerde aanpak vraagt om het gebruik van integratietools die aansluiten bij het hybride applicatielandschap. Maar het vraagt ook om een andere organisatievorm van de nu vaak nog traditioneel georganiseerde integratielaag.
Je zult ook een afweging moeten maken in de mate waarin je functionaliteit opsplitst in losse containers. Vanuit het oogpunt van autonomie, herbruikbaarheid en flexibiliteit houd je de microservices het liefst klein. Als je de functionaliteit echter in te kleine stukjes opknipt, en daarmee het aantal containers vergroot, dan verlies je een deel van je snelheid door de extra communicatielijnen die ontstaan. Bovendien zit in iedere container overhead, wat zich uiteindelijk vertaalt in kosten. En tot slot wordt de beheersbaarheid natuurlijk complexer naarmate je meer containers hebt. De vraag is: hoe houd je overzicht en regie als het aantal containers maar blijft uitdijen en daarmee het aantal communicatiestromen verveelvoudigt? Je zult dus balans moeten zoeken tussen flexibiliteit, kosten en beheersbaarheid.
Tooling lost niet alles op
Natuurlijk, het Kubernetes-platform draagt in belangrijke mate bij aan het beheersbaar houden van deze uitdagingen. Deze orchestratielaag, die als een schil over de containers ligt, maakt het bovendien mogelijk om monitoring in te richten. Kubernetes vergelijkt de gewenste status en de werkelijke status van containers en acteert automatisch als deze twee van elkaar afwijken. Daarmee wordt het beheer in bepaalde aspecten eenvoudiger, maar dat betekent allerminst dat je ops-specialisten minder onderlegd of nodig hoeven te zijn.
Er komen namelijk nieuwe vragen zoals: wat doe je als de container in een restart loop terecht komt? Wat Kubernetes niet kan, is een juiste afweging maken tussen flexibiliteit en beheersbaarheid. Je zult dus naast tooling ook altijd gespecialiseerde ontwikkelaars en operationsspecialisten beschikbaar moeten hebben om samen de juiste keuzes te maken.
Bezint eer ge begint
Ons advies is: als je met containers aan de slag gaat, bedenk dan vooraf hoe je de architectuur inricht en hoe je dev en ops dichter bij elkaar brengt om onder andere aspecten als security en beheersbaarheid te waarborgen. Implementeer een agile integratiestrategie die aansluit op het hybride applicatielandschap om de ontwikkelsnelheid daadwerkelijk te verhogen. Niet voor alle toepassingen is een microservices-architectuur per definitie de beste oplossing. Zoek dus de balans tussen flexibiliteit en beheersbaarheid. En zorg dat zowel de ontwikkelaars als de operations specialisten voldoende Kubernetes-kennis hebben: hoe werkt het platform onder de motorkap? Strikt genomen heb je die kennis niet nodig om een stukje code te ontwikkelen en die in een container te stoppen. Maar als je wil dat alle containers op de juiste manier met elkaar (blijven) praten, op de juiste manier beveiligd zijn én de kosten in de hand wilt houden, dan is die kennis onontbeerlijk.
Jos Smits, cto, Frank van Noorden, architect en Thomas Wijnberg, developer bij Conclusion Virtual Sciences
De vraag over een uitdijend aantal microservices met parallel een verveelvoudiging in de communicatiestromen levert de klassieke problemen in de meso- en macroarchitecturen op. Voor wat betreft de regie vanuit de macro architectuur zijn er namelijk GRC regels die vertaald zullen moeten worden tot op het micro architectuur niveau. Want vanuit het privacy-by-design principe moeten de onderlinge koppelvlakken inzichtelijk zijn zodat duidelijk is wie met wie communiceert en waarom. En betreffende de opslag zullen role-based access control mechanismen uiteraard onafhankelijk van de containers moeten zijn, het bonnetje moet je tenslotte langer bewaren dan de levensduur van een service.
Oja, DevOps evolueert langzaam tot SecDevOps (let even op de volgorde) omdat het besef komt dat er geen vrijblijvendheid meer is voor wat betreft het voldoen aan regels. En kennis van de regels betekent een meer juridische kijk op de IT als we kijken naar de Europese macro architectuur.