De Nationale Politie is druk bezig met het opbouwen van een netwerkomgeving waarin gretig van een microservices-architectuur gebruikgemaakt wordt. Het grote voordeel van microservices gebruiken is de mogelijkheid er kleine, doelgerichte applicaties mee te bouwen.
De Nationale Politie is de afgelopen jaren een heel eind gevorderd in het bouwen en onderhouden van bijvoorbeeld slimme databases om relschoppers te identificeren en op te sporen, applicaties om gevaarlijke verkeersplekken in kaart te brengen en om sociale media te gebruiken om incidenten sneller af te handelen. Om de ontstane kennis rond het opbouwen van microservices te delen met de Java-community, vertelde Bert Jan Schrijver over zijn ervaringen bij de politie tijdens de Java Summit bij iSense ICT Professionals.
Een van de belangrijkste redenen voor het gebruik van microservices is dat het zeer schaalbaar is, iets wat steeds belangrijker wordt in een wereld waarin criminaliteit zich vaak afspeelt in de digitale wereld. Om de diensten voor de politie op te zetten, ging de productlijn Cloud, Big data en Internet van de Nationale Politie aan de slag met drie DevOps-teams om big-data-webapplicaties te bouwen in een beveiligde netwerkomgeving.
Voordeel is ook nadeel
Schrijver noemt het grote voordeel, kleine en doelgerichte applicaties bouwen, ook een potentieel nadeel. De kleine, onafhankelijk van elkaar bewegende deeltjes zijn per stuk misschien makkelijker te beheren, ze zorgen tegelijkertijd ook voor complexiteit omdat het zo veel systemen zijn die weer onderling verbonden zijn. Ontwikkelaars moeten van meerdere markten thuis zijn om problemen op te kunnen lossen, maar aan de andere kant is elk individueel component makkelijker aan te passen dan grote monolithische structuren.
Het opzetten van multidisciplinaire teams rondom producten is een goede start. Daarmee kan elk team zelfstandig aan die producten ontwikkelen werken waarvoor het team verantwoordelijk is, zonder afhankelijk van andere teams te zijn. Daartegenover staat wel weer dat de teams ook onderling contact moeten houden over technologie-keuzes en werkwijzen.
De teams bij de productlijn Cloud, Big data en Internet gebruiken uitsluitend opensource producten om zo licentiekosten te drukken en vooral in kennis en ervaring te investeren. Om overzicht te houden op het landschap van services kozen de teams voor Consul, een tool van HashiCorp. Hiermee wordt snel inzichtelijk wat waar draait binnen het netwerk. Voor het testen van de performance gebruiken de teams Gatling, een tool op basis van Scala, Akka en Netty. Hiermee kunnen via een dsl-performance tests worden gedefinieerd en wordt continu getest of alle individuele services snel genoeg reageren. Het bouwen van de frontend gebeurde met Angular 5, volgens Schrijver heel fijn om mee te werken omdat er een sterke componenten-architectuur is en het schrijven van de code met TypeScript gebeurt, waardoor het bijna Java lijkt.
Gat
Enige lacune die het werken met opensource-producten met zich meebrengt is volgens Schrijver het gat op het gebied van security tools. Op dat vlak is nog terrein te winnen van de vaak wat uitgebreidere commerciële tools. De teams vangen dat op door in code reviews veel aandacht aan security te besteden.
Schrijver waarschuwt wel dat als de infrastructuur en het serverbeheer nog niet zo ver is, je beter niet aan microservices kunt beginnen. Eerst was het veel handwerk, maar uiteindelijk is met een combinatie van Terraform, Puppet en wat zelfgeschreven scripts maar een druk op de knop nodig om de service in gang te zetten.
Een focuspunt voor de toekomst bij het project bij de politie is het verbeteren van de deployments. Het uitrollen van nieuwe versies moet op elk moment geautomatiseerd kunnen zonder dat gebruikers daar iets van merken. Nu zitten daar nog een aantal handmatige acties voor de teams in. Verder ziet Schrijver nog verbeteringen op het gebied van alerts, automatische notificaties en monitoring.
‘Klein beginnen is prima te doen met microservices. Zoek naar pijnplekken in de organisatie en bedenk wat je kunt doen om ze op te lossen’, zegt Schrijver. En vergeet niet de successen te vieren, ook al zijn het maar kleine stapjes. Dat laatste is volgens hem belangrijk, juist omdat de kleine stapjes sneller zorgen voor draagvlak binnen de organisatie. ‘In alle lagen moet vertrouwen ontstaan in het werk van de it-afdeling’, aldus Schrijver. Het zorgt voor meer vrijheid om slimme verbeteringen door te voeren. Op die manier kan een organisatie ‘ruimschoots profiteren van de laatste technologische ontwikkelingen’, besluit hij.
Is er naast het security aspect nagedacht over het monitoren van deze microservices? Met traditionele monitoring kom je er echt niet meer. En daar vat ik ook Prometheus onder, waar sommige fintech bedrijven beginnen te ondervinden dat het niet voldoet aan de behoefte om grip en controle te hebben op de performance van deze paddenstoel architectuur. En traditioneel is het dat organisatie er pas veel te laat achterkomen dat adequate monitoring nodig is, omdat het namelijk leuker is om eerst te knutselen en daarna pas na te denken.
Terechte vraag, en mee eens: observabiliteit van microservices is belangrijk. Uit hoe meer losse onderdelen een systeem bestaat, hoe lastiger het is om overzicht over het geheel te houden. Voor monitoring, metrics, logging en tracing gebruiken we open source tools als Sensu, Flapjack, Consul, Grafana, Graylog, Zipkin en inderdaad: Prometheus. We kijken onder andere naar beschikbaarheid, load, responstijden en JVM-statistieken (memory, garbage collection, etc). Heb je hier nog andere ideeen over? Ik wissel er graag eens met je van gedachten over.