Waar vroeger vooral met monolithische applicaties werd gewerkt, bestaan applicaties vandaag de dag steeds vaker uit een verzameling microservices. Deze verschuiving brengt verschillende voordelen met zich mee, maar kent ook enkele uitdagingen. Kilian Drewel, trendwatcher & techblogger bij True, zoomt in op de belangrijkste ontwikkelingen rondom de verschuiving van monolithische applicaties naar microservices.
Dit interview verschijnt tevens in de eerstvolgende editie van vakblad CloudWorks.
Geen one-man-job meer
De tijd dat een website of webapplicatie op een zolderkamertje werd ontwikkeld is inmiddels ver achter ons. Voor webdevelopment zijn vandaag de dag een breed scala aan technologieën en werkwijzen beschikbaar. Ontwikkelaars kunnen dan ook niet langer over alle benodigde kennis beschikken en werken doorgaans samen in ontwikkelteams, waarbij ieder zijn eigen expertise inbrengt.
Ook de manier waarop applicaties worden ontwikkeld is de afgelopen jaren drastisch veranderd. “Waar applicaties voorheen vaak in één keer werden neergezet als een grotendeels afgerond project, is applicatieontwikkeling vandaag de dag een continu proces dat nooit ophoudt. Steeds meer wordt gewerkt met iteraties en worden nieuwe functionaliteiten gefaseerd uitgerold”, zegt Drewel. “We zien dan ook steeds meer specialismen terug in de developmentwereld. Het gaat hierbij niet alleen om expertise op het gebied van softwareontwikkeling, maar steeds vaker ook omtrent systeembeheer en de raakvlakken daartussen.”
Vanaf iedere locatie aan de slag
De opkomst van ontwikkelplatformen als GitHub en GitLab is een belangrijke drijver voor deze verschuiving. “Dergelijke systemen hebben een gigantische revolutie veroorzaakt. Via deze platformen kunnen ontwikkelaars elkaar laten meekijken naar code. Het maakt hierdoor niet langer uit waar ter wereld een ontwikkelaar zich bevindt; vanaf iedere locatie kan hij aan de slag met de code en bijdragen aan een project. Met een klein stukje code kan iemand al een belangrijke bijdrage leveren.”
Als voorbeeld noemt Drewel Automattic, het moederbedrijf van contentplatform WordPress. Het bedrijf kondigde in 2017 aan zijn hoofdkantoor te sluiten aangezien werknemers hier nog onvoldoende gebruik van maakten. “Dit bedrijf telt zo’n 1.200 medewerkers, die remote werken over de gehele wereld. Om dit mogelijk te maken zijn de verschillende technologieën waarmee zij werken ondergebracht in remote teams. Iedereen werkt gedistribueerd aan eigen projecten”, licht Drewel toe.
Verschuiving naar microservices
Het werken in remote teams sluit aan bij een verschuiving die al langer gaande is, namelijk van monolitische applicaties naar microservices. “Een monolitische applicatie kun je het beste zien als één blok code en systemen die je ergens neerzet. Het draait hierbij vooral om stabiliteit en veiligheid. Naarmate een applicatie groeit wil je echter soms wijzigingen doorvoeren. Doordat een monolitische applicaties echter uit één blok code bestaat, zijn deze wijzigingen relatief moeilijk realiseerbaar. Ook zijn monolithische applicaties minder geschikt voor gedistribueerde systemen.”
Het is dan ook niet verrassend dat microservices snel aan populariteit winnen. “Een microservice is in feite een kleine mini-applicatie. Je deelt een applicatie op in meerdere microservices, die ieder een eigen functionaliteit voor rekening nemen”, legt Drewel uit. Denk hierbij aan een betaal- of een inlogfunctie. Microservices opereren onafhankelijk van elkaar en kunnen bijvoorbeeld over eigen databasesoftware beschikken of een andere programmeertaal gebruiken. Met behulp van API’s werken microservices met elkaar samen. De eindgebruiker merkt hier niets van. Doordat microservices onafhankelijk van elkaar opereren is het relatief eenvoudig een functionaliteiten te vernieuwen, toe te voegen of juist te verwijderen.
“Werken met microservices is ideaal als je een team met remote ontwikkelaars hebt, zoals Automattic. Doordat functionaliteiten onafhankelijk van elkaar als mini-applicatie opereren kunnen ontwikkelaars zich op hun eigen stukje van het project richten. Zij zijn minder afhankelijk van andere ontwikkelaars en kunnen in feite vanaf iedere locatie ter wereld via internet werken.”
Site reliability engineer
Binnen veel techgiganten zien we de laatste jaren een nieuwe functie ontstaan om de complexiteit van microservices te beheren: de site reliability engineer. Zij zijn verantwoordelijk voor de betrouwbaarheid en beschikbaarheid van een gedistribueerde omgeving die bijvoorbeeld bestaat uit microservices. Het testen van microservices speelt hierbij een cruciale rol. De site reliability engineer voorkomt dat een fout met een microservice het functioneren van de rest van het applicatie-ecosysteem beïnvloedt.
Netflix is een voorbeeld van een partij die veel gebruik maakt van microservices. Om fouten in deze mini-applicaties op te sporen zetten zij ‘Chaos Monkey’ in. Deze tool is door Netflix in eigen beheer ontwikkeld en test of microservices ondanks fouten correct blijven functioneren. “Chaos Monkey sloopt doelbewust willekeurige elementen van gedistribueerde systemen en brengt de impact in kaart. Dit voorkomt dat problemen met een microservice de betrouwbaarheid van de totale applicatie in gevaar brengen.”
DevOps
De inzet van site reliability engineers sluit aan bij de DevOps-methodiek, waarmee bedrijven softwareontwikkeling (Dev) en de operationele kant van software (Ops) samenbrengen. “Bij DevOps zijn twee verschillende functies beschikbaar, die ieder hun eigen prioriteiten hebben. Zo willen ontwikkelaars vooral zo snel en foutloos mogelijk nieuwe functionaliteit beschikbaar stellen aan gebruikers. Voor systeembeheerders is het echter vooral van prioriteit dat systemen stabiel en veilig zijn, en goed presteren.”
Deze twee belangen staan soms haaks op elkaar. Snelheid vertaalt zich bijvoorbeeld niet altijd in stabiliteit en veiligheid. Deze botsende belangen zijn niet nieuw en kennen we ook van monolithische applicaties. Gedistribueerde systemen vergroten echter het probleem. “Gedistribueerde systemen worden met regelmaat vernieuwd of uitgebreid, wat dankzij het gebruik van microservices een stuk eenvoudiger is geworden. Deze continue ontwikkeling en de snelheid waarmee wijzigingen worden doorgevoerd maakt het bewaken van de betrouwbaarheid, veiligheid en prestaties een uitdaging.”
CI/CD-pijplijn
Deze uitdagingen kan worden overwonnen met behulp van een Continuous Integration en Continuous Development pijplijn (CI/CD-pijnlijn). “Je kunt een CI/CD-pijplijn zien als een soort lopende band in een fabriek, waar een softwareontwikkelaar een stukje code op kan plaatsen. Aan het einde van de band moet deze code in de applicatie in de productieomgeving geïntegreerd zijn. De lopende band leidt de code langs verschillende kwaliteitchecks, die in het geval van CI/CD-pijplijnen volledig geautomatiseerd worden uitgevoerd.”
“Indien ontwikkelaars en systeembeheerders deze testen samen vormgeven kunnen zij hiermee een snelle levering van code mogelijk maken, zonder hierbij de betrouwbaarheid, veiligheid en prestaties van de applicatie in geding te brengen. Een CI/CD-pijplijn brengt hiermee de wereld van softwareontwikkelaars en systeemexperts dichter bij elkaar. Die ontwikkeling blijven we de komende jaren volgen.”
