Verzuimsignaal om over te stappen naar een microservice-architectuur?
8. Conclusie en aanbevelingen
In dit onderzoek is bekeken hoe de monolithische architectuur van Verzuimsignaal omgezet kan worden naar microservices. Hiervoor is gekeken naar de wensen van Verzuimsignaal. Daarna zijn de mogelijkheden binnen een microservice-architectuur onderzocht. Vervolgens is gekeken naar de verschillende patterns en door welke technologieën ze worden ondersteund.
Met behulp van deze informatie is een toekomstige architectuurtekening gemaakt. Deze tekening geeft de huidige architectuur weer en laat zien hoe deze
langzamerhand kan worden omgezet naar een microservice-architectuur.
Daarnaast is een architectuurplaat opgesteld voor de ontwikkeling van het prototype. Hiervoor is samen met de technisch begeleider een lijst opgesteld met daarop de systeem-requirements en de user-requirements. Deze architectuurplaat is na goedkeuring gebruikt om het PoC om te zetten naar een prototype.
Het PoC is verder uitgewerkt met de benodigde informatie en voldoet aan alle systeem- en user-requirements die waren opgesteld. Hierna is het prototype gedeployd naar een Kubernetes-omgeving.
Het prototype is een eerste stap naar een microservice-architectuur. Bij het verder ontwikkelen van de microservice-architectuur moet rekening worden gehouden met enkele aandachtspunten. Een van die punten is dat het een nieuw concept is dat in het bedrijf wordt geïntroduceerd. Niet alleen de microservice is een nieuw concept, maar ook de patterns die in de service worden gebruikt. Door deze verschillende technologieën lijkt het zeer complex en is het lastig te zien wat er gaande is, totdat duidelijk is hoe het nieuwe concept werkt.
Een ander aandachtspunt is dat er bij Verzuimsignaal veel kennis is over de huidige applicatie. Hierdoor weten veel ontwikkelaars van Verzuimsignaal waar de
ontwerpfouten liggen in de de applicatie. Deze kennis kan worden meegenomen naar een nieuw ontwerp van een microservice. Hierdoor kunnen deze fouten in de
toekomstig worden voorkomen.
Het laatste aandachtspunt is dat het omzetten van de monolithische applicatie naar een microservice veel is kost, maar dat het ook veel voordelen oplevert. Het wordt met de microservice-architectuur bijvoorbeeld eenvoudig om een gedeelte van de applicatie op te schalen.
9. Literatuurlijst
Wikimedia Foundation, Inc. (2020, april 1). OS-level virtualization. Opgehaald van wikipedia.org: https://en.wikipedia.org/wiki/OS-level_virtualization Amazon Web Services. (sd). Auto Scaling Groups. Opgehaald van
aws.amazon.com:
https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGr oup.html
Amazon Web Services, Inc. (sd). Amazon Elastic Container Service. Opgehaald van aws.amazon.com/: https://aws.amazon.com/ecs/
Bologna, A. (2018, maart 18). Microservices the Event Sourcing way. Opgehaald van itnext:
https://itnext.io/microservices-the-event-sourcing-way-124a8a772680 cloudamqp. (2015, 05 18). Part 1: RabbitMQ for beginners - What is RabbitMQ?
Opgehaald van cloudamqp.com:
https://www.cloudamqp.com/blog/2015-05-18-part1-rabbitmq-for-begin ners-what-is-rabbitmq.html
CQRS. (2011, jul 14). Opgehaald van martinfowler.com: https://martinfowler.com/bliki/CQRS.html
Davis, K. (2018, feb 20). New Videos: Active-Active, Redis on Flash, Replication and Clustering Deep Dives. Opgehaald van redislabs.com:
https://redislabs.com/blog/new-videos-active-active-redis-on-flash-rep lication-and-clustering-deep-dives/
Docker Inc. (sd). What is a Container? Opgehaald van docker.com: https://www.docker.com/resources/what-container
educba. (sd). Difference Between Redis and Kafka. Opgehaald van educba.com: https://www.educba.com/redis-vs-kafka/
Forstner, M. (2019, feb 11). How to use Redis as an event store for
communication between microservices. Opgehaald van redislabs.com: https://redislabs.com/blog/use-redis-event-store-communication-micro services/
Google. (2020, april 20). Deploying a containerized web application. Opgehaald van cloud.google.com:
google. (2020, 04 20). Deploying event-sourced systems with Cloud Spanner. Opgehaald van cloud.google:
https://cloud.google.com/solutions/deploying-event-sourced-systems-w ith-cloud-spanner
Google. (sd). Google Kubernetes Engine. Opgehaald van cloud.google.com: https://cloud.google.com/kubernetes-engine/
hbo-i. (2015, jan 31). Interview. Opgehaald van onderzoek.hbo-i: https://onderzoek.hbo-i.nl/index.php/Interview
HBO-i. (2018, feb 9). Available product analysis. Opgehaald van ictresearchmethods.nl:
http://ictresearchmethods.nl/Available_product_analysis HBO-i. (2018, feb 9). Best good and bad practices. Opgehaald van
ictresearchmethods.nl:
http://ictresearchmethods.nl/Best_good_and_bad_practices HBO-I. (2018, jan 18). Component test. Opgehaald van HBO-I:
http://ictresearchmethods.nl/Component_test HBO-I. (2018, jan 18). Decomposition. Opgehaald van HBO-I:
http://ictresearchmethods.nl/Decomposition
HBO-I. (2018, jan 18). Design pattern research. Opgehaald van HBO-I: http://ictresearchmethods.nl/Design_pattern_research
HBO-I. (2018, jan 18). IT architecture sketching. Opgehaald van HBO-I: http://ictresearchmethods.nl/IT_architecture_sketching
HBO-I. (2018, jan 18). Pitch. Opgehaald van HBO-I: http://ictresearchmethods.nl/Pitch
HBO-I. (2018, jan 18). Unit-test. Opgehaald van HBO-I: http://ictresearchmethods.nl/Unit_test
HBO-i. (2019, feb 9). Expert interview. Opgehaald van HBO-i: http://ictresearchmethods.nl/Expert_interview
HBO-i. (2019, fab 9). Literature study. Opgehaald van ictresearchmethods.nl: http://ictresearchmethods.nl/Literature_study
HBO-i. (2018, jan 18). Community research. Opgehaald van HBO-i.: http://ictresearchmethods.nl/Community_research
hbo-i. (2018, jan 18). Methoden Toolkit HBO-i. Opgehaald van onderzoek.hbo-i: https://onderzoek.hbo-i.nl/index.php/Methoden_Toolkit_HBO-i
In-memory database. (2019, sep 22). Opgehaald van wikipedia: https://en.wikipedia.org/wiki/In-memory_database
jeps. (2014, april 27). Benchmarking Apache Kafka: 2 Million Writes Per Second (On Three Cheap Machines). Opgehaald van engineering.linkedin.com/: https://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2- million-writes-second-three-cheap-machines
kubernetes. (2020, oktober 17). Horizontal Pod Autoscaler. Opgehaald van kubernetes:
https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autosc ale/
laravel. (sd). Redis. Opgehaald van laravel: https://laravel.com/docs/7.x/redis microsoft. (2020, 02 11). Command and Query Responsibility Segregation (CQRS)
pattern. Opgehaald van docs.microsoft.com:
https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs#eve nt-sourcing-and-cqrs
Narkhede, N. (2017, juni 30). Exactly-once Semantics are Possible: Here’s How Kafka Does it. Opgehaald van confluent.io:
https://www.confluent.io/blog/exactly-once-semantics-are-possible-her es-how-apache-kafka-does-it/
Netflix. (2013). Netflix / aminator. Opgehaald van Github.com: https://github.com/Netflix/aminator
opengroup. (sd). The ArchiMate® Enterprise Architecture Modeling Language | The Open Group Website . Opgehaald van Opengroup:
https://www.opengroup.org/archimate-forum/archimate-overview Paans, F. (2017, mei 10). Microservices: wanneer wel, wanneer niet? Opgehaald
van
https://www.emerce.nl/achtergrond/microservices-wel-of-niet-gebruike n:
https://www.emerce.nl/achtergrond/microservices-wel-of-niet-gebruike n
php-rdkafka. (2020, juni 26). PHP Kafka client - php-rdkafka. Opgehaald van github: https://github.com/arnaud-lb/php-rdkafka
RabbitMQ vs Apache Kafka. (2018). Opgehaald van linuxhint: https://linuxhint.com/rabbitmq-vs-apache-kafka/ redis. (sd). Introduction to Redis. Opgehaald van redis.io:
Richards, M. (2018, april 8). Lesson 12 - CQRS and Microservices. Opgehaald van youtube: https://www.youtube.com/watch?v=pUGvXUBfvEE
Richardson, C. (2016, feb 10). Choosing a Microservices Deployment Strategy. Opgehaald van nginx.com:
https://www.nginx.com/blog/deploying-microservices/
Richardson, C. (2019, 1 28). Microservices anti-patterns in Melbourne. Opgehaald van
http://chrisrichardson.net/post/antipatterns/2019/01/28/melbourne-micr oservices.html:
http://chrisrichardson.net/post/antipatterns/2019/01/28/melbourne-micr oservices.html
Richardson, C. (2019). Pattern: Microservice Architecture. Opgehaald van microservices.io: https://microservices.io/patterns/microservices.html Richardson, C. (sd). Applying the microservice architecture pattern language.
Opgehaald van microservices:
https://microservices.io/articles/applying.html
Richardson, C. (sd). Pattern: Multiple service instances per host. Opgehaald van microservices.io:
https://microservices.io/patterns/deployment/multiple-services-per-hos t.html
Richardson, C. (sd). Pattern: Service Instance per VM. Opgehaald van
https://microservices.io/patterns/deployment/service-per-vm.html: https://microservices.io/patterns/deployment/service-per-vm.html Richardson, C. (sd). Pattern: Single Service Instance per Host. Opgehaald van
microservices.io:
https://microservices.io/patterns/deployment/single-service-per-host.ht ml
Sookocheff, K. (2015, sep 2015). Kafka in a Nutshell. Opgehaald van sookocheff: https://sookocheff.com/post/kafka/kafka-in-a-nutshell/
Spatie. (sd). Laravel-event-sourcing. Opgehaald van spatie:
https://spatie.be/docs/laravel-event-sourcing/v3/introduction Varghese, S. (2017, jul 4). Microservices: Overview, Misinterpretations and
Misuses. Opgehaald van medium.com:
https://medium.com/@shijuvar/microservices-overview-misinterpretatio ns-and-misuses-56a1979edafb
What is Domain-Driven Design? (2007, 03 28). Opgehaald van dddcommunity.org:
https://dddcommunity.org/learning-ddd/what_is_ddd/
Wrong Ways of Defining Service Boundaries. (2017, jun 22). Opgehaald van medium.com: https://medium.com/hackernoon/wrong-ways-of-defining-service-boun daries-d9e313007bcc
10. Bijlagen
Interviews
De hoofdvragen die zijn gebruikt bij het interview:
1. Welke problemen kom jij tegen als je werkt met het systeem? 2. Waarom is dit een probleem?
3. Wat zou een oplossing zijn voor dit probleem? 4. Wat zijn de knelpunten in het systeem?
5. Waarom zijn dit de knelpunten? 6. Wat is een microservice?
7. Zou een microservice-architectuur een oplossing kunnen zijn (waarom wel, waarom niet)?
Matthijs Schonewile (Front-end developer):
Het probleem van Verzuimsignaal is dat alles inderdaad in één grote applicatie zit. Alles is met alles verbonden en dat maakt het doen van aanpassingen heel lastig. We kunnen niet één ding aanpassen zonder dat het allerlei andere delen raakt. Daarnaast is de performance niet optimaal - ook weer omdat alles in één grote bak zit.
Wat ik wel kan beantwoorden is de vraag welke problemen ik heb wanneer ik in Verzuimsignaal werk.
Ontwikkelen duurt langer omdat er talloze includes zijn die ik niet één-twee-drie kan verklaren of thuisbrengen. Alles is met elkaar verbonden en dat maakt het vaak lastig om even wat kleins op te pakken. Het is vaak niet klein. Er zijn ook vaak in het
verleden allerlei pleisters geplakt om probleempjes op te lossen, waardoor het echte probleem nooit is opgelost. Die pleisters zijn lastig te begrijpen en het probleem is er ook nog. Hierdoor ben ik vaak lang bezig met eerst uitzoeken wat het probleem is. Dus voor nieuwe programmeurs is het ook lastig om aan de applicatie te werken - omdat het zo groot en veel is.
En omdat alles met alles is verbonden moet je dus ook alles testen bij oplevering. Oké, het is minder zwart-wit dan ik nu aangeef, maar het is al wel voorgekomen dat
door aanpassing A een bestaande feature B omviel.
Als de applicatie uit meerdere kleine stukjes zou bestaan, dan is het makkelijker om een stukje te vervangen of aan te passen omdat de scope dan veel kleiner is.
Verder hebben wij er ook enorm last van dat echt alles bij elkaar in zit,
php/html/css/js/db, echt alles. En dat maakt het dubbel zo lastig om bijvoorbeeld de look en feel aan te passen
Frank Leijzer (Tester van Verzuimsignaal)
Welke problemen kom jij tegen als je werkt met het systeem?
Lastig, want waar ik vooral mee bezig ben is testen. Hierbij test ik nieuwe features en bugfixes die worden released. Hierbij moet ik kijken of de nieuwe feature of bugfix niet iets anders weer stuk maakt. Dit is soms een probleem want je weet nooit zeker dat de feature niet een ander gedeelte van het systeem stuk maakt. Hierdoor moet ik alle basisfunctionaliteiten testen voordat er een nieuwe release komt.
Wat zou een oplossing zijn voor dit probleem?
Richard is al bezig met het schrijven om de testen automatisch te maken. Hierdoor hoef ik straks niet meer de testen uit te voeren.
Wat zijn de knelpunten in het systeem?
Wanneer ik werk en een test uitvoer, gaat de test in één keer heel veel
functionaliteiten af, maar wanneer hij crasht stopt die de gehele test en moet je de test weer opnieuw laten runnen.
Waarom zijn dit de knelpunten?
Het is een knelpunt omdat het uitvoeren van een test lang duurt en als een test crasht stopt hij direct en je weet niet of de resterende functionaliteiten die de test nog moet uitvoeren ook werken.
Wat is een microservice? Ik weet er zelf niet zo veel van.
Zou een microservice-architectuur een oplossing kunnen zijn (waarom wel, waarom niet)?
Het concept lijkt mij echt wel een goede oplossing, vooral omdat je dan kunt testen per microservice.
Gillian Lo Wong (Back-end developer)
Welke problemen kom jij tegen als je werkt met het systeem?
Verzuimsignaal is op zichzelf een groot monoliet en heeft daarnaast ook
afhankelijkheden die je geïnstalleerd en juist geconfigureerd moet hebben om het geheel werkend te kunnen krijgen. Bijvoorbeeld het inloggen via een login-cluster, een apart project, of de verificatie van postcodes, een aparte SOAP-call. Daarnaast is teveel code met andere delen van de applicatie verweven.
Waarom is dit een probleem?
Als je ontwikkelingen doet in VS dan moet je altijd rekening houden met het feit dat andere projecten jouw code ook zullen inladen en draaien. Hierdoor wordt de scope en daarmee het risico op fouten erg groot. Je moet andere projecten ook testen, zodat deze compatibel zijn met jouw ontwikkelingen. Een simpele aanpassing in het systeem kan dus grote implicaties hebben. Vaak zien we dat een relatief simpele feature een zodanig grote impact en tijdsduur kan hebben dat er simpelweg wordt gekozen om deze niet te doen en dat is zonde.
Wat zou een oplossing zijn voor dit probleem?
Domain driven design. Single responsibility principle, Strangler pattern: code uit Verzuimsignaal halen en generiek opzetten met bijvoorbeeld API's. Door code los te halen maken we de codebase kleiner en daardoor verkleinen we het risico op bugs.
Wat zijn de knelpunten in het systeem?
Zwaar verouderde code, veel gedupliceerde code en veel te grote queries. Voor de klant: veel traagheid. Inloggen kan bij sommige klanten lang duren en overzichten laden duurt lang wegens de grote queries.
Waarom zijn dit de knelpunten?
Omdat dit als gevolg heeft dat de klant niet lekker door de applicatie kan klikken.
Wat is een microservice?
Een service zoals bijvoorbeeld een html naar pdf-generator die alleen maar pdf's genereert. Elk project dat pdf's wil genereren kan die microservice gebruiken. Doordat deze microservice alleen maar één ding doet, kun je het heel makkelijk onderhouden afzonderlijk van andere code. Voor meer info, zie Google.
Marjolein Tibbe (Product owner) Waarom is dit een probleem?
Het zorgt dat de verwerkingstijd van bugs heel erg lang is en dat er meerdere malen bugs doorheen gaan die eigenlijk geen bug zijn. Combineer dit met een traag systeem en je bent nog meer tijd kwijt. Het is zonde, want die tijd zouden we beter kunnen besteden aan nieuwe ontwikkelingen.
Wat zou een oplossing zijn voor dit probleem?
Betere logging, betere documentatie en terug naar een productvisie met zo min mogelijk maatwerk. Het moet een echt één fix-for-all worden.
Wat zijn de knelpunten in het systeem?
Responstijden zijn traag. Inloggen kan tot 45 seconden duren, een scherm laden duurt soms een eeuwigheid, zoeken gaat langzaam, data importeren geeft meer dan eens een time out, net als zoekfunctionaliteiten en exports.
Waarom zijn dit de knelpunten?
Niemand zit te wachten op een traag systeem en voor nu kan Verzuimsignaal wel echt aangemerkt worden als een traag systeem. Gebruikers denken vaak dat zaken niet werken, dat is echter niet zo, maar ze moeten nog langer wachten. Gevolg is nogmaals een export opvragen en nog langer wachten.
Zou een microservice-architectuur een oplossing kunnen zijn (waarom wel, waarom niet)?
Ik denk deels wel. Het maakt informatie gestructureerder beschikbaar en de functie van een microservice is duidelijk. Dit betekent dat het ding doet waar hij voor
gemaakt is en er geen extra stress op komt te staan. Het optimaliseren van de query's is hierbij ook belangrijk. Als je ziet hoe deze in elkaar zitten, is dit vaak verre van een optimale werking. Het combineren van query's om in één keer de juiste gegevens op te halen moet ook een hoop doen. Door de combinatie microservices en query-optimalisatie in te zetten, zou dit probleem niet meer moeten bestaan. Oké, misschien moeten we ook wat database opschoning doen.