Talk 1: Wanneer zijn microservices de juiste oplossing voor je API-ontwikkeling?
Voor technische oplossingen anno nu worden cloudgedreven microservices gezien als de oplossing voor flexibele en schaalbare IT als tegenhanger voor monolieten. Maar klopt dat beeld wel? Want je API die bestaat uit microservices betekent tientallen cloud connecties met evenzoveel afhankelijkheden en dito complexiteit. Wanneer zijn microservices wel en wanneer zijn microservices niet de juiste oplossing voor je API-ontwikkeling?
Van SOA naar Microservices
Ongeveer 5 jaar geleden verfijnde het gedachtegoed rondom Service Oriented Architectures door het populairder worden van de DevOps strategie. DevOps, een samentrekking van development en Operations brengt softwareontwikkeling en de operatie (beheer, onderhoud en support) samen. En het werd eenvoudiger om applicaties te publiceren dankzij de opkomst van de cloud. Clouddiensten hebben de wereld van de hosting op zijn kop gezet en maakten het mogelijk om applicaties technisch nog verder op te breken in kleine services; de zogeheten microservices.
Hoe groot of klein is eigenlijk een microservice?
De term micro creëert verwarring zodra je dit onderwerp met elkaar bespreekt. Er is geen exacte definitie wat een microservice nu wel of niet behelst. Is een microservice wel een ‘micro’-service? Wat is de definitie van micro in de context van een technisch complexe applicatie? Martin Fowler, een evangelist in software design principes, heeft dit als volgt benoemd:
‘Microservices’ is a label, not a description.
Onze visie op microservices
Bij Enrise vinden we dat een microservice functioneel onafhankelijk moet zijn, taal-agnostisch is en volledig geautomatiseerd te testen en uit te leveren is.
Wij denken dan aan API’s die 1 functionaliteit bieden. Maar ook daar is geen definitie op te plakken. Wat is nu 1 functionaliteit? Iedereen heeft daar een verschillende visie op. En ga je dan je applicatie verdelen in 5, 10 of nog meer microservices die samen de oplossing voor je businesscase vormen?
Maak kennis met de microlith
Als microservices op zichzelf niet perse de oplossing zijn voor je architectuur uitdaging, wat kun je dan doen? Wij leerden van het verleden, van zowel de monoliet in een Service Oriented Architecture, alsook de inzet van microservices. We bouwen een monoliet, met de voordelen van microservices: een microlith.
Door deze opzet heb je meerdere modulaire eenheden ofwel services, in 1 applicatie. De mate waarin je de eenheden opdeelt bepaal je zelf. Je kunt ze verder opsplitsen tot op het kleinste niveau, microservices zo je wilt. Zo’n microlith is een oplossing voor een onbeheersbare wolk van losse microservices, waarin het steeds lastiger wordt om al die services te blijven onderhouden, in tijd, geld en mankracht.
Communicatieproblemen oplossen
Uiteindelijk lost een microservicesarchitectuur niet primair technische problemen op. Microservices lossen een samenwerkingsprobleem op. Vooral als je schaalt, met meer mensen werkt en systemen complexer worden, kunnen microservices die communicatie-uitdagingenan en blijft begrip voor een architectuur beter onder controle!
Meer weten over de microlith? Jeroen schreef ook Zijn microservices de passende oplossing voor je API-ontwikkeling?.
Talk 2: The user story lifecycle
Boeken vol zijn er geschreven over Agile processen en SCRUM als methodiek. Dat zijn echter geen rigide handleidingen, het zijn handreikingen. Vervolgens ga je ermee aan de slag op je eigen manier en pas ja aan naar wat het beste werkt voor jouw team of project.
Spreker Melle Gloerich neemt de bezoekers van CodeCuisine®LIVE mee op de reis van de User Story, het kleinste onderdeel in software development dat op zichzelf en met de vele andere stories voor maximale waarde moet zorgen. Daarbij geeft hij een kijkje in de keuken van een complex webdevelopmenttraject, dat met een klant en meerdere leveranciers in 76 sprints behoorlijk geperfectioneerd is tot een succesvol Scrumproces.
Request for change
Elke user story begint met de vraag van de klant. Dat kan een kleine vraag zijn voor uitbreiding of aanpassing of de omvang hebben van een maandenlang project. De product owner bekijkt met de klant wat de vraag achter de vraag is en hoe dat concreter kan worden. We formuleren de daadwerkelijke vraag tot wat ze in Scrum-termen een epic noemen.
3 Amigo’s
Dit is niet typisch Scrum, maar Melle’s team heeft de 3 Amigo’s in hun proces gebracht om tot een betere aanpak van een RFC te komen. Het houdt in dat ze met drie mensen de RFC doornemen: een developer, een product owner en een tester. Doordat je met verschillende perspectieven kijkt naar de vraag doe je als team goed je huiswerk. Je kunt namelijk de klant antwoord geven op zijn vraag in de breedte, met meerdere opties. Dus bijvoorbeeld met een topoplossing, een snellere methode of een fasering. Zo heeft de klant ook iets te kiezen.
Planning met partners
Als klant wil je dat een RFC zo snel mogelijk ontwikkeld en opgeleverd wordt. In het geval van de klant in dit voorbeeld, waarbij Enrise de spil is in een IT-landschap met meerdere partners en leveranciers, heeft het team echter eerst behoefte aan het afstemmen met al die betrokkenen. Ook zij hebben hun planning en onze aanpassingen kunnen gevolgen hebben voor de diensten die zij leveren. Goede planning met partners en stakeholders is essentieel om de ontwikkeling van een RFC soepel te laten verlopen.
Prioriteitoverleg
Enrise vindt het prettig om een aparte prioriteit-meeting te hebben, eens per week, om samen met de klant de prioriteiten bespreken. De klant heeft hierin de sleutelrol. Twee of meer user stories met een ‘prio 1’ gaat niet werken, dus daarin moeten scherpe keuzes gemaakt worden. Een top 10 met user stories die deze week opgepakt moeten worden werkt het best.
Refinement
Nu is het moment dat het ontwikkelteam erbij komt, zo’n 5–6- mensen met diverse expertises, om de RFC te verfijnen. Soms doen we dat wel 4 keer per sprint. Als team schat je de omvang van de RFC en al haar user stories in. Soms wel 30 stories per sprint. Dat doet het team met planningpoker. Per user story houdt elk teamlid een kaart omhoog met een getal. Een laag getal betekent weinig inspanning, een hoog getal veel inspanning of hoge mate van complexiteit. Als in de groep de kaartjes verschillen in waarde, gaat men met elkaar in gesprek tot er gezamenlijk akkoord is op de verwachtte impact. Dat maakt inschatten beter en concreter.
Naast inschatten is de refinementsessie er ook om de RFC te verfijnen. Als je namelijk in een groep met mensen zit die straks het werk moeten doen, dan komen daar praktische of tactische aanpassingen uit die de taakomschrijvingen, de userstories, nuttiger maken.
Sprintplanning
Melle vertelt over de sprintplanning, die je als team eenmaal per sprint doet. Als team bepaal je wie welke user stories oppakt. Daarbij houd je ook rekening met vakantiedagen en andere uitval. Historische trends laten zien wat hierin realistisch en haalbaar is. Je houdt daarbij ook rekening met andere teams, die bijvoorbeeld eerst iets aan jouw team moet opleveren of de teams die verder moeten met wat jij oplevert.
Development
Nu gaan we echt beginnen! Developers gaan aan de slag en werken volgens een gestructureerde flow aan hun user stories:
- To-do: Wat gedaan moeten worden;
- WIP: Work in progress. Iedereen ziet wie waar aan werkt;
- Tech Review: Een collega-developer kijkt en controleert of dat wat ontwikkelt is helder en begrijpelijk is en doet wat het moet doen;
- Functional Review: Testers checken per acceptatiecriterium of de applicatie ook na de vernieuwing of wijziging blijft werken en welk effect het heeft op de rest van het systeem;
- Acceptatie: de klant kan nu zelf kijken, controleren en testen;
- Hotfixes: We pakken kleine wijzigingen, verbeteringen aan die niet voorzien waren;
- Feature flags: We maken een knop die een nieuwe feature met 1 klap live kan zetten. Vaak is dit gekoppeld aan tijdgebonden marketingcampagnes;
- Daily standup: Een belangrijk onderdeel van het Scrum-proces met elke dag, met het hele team een kwartier voortgangsoverleg, staand bij het Scrumbord.
Retrospective
Aan het eind van de sprint kijk je als team terug op hoe het ging, wat goed ging en hoe het een volgende sprint beter kan. Elke sprint een procentje beter levert op de lange termijn flinke winst op en een team dat steeds beter op elkaar ingespeeld raakt.
Sprint Review
Nu is het moment om je klant een demo te geven van wat je als team hebt gebouwd. Behalve laten zien, kijk je samen met de klant ook naar hoe het ging en hoe het beter kan in een volgende sprint. Waar de retrospective zorgt voor een sterker team, zorgt de sprint review voor een betere klantrelatie.
Sprint Report
Als alle facetten van de sprint zijn doorlopen, de user stories samen als RFC worden opgeleverd, vatten we alles samen in een Sprint Report. Een digitaal boekje met een verslag, compleet met cijfers over voortgang, bezetting, velocity en kosten.
Deze aanpak is geen blauwdruk voor elk project. Melle liet zien hoe het voor zijn ontwikkelteam werkt, wat niet werkte en welke wijzigingen zij aan het standaardproces hebben toegevoegd. Dat heeft gezorgd voor een werkwijze waar klant, partners, leverancier en developers enorm voordel van hebben.
Culinaire afsluiting
Op een CodeCuisine®LIVE hoort een culinaire afsluiting. De buren van restaurant Dara verzorgden een buffet vol internationale geuren en smaken. Met een bordje in de hand spraken bezoekers en sprekers elkaar over de dagelijkse praktijk van techniek en proces en software-ontwikkeling. Met tips, uitwisseling van ervaringen en nieuwe inzichten werd editie 8 van ons event tot een geslaagde avond.
Ook napraten? We helpen je graag in de zoektocht naar antwoorden op je digitale technologie- en procesvraagstukken. Bel of mail met Enrise voor een gesprek met onze experts.
