Softwaredevelopment is in de loop der jaren aan grote veranderingen onderhevig geweest. In vroegere tijden was een monolithische aanpak vanzelfsprekend. Er werd een allesomvattend product opgeleverd dat alle functies bevatte. In de huidige tijd van devops, containers, cloud en ci/cd is de wereld radicaal aan het veranderen.
Een ontwikkelmethode die steeds meer momentum krijgt is microservices. Microservices is de opvolger van service oriented architecture. Feitelijk komt het bij microservices erop neer dat software in kleinere modules wordt ontwikkeld. Dit kan bijvoorbeeld een e-mailfunctie zijn, een payment module of een product catalogus. Eigenschap van een module is dat deze eenduidige functionaliteit bevat, en onafhankelijk kan schalen en getest kan worden. Het gebruik maken van nieuwe technieken zoals containerization geven een additionele impuls aan deze nieuwe manier van werken.
Deze techniek kan een hogere beschikbaarheid van de applicatie bewerkstelligen. De ontwikkeltechniek leent zich uitstekend om in een devops-straat te worden ontwikkeld. Immers het minimal viable product staat als zodanig vast, en kan zelfs uit meerdere andere kleinere producten bestaan.
Er zijn ook nadelen. Het te ontwikkelen product kan te klein zijn voor ontwikkeling in een microservice-structuur. Verder vereist het veel nieuwe tooling en zijn er afhankelijkheden.
Mandaat
Er is een groot belang om de organisatie klaar te maken voor deze ontwikkelingen. Er moet een mandaat zijn vanuit het management om de teams op deze manier te laten werken. Er zullen processen moeten worden ontwikkeld die duidelijkheid gaan geven. Iedereen zal ook moeten wennen aan de iteraties die bij deze nieuwe manier van ontwikkelen nodig zijn. Immers, de watervalmethode gaf doorgaans een goed overzicht over het totaalbeeld. Nu kan dat opeens heel anders zijn.
Het gebruik van microservices leent zich beter voor bestaande applicaties dan voor applicaties die van scratch worden ontwikkeld. Modules uit een applicatie kunnen eruit worden genomen (neem als voorbeeld de e-mailfunctionaliteit) en opnieuw ontwikkeld worden.
De businesswaarde van microservices ligt in het feit dat ze de mogelijkheid bieden om sneller in te kunnen springen op ontwikkelingen wanneer de markt om deze veranderingen vraagt. Er is geen lang traject nodig om de hele applicatie door te spitten en de verandering door te voeren. Kleinere modules zijn sneller aan te passen als ze goed geordend zijn. Er zijn nog meer goede redenen om microservices te gebruiken. Het herschrijven van modules omdat ze gebruikmaken van oude technieken is zo’n reden. Of het feit dat applicaties wellicht gebruik kunnen maken van features die nu al in de cloud beschikbaar zijn. Hierdoor kunnen de modules minder complex worden. Als laatste kunnen de mogelijkheden van het gebruik van api’s een acceleratie leveren op het gebied van kostenreductie. Immers, veel functionaliteit is te verkrijgen via een api en is vaak nog actueler dan code van de applicatie waar data voor moet worden aangeleverd.
Microservices als methodiek is conceptueel al ver. Invoering ervan vereist nog tijd. De tijd is nu, want dat deze richting wordt ingeslagen in een wereld waarin steeds meer wordt samengewerkt vanuit de cloud is onvermijdelijk.
