Dit is vergelijkbaar met het opzetten van een software architectuur. Het team ontwikkelt, in samenwerking met de opdrachtgever, een plan en bedenkt de opzet voor de applicatie. Ze kiezen de talen, frameworks en technieken die het beste passen bij de gestelde eisen.
Architectuur en basketbal, wat heeft dat met elkaar te maken? Misschien meer dan je denkt. Binnen basketbal bestaan namelijk verschillende speelstijlen, zoals pace & space (veel beweging en passes) en grit & grind (fysiek en langzaam spelend). Een goede technisch directeur van een basketbalteam denkt vooraf goed na over de speelstijl. Hij kiest de spelers en coaches uit die passen bij het plan. Het is een soort blauwdruk van het team.
Het plan aanpassen tijdens het seizoen is een stuk complexer dan wanneer dit voor het seizoen gebeurt. Bij softwareontwikkeling is het niet anders. Het uitdenken van de juiste architectuur is erg belangrijk. Je moet nadenken over hoeveel gebruikers de applicatie krijgt, met welke hoeveelheden data er rekening gehouden moet worden en hoe snel de applicatie moet zijn.
Microservices, het andere begrip uit de titel van dit blog, zijn vergelijkbaar met een basketbalteam: iedere speler heeft zijn eigen rol met de bijbehorende verantwoordelijkheden. Ze vormen een team met een gezamenlijk doel: winnen. Klassieke applicaties hebben vaak een monolithische architectuur. Dit is één grote service die alle verantwoordelijkheden heeft. Een applicatie opgezet in een Microservice Architectuur bestaat uit allerlei kleine applicaties, ook wel services genoemd. De services hebben allemaal hun eigen verantwoordelijkheden. Samen vormen ze één applicatie die voorziet in alle wensen van de klant.
Een nieuwe ontwikkeling binnen het basketbal is ‘positionless basketball’. Samengevat houdt dit in dat er niet zozeer meer in posities wordt gedacht. De speler met de juiste eigenschappen om een bepaalde taak uit te voeren wordt in het veld gezet. Een Microservice Architectuur is hiermee te vergelijken. Een goed opgezette Microservice Architectuur zorgt ervoor dat een applicatie schaalbaar en duurzaam is. Dit houdt in dat onderdelen van de applicatie waar veel vraag naar is meerdere malen kunnen worden opgestart. De applicatie is op die manier geschikt om een grote vraag en veel informatie te verwerken. Dit is één van de grootste voordelen van het gebruik van een Microservice Architectuur.
De technisch directeur trekt spelers aan die passen bij de verantwoordelijkheden van het team. Iedere speler heeft zijn eigen eigenschappen die hem bruikbaar maken. De ene speler is erg sterk, maar door de spiermassa minder snel. Terwijl een andere speler goed kan schieten en snel is. Dit is vergelijkbaar met een Microservice Architectuur. Sommige technologieën lenen zich beter voor het ontwikkelen van een webapplicatie terwijl anderen geschikter zijn voor complex berekeningen. Per service wordt gekozen welke technologie het beste past bij zijn verantwoordelijkheden. Dat is dus een groot voordeel van een Microservice Architectuur.
Het smeden van een goed basketbalteam is complex. Er komt meer bij kijken dan het aantrekken van goede coaches en spelers. Communicatie tussen coach en spelers is erg belangrijk en er moet chemie ontstaan wil een team succesvol zijn. Het ontwikkelen van een applicatie binnen een Microservice Architectuur is precies om dezelfde redenen complexer dan één klassieke grote applicatie. De communicatie tussen de services brengt complexiteit met zich mee. Er moet bijvoorbeeld worden nagedacht over foutafhandeling en afhankelijkheden tussen verschillende services. De services moeten op elkaar afgestemd zijn en goed met elkaar communiceren. Dit is vergelijkbaar met teamchemie.
Zoals het bovenstaande plaatje laat zien is een Microservice Architectuur niet altijd rendabel. Wanneer schaalbaarheid en flexibiliteit geen eisen zijn, is een monolithische opzet soms de beste oplossing. Bij een applicatie die wordt doorontwikkeld is een Microservice Architectuur al snel de beste keuze. Wanneer performance, schaalbaarheid en duurzaamheid eisen zijn, dan kun je eigenlijk niet om een Microservice Architectuur heen. Amazon heeft berekend dat een vertraging van honderd milliseconde op hun webwinkel één procent verkopen kost.
In de afgelopen jaren is het gebruik van een Microservice Architectuur een stuk toegankelijker geworden. Dit komt door de opkomst van verschillende cloud providers zoals Microsoft Azure, Google Cloud en Amazon Web Services(AWS). Deze providers hebben een grote ICT infrastructuur met verschillende datacenters over de hele wereld. Dit is ook de reden dat steeds meer applicaties volgens een Microservice Architectuur worden opgezet.
Covadis ontwikkelt samen met de opdrachtgever het plan voor de applicatie. Dit doen wij aan de hand van de eisen die we samen bespreken. Je zou ons als de technisch directeur kunnen zien en de opdrachtgever als de algemeen directeur. Het gezamenlijke doel is een goed team neerzetten en een goed resultaat halen. In de laatste jaren is het gebruik van Microservices een stuk toegankelijker geworden, daarnaast biedt het erg veel voordelen. Het zou altijd moeten worden overwogen, zeker voor onderdelen van de applicatie.
Het Covadis Innovatielab onderzoekt met welke innovatieve methoden en technieken we Microservices makkelijker en sneller kunnen inzetten. We willen op deze manier een Microservice Architectuur toegankelijker maken, ook voor kleinere applicaties. Op deze manier kunnen onze applicaties efficiënt en duurzaam worden gerealiseerd. Ben je geïnteresseerd geraakt in deze architectuur en benieuwd wat wij voor je kunnen betekenen? Gooi eens een balletje op. Samen smeden wij het beste team!
Tim Boerman
Tim Boerman is de projectleider van het Innovatielab. Dit lab is de R&D afdeling van Covadis. Hier werken talentvolle ontwikkelaars aan prototypes voor onze opdrachtgevers. Hiermee is Tim de slijper die van de ruwe diamanten ware edelstenen maakt. Als correspondent in het land der nieuwe technieken weet Tim van alle relevante noviteiten en aankondigingen. Via zijn blogs houdt hij ons allen op de hoogte, als zijn favoriete NBA team tenminste niet speelt.