• No results found

Conclusie en aanbevelingen 

In document Van een monoliet naar microservice (pagina 50-60)

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.   

In document Van een monoliet naar microservice (pagina 50-60)