Blog

Schaalbare webapplicaties door Microservices

Om goed in te kunnen spelen op veranderende marktomstandigheden en de concurrentie voor te blijven, is er behoefte aan applicaties die snel te ontwikkelen én uit te rollen zijn. Applicaties moeten bovendien schaalbaar zijn, om veranderingen in de gevraagde capaciteit op te kunnen vangen zonder performanceverlies. Dit vereist een applicatie-architectuur die niet statisch, maar juist dynamisch is, zoals het geval is bij bijvoorbeeld Amazon, Google, Netflix en Facebook. Om dynamische applicatie-architecturen op te zetten, wordt vandaag de dag steeds meer gebruik gemaakt van microservices. Deze worden ingericht in een zodanig patroon dat deze services onafhankelijk van elkaar kunnen worden ontwikkeld en uitgerold.

Al vanaf de jaren ’90 werden er in plaats van monolithische oplossingen steeds vaker applicaties ontwikkeld die zijn opgebouwd uit een drielagenmodel , waarbij de verschillende lagen zich toespitsen op respectievelijk de data, de logica en de presentatie. De database en logica kunnen hierbij worden opgeschaald, terwijl de presentatielaag gelijk blijft. Om de groei van de logicalaag beheersbaar te houden, wordt er in componenten gewerkt. Dit zogenoemde component based development ging later over in services. Deze zijn kleiner dan componenten en bovendien meer gericht op een specifieke functionaliteit. Hierbij valt te denken aan een service voor authenticatie, orderafhandeling en e-mailnotificatie. Door een Service Oriented Architecture (SOA) te gebruiken, kunnen de verschillende applicaties met elkaar communiceren. Dit gebeurt veelal via een Enterprise Service Bus (ESB).

Waarin verschillen microservices van SOA?
Het opdelen van een applicatie in componenten of services is dus niet nieuw. Maar doordat deze oplossingen moeite hebben om alle technische- en businessontwikkelingen te blijven volgen, blijken ze nu toch vrij archaïsch en duur te zijn. Als reactie hierop geraakt het gebruik van microservices in opkomst. Microservices worden ingericht in een patroon waarbij de services onafhankelijk van elkaar kunnen worden ontwikkeld en in productie uitgerold. Ze volgen dus het enkelvoudige verantwoordelijkheidsprincipe. De communicatie tussen microservices wordt gedaan over http, met veelal een RESTful API en waarbij JSON data zeer efficiënt en snel wordt doorgegeven. Het patroon van microservices is duidelijker en ondersteunt de moderne schaalbaarheidseisen die aan webapplicaties worden gesteld beter. Micro hoeft overigens niet per definitie ‘klein’ te betekenen, waardoor je standaard met een zeer groot aantal services opgescheept zou komen te zitten.

Een andere visie op schaalbaarheid
Het principe van microservices vindt zijn oorsprong in de hardwarewereld. Hier is het begrip ‘servervirtualisatie’ al jaren gemeengoed. Sinds een paar jaar is hier het begrip ‘containersoftware’ bijgekomen. Cloud hosting-bedrijven als Amazon en Azure bedachten oplossingen om via replicatie een schaalbare omgeving te realiseren. Hierdoor kan binnen enkele minuten een extra server worden toegevoegd, bijvoorbeeld om een piekbelasting op een veilingsite op te kunnen vangen. Op het gebeid van gedeeltelijke applicatiereplicatie geldt het bedrijf Docker als een pionier. Zij bedachten een oplossing om in plaats van de gehele applicatie over meerdere omgevingen te repliceren, heel gericht bepaalde microservices waaraan behoefte is op- en af te kunnen schalen. Naast traditionele integrale duplicatie van microservices, zoals schermen of User Interfaces om producten te zoeken, bestellingen te plaatsen en orders af te handelen, wordt het ook mogelijk om gelijksoortige microservices of per verschillende microservices op te schalen. Bij gelijksoortige services kan een verdeling worden gemaakt op basis van data partitionering (bijvoorbeeld zakelijke klanten versus particulieren). Bij verschillende services gaat het om functionele decompositie, zoals een service voor productinformatie, het doen van aanbevelingen en het plaatsen van bestellingen.

Voordelen
Een dynamische applicatie-architectuur op basis van microservices biedt een aantal voordelen:
• Doordat een microservice relatief klein is, is de code beter te bevatten voor een ontwikkelaar, waardoor de productiviteit van ontwikkelaars en de kwaliteit van de software toeneemt.
• Doordat iedere service onafhankelijk van andere services kan worden uitgerold, kunnen ontwikkelaars zelfstandig werken en services uitrollen. Hierdoor komt continuous delivery binnen handbereik. Ook blijft de impact van fouten beperkt tot een enkele microservice. De andere services zullen normaal blijven functioneren.
• Door het onafhankelijke karakter kan iedere microservice worden gedraaid op hardware die het beste aansluit bij de eisen van die specifieke service (bijvoorbeeld CPU-intensief versus geheugenintensief). Bovendien kan iedere service hierdoor apart worden geschaald.
• Met microservices wordt bovendien het ontwikkelproces schaalbaar, waarbij de ontwikkelcapaciteit wordt georganiseerd in teams die verantwoordelijk zijn voor een bepaalde service of een groep gerelateerde services.

Nadelen
Uiteraard zijn er ook een aantal nadelen aan het werken met microservices:
• Ontwikkelaars zullen moeten omgaan met de extra complexiteit van het creëren van een distributed system, waarbij de grootste uitdaging zal bestaan uit het inregelen van een coördinatiemechanisme dat de verschillende services met elkaar verbindt. PaaS-technologie, zoals OutSystems Platform, biedt daar een goede ondersteuning voor.
• Er moeten veel meer dynamische delen (meerdere versies van verschillende type services) worden beheerd in productie. PaaS-achtige technologie zoals Netflix Asgard kan uitkomst bieden voor het uitrollen en managen van applicaties in de cloud.
• Er kan frictie ontstaan tussen architecten en ontwikkelaars over welke applicaties hoe herbouwd moeten worden op basis van microservices. En ontwikkelaars kunnen door een te grote focus op de services waaraan ze werken de doelstelling van het systeem als geheel uit het oog verliezen.
 

Gelet op de voor- en nadelen van microservices lijkt een dynamische applicatie-architectuur vooral geschikt voor applicaties die sterk schaalbaar moeten zijn, zoals web- en SaaS-applicaties met een groot aantal gelijktijdige gebruikers. Niet voor niets hebben bekende sites als eBay, Amazon en Groupon al de transitie ondergaan van een monolithische naar een dynamische applicatie-architectuur.
 

Deze blog is geschreven door Joachim Vandecasteele. Heeft u ook iets wat u bezig houdt? Meldt u dan aan als auteur en plaats uw eigen blog
Categorie:   
Auteur
afbeelding van JoachimVandecasteele
Joachim Vandecasteele
COOLProfs - CTO

Joachim Vandecasteele is de CTO van COOLProfs, specialist in het bouwen van bedrijfskritische informatiesystemen op maat. COOLProfs onderscheidt zich door haar aanpak, waarin de menselijke factor van IT centraal staat en waarbij in nauwe samenwerking met de klant het gewenste resultaat wordt gerealiseerd. Vandecasteele was voor zijn tijd bij COOLProfs senior consultant bij KPMG Consulting op het gebied van World Class IT en consultant ISES International op het gebied van CASE-tools voor systeemontwikkeling. Hij heeft verschillende publicaties op zijn naam staan over de toekomst van de IT-organisatie, over strategierealisatie met de balanced scorecard en over maatwerk systeemontwikkeling. Vandecasteele studeerde Bestuurlijke Informatiekunde aan de Katholieke Universiteit Brabant en Bedrijfsinformatica aan de Haagse Hogeschool. Zijn vrije tijd besteedt hij aan zijn gezin, alles volgen wat met IT te maken heeft en marathons lopen. Altijd gedreven, scherp en vrolijk!

Twitter: jvandecasteele
Email: joachim.vandecasteele@coolprofs.com

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.