Continuous Delivery Amsterdam - Microservices in action at the Dutch National Police

Bert Jan Schrijver
Bert Jan SchrijverCTO at OpenValue
bertjan@jpoint.nl
Microservices in action
at the Dutch National Police
Bert Jan Schrijver
@bjschrijver
Bert Jan Schrijver
L e t ’ s m e e t
@bjschrijver
Architecture and
platform
Frontend
Methodology
and culture
Introduction
Development and
testing
Build tools, deployments
and running in production
Challenges and
looking ahead
Outline
W h a t ‘ s n e x t ?
Backend
The police protects the
democracy, maintains the law
and is the authority on the
streets. Around 65.000 people
work at the Dutch police, of
which over 1500 IT
professionals.
Dutch National Police
CLOUD
PLATFORM
ANALYSE
PATRONEN
BIG DATA
SECURITY3 DevOps teams are building
high tech big data web
applications in a private cloud
environment. These
applications support police
related themes.
Product line
Cloud | Big Data | Internet
Methodology and culture
• 3 teams with separate backlogs
• Overall planning at start of sprint
• Minimal planning ritual
• Usability tests as part of sprint
• Phabricator as tool of choice
Methodology
• Continuous Delivery & DevOps
• Short feedback loops
• Embrace change
• Minimal dependencies outside team
• Invest in people, not in products
• Open, transparent, verifiable
Culture
Source: http://kids.nationalgeographic.com/explore/countries/netherlands/#netherlands-tulip-fields.jpg
Architecture and platform
• End-to-end security and encryption
• Version control for everything
• Horizontally scalable, no single point of failure
• No dependencies on external sources
• Standardised naming
• Application config lives with code
• Services defined by business functionality
Architecture
Architecture
Current architecture
Current architecture
Current architecture
Current architecture
Current architecture
Current architecture
Current architecture
Current architecture
Source: https://www.google.com/about/datacenters
• Openstack private cloud
• General cloud services for police 

organisation
• Ceph distributed storage
• Puppet & Ansible for config management
• 3000 managed desktops
• Automation starts when hardware boots
Platform
Frontend
• Angular 2.x
• Typescript
• RxJS
• Bootstrap
• Responsive design
• Feature toggles
• Graceful degradation when backend fails
Frontend
Backend
• Small in size, single responsibility
• Runs in its own process
• Independently develop, deploy, upgrade, scale
• Has its own data store
• Distributed by default
• Potentially heterogeneous/polyglot
• Light-weight communication
Anatomy of a microservice
• Spring Boot, Java 8, Maven
• Stateless
• 1 service in 1 jar on 1 JVM on 1 host
• Now: high available via Openstack load balancers
• Future: move from LB’s to service discovery
• Minimal amount of shared code:
• Security
• Logging and metrics
Backend
Development and testing
• Local environment runs only the
component(s) that are being developed
• For other components, local env connects
to development env on Openstack
• Feature branch based development
• Master branch must always be releasable
Development
• Unit tests: JUnit, Karma
• Mutation tests with PIT
• Service/integration tests: Spring boot
integration, embedded in-memory data
stores, REST assured
• End-to-end test: Protractor
• Load tests: Gatling
Testing
Build tools, deployments
and running in production
• Gitlab
• Jenkins with Docker swarm slave nodes
• Jenkins 2 pipelines
• Nexus
• Sonar
Build tools
• Every push to master is a release
• Config is embedded in executable jar
• Deployments via Rundeck and Puppet
• Development: deploy service on commit
• Everything from dev -> acc during sprint
• Everything from acc -> prod after sprint
• Single service dev -> acc -> prod when needed
Deployments
• Logging and dashboards via Graylog
• Metrics:
• Spring Boot actuator
• Grafana
• Kafka stats via Burrow
• Monitoring via Sensu and Flapjack
Running in production
Photo: Dave Lehl
Challenges and looking ahead
Challenges
01
Share as little as possible; prefer
duplication over coupling.
Sharing code between services
04Authentication and authorisation
happen at every request. Find the
balance between performance and
security.
Running stateless has a cost
When moving fast,
don’t forget to finish up before
starting something new.
Switching focus has a cost
06
Throwing something away and
starting over can work out better
than refactoring.
Don’t be afraid to rebuild03
Microservices are not just for the
backend. Modularity is just as
imported on the frontend.
Monolithic frontend
02
Minimalize dependencies on
other teams, or it will slow you
down.
Cross functional team
composition is vital
05
and lessons learned
Looking ahead
Upgrades and fixes without users even
noticing.
0-downtime deployments
Our plans for the (near) future.
@bjschrijver
Cross-functional teams with vertical
(full stack) responsibilities.
Product teams
Split the frontend in products and re-
usable components.
Modular frontend
There is no silver bullet here, but useful
tools and practices do exist.
Automated security testing
Get the teams the information they
need, but only when they need it.
Better dashboards and alerting
Questions?
@bjschrijver
Thanks for your time.
Got feedback? Tweet it!
All pictures belong
to their respective
authors
@bjschrijver
1 de 37

Más contenido relacionado

Similar a Continuous Delivery Amsterdam - Microservices in action at the Dutch National Police(20)

Microservices: Yes or not?Microservices: Yes or not?
Microservices: Yes or not?
Eduard Tomàs943 vistas
Technology insights: Decision Science PlatformTechnology insights: Decision Science Platform
Technology insights: Decision Science Platform
Decision Science Community154 vistas
QCon 2015 - Microservices Track Notes QCon 2015 - Microservices Track Notes
QCon 2015 - Microservices Track Notes
Abdul Basit Munda541 vistas
All about that reactive uiAll about that reactive ui
All about that reactive ui
Paul van Zyl351 vistas
Manging Container Deployments at ScaleManging Container Deployments at Scale
Manging Container Deployments at Scale
Mofizur Rahman130 vistas
Design Like a Pro: Planning Enterprise SolutionsDesign Like a Pro: Planning Enterprise Solutions
Design Like a Pro: Planning Enterprise Solutions
Inductive Automation173 vistas
Design Like a Pro: Planning Enterprise SolutionsDesign Like a Pro: Planning Enterprise Solutions
Design Like a Pro: Planning Enterprise Solutions
Inductive Automation498 vistas

Último(20)

WEB 2.O TOOLS: Empowering education.pptxWEB 2.O TOOLS: Empowering education.pptx
WEB 2.O TOOLS: Empowering education.pptx
narmadhamanohar218 vistas
Is Entireweb better than GoogleIs Entireweb better than Google
Is Entireweb better than Google
sebastianthomasbejan10 vistas
Audience profile.pptxAudience profile.pptx
Audience profile.pptx
MollyBrown8612 vistas
UiPath Document Understanding_Day 2.pptxUiPath Document Understanding_Day 2.pptx
UiPath Document Understanding_Day 2.pptx
RohitRadhakrishnan8265 vistas
Existing documentaries (1).docxExisting documentaries (1).docx
Existing documentaries (1).docx
MollyBrown8613 vistas
childcare.pdfchildcare.pdf
childcare.pdf
fatma alnaqbi13 vistas
informationinformation
information
khelgishekhar6 vistas
UiPath Document Understanding_Day 3.pptxUiPath Document Understanding_Day 3.pptx
UiPath Document Understanding_Day 3.pptx
UiPathCommunity87 vistas
Sustainable MarketingSustainable Marketing
Sustainable Marketing
Theo van der Zee7 vistas
informing ideas.docxinforming ideas.docx
informing ideas.docx
MollyBrown8612 vistas
Serverless cloud architecture patternsServerless cloud architecture patterns
Serverless cloud architecture patterns
Jimmy Dahlqvist17 vistas
zotabet.pdfzotabet.pdf
zotabet.pdf
zotabetcasino6 vistas
AI Powered event-driven translation botAI Powered event-driven translation bot
AI Powered event-driven translation bot
Jimmy Dahlqvist16 vistas
KHNOG 5: RPKI Status UpdateKHNOG 5: RPKI Status Update
KHNOG 5: RPKI Status Update
APNIC401 vistas

Continuous Delivery Amsterdam - Microservices in action at the Dutch National Police

  • 1. bertjan@jpoint.nl Microservices in action at the Dutch National Police Bert Jan Schrijver @bjschrijver
  • 2. Bert Jan Schrijver L e t ’ s m e e t @bjschrijver
  • 3. Architecture and platform Frontend Methodology and culture Introduction Development and testing Build tools, deployments and running in production Challenges and looking ahead Outline W h a t ‘ s n e x t ? Backend
  • 4. The police protects the democracy, maintains the law and is the authority on the streets. Around 65.000 people work at the Dutch police, of which over 1500 IT professionals. Dutch National Police
  • 5. CLOUD PLATFORM ANALYSE PATRONEN BIG DATA SECURITY3 DevOps teams are building high tech big data web applications in a private cloud environment. These applications support police related themes. Product line Cloud | Big Data | Internet
  • 7. • 3 teams with separate backlogs • Overall planning at start of sprint • Minimal planning ritual • Usability tests as part of sprint • Phabricator as tool of choice Methodology
  • 8. • Continuous Delivery & DevOps • Short feedback loops • Embrace change • Minimal dependencies outside team • Invest in people, not in products • Open, transparent, verifiable Culture Source: http://kids.nationalgeographic.com/explore/countries/netherlands/#netherlands-tulip-fields.jpg
  • 10. • End-to-end security and encryption • Version control for everything • Horizontally scalable, no single point of failure • No dependencies on external sources • Standardised naming • Application config lives with code • Services defined by business functionality Architecture
  • 20. Source: https://www.google.com/about/datacenters • Openstack private cloud • General cloud services for police 
 organisation • Ceph distributed storage • Puppet & Ansible for config management • 3000 managed desktops • Automation starts when hardware boots Platform
  • 22. • Angular 2.x • Typescript • RxJS • Bootstrap • Responsive design • Feature toggles • Graceful degradation when backend fails Frontend
  • 24. • Small in size, single responsibility • Runs in its own process • Independently develop, deploy, upgrade, scale • Has its own data store • Distributed by default • Potentially heterogeneous/polyglot • Light-weight communication Anatomy of a microservice
  • 25. • Spring Boot, Java 8, Maven • Stateless • 1 service in 1 jar on 1 JVM on 1 host • Now: high available via Openstack load balancers • Future: move from LB’s to service discovery • Minimal amount of shared code: • Security • Logging and metrics Backend
  • 27. • Local environment runs only the component(s) that are being developed • For other components, local env connects to development env on Openstack • Feature branch based development • Master branch must always be releasable Development
  • 28. • Unit tests: JUnit, Karma • Mutation tests with PIT • Service/integration tests: Spring boot integration, embedded in-memory data stores, REST assured • End-to-end test: Protractor • Load tests: Gatling Testing
  • 29. Build tools, deployments and running in production
  • 30. • Gitlab • Jenkins with Docker swarm slave nodes • Jenkins 2 pipelines • Nexus • Sonar Build tools
  • 31. • Every push to master is a release • Config is embedded in executable jar • Deployments via Rundeck and Puppet • Development: deploy service on commit • Everything from dev -> acc during sprint • Everything from acc -> prod after sprint • Single service dev -> acc -> prod when needed Deployments
  • 32. • Logging and dashboards via Graylog • Metrics: • Spring Boot actuator • Grafana • Kafka stats via Burrow • Monitoring via Sensu and Flapjack Running in production
  • 33. Photo: Dave Lehl Challenges and looking ahead
  • 34. Challenges 01 Share as little as possible; prefer duplication over coupling. Sharing code between services 04Authentication and authorisation happen at every request. Find the balance between performance and security. Running stateless has a cost When moving fast, don’t forget to finish up before starting something new. Switching focus has a cost 06 Throwing something away and starting over can work out better than refactoring. Don’t be afraid to rebuild03 Microservices are not just for the backend. Modularity is just as imported on the frontend. Monolithic frontend 02 Minimalize dependencies on other teams, or it will slow you down. Cross functional team composition is vital 05 and lessons learned
  • 35. Looking ahead Upgrades and fixes without users even noticing. 0-downtime deployments Our plans for the (near) future. @bjschrijver Cross-functional teams with vertical (full stack) responsibilities. Product teams Split the frontend in products and re- usable components. Modular frontend There is no silver bullet here, but useful tools and practices do exist. Automated security testing Get the teams the information they need, but only when they need it. Better dashboards and alerting
  • 37. Thanks for your time. Got feedback? Tweet it! All pictures belong to their respective authors @bjschrijver