Building microservices with Vert.x
Bert Jan Schrijver
AMSTERDAM 11-12 MAY 2016
@bjschrijver
Let’s meet
Bert Jan Schrijver
@bjschrijver
- Introduction
- Why Vert.x?
- Basic demo
- Deep dive
- Advanced demo
- Microservices with Vert.x
- Vert.x in practice
Outline
- Introduction
- Why Vert.x?
- Deep dive
- Demo
- Microservices with Vert.x
Introduction
Malmberg	is	an	educational	
publisher	in	the	Netherlands.

Malmberg	is	building	modern,	
rich	and	scalable	e-learning	
applications	using	Java	8,	Vert.x,	
AngularJS	and	MongoDB,	
running	on	Amazon		
cloud	services.
Vert.x basics
@bjschrijver
- Toolkit for building reactive applications on the JVM
- General purpose application framework
- Swiss army knife for building modern and scalable
web apps
- Event-driven, non-blocking
- Polyglot
- Lightweight and fast
- Fun to work with!
Vert.x: the basics
- We love open source
- Powerful module system
- Reactive characteristics
Why did we choose Vert.x?
Vert.x is reactive
Demo
@bjschrijver
Vert.x in depth
@bjschrijver
- Verticle, application, instance, JVM:
Vert.x in depth
Host
JVM
Vert.x instance
Verticle Verticle
Verticle Verticle
Event Bus
JVM
Vert.x instance
Verticle Verticle
Verticle Verticle
- Verticle, application, instance, JVM:
Host
Vert.x in depth
Host
JVM
Vert.x instance
Verticle Verticle
Verticle Verticle
Event Bus
JVM
Vert.x instance
Verticle Verticle
Verticle Verticle
- Event driven and non blocking event loop
- Multi-reactor pattern
- Actor-like concurrency
- Distributed event bus
- Management and monitoring built-in
Vert.x in depth
- Both request/response and publish/
subscribe
- Messages are received by Handlers
- All Vert.x instances have access to the
event bus
- Verticles interact using messages
Vert.x event bus
- Never ever ever block the event loop
- Need to to blocking stuff? Use a worker
Vert.x’s golden rule
Source: http://www.slideshare.net/clement.escoffier/vertx-31-be-reactive-on-the-jvm-but-not-only-in-java
Vert.x in one slide
Demo
@bjschrijver
Vert.x & microservices
@bjschrijver
- Small in size, single responsibility
- Runs in its own process
- Has its own data store
- Distributed by default
- Independently develop, deploy, upgrade, scale
- Potentially heterogeneous/polyglot
- Light-weight communication
Anatomy of a microservice
microserviceAnatomy of a Vert.x module
- Small in size, single responsibility
- Runs in its own process
- Has its own data store
- Distributed by default
- Independently develop, deploy, upgrade, scale
- Potentially heterogeneous/polyglot
- Light-weight communication
Vert.x in practice
@bjschrijver
- Organisation structure:
- Core platform team (infrastructure)
- Core modules team (Vert.x modules)
- Product teams
- Deployment model: AWS, Nginx, MongoDB
- Multiple lightweight artifacts
3 years of Vert.x: situation
3 years of Vert.x: deployments
- Rolled our own deployment tooling and
open sourced it

(https://github.com/msoute/vertx-deploy-tools)
- Controlled from Jenkins
- Zero-downtime deployments
- Microservice deployments
- Very suitable for test driven development
- Integration tests with embedded MongoDB
- Good cooperation from the Vert.x team
3 years of Vert.x: experiences
- Callback hell
- Java 8 helped a LOT
- Rx fixes the remaining issues
- Blocking the event loop
- Scaling / JVM overhead
- Debugging
- Static code analysis
- Upgrade from Vert.x 2 to Vert.x 3
3 years of Vert.x: challenges
Almost there ;-)
@bjschrijver
- Vert.x: toolkit for reactive applications on
the JVM
- Polyglot, event-driven
- Very suitable for building microservices
Summary
- https://github.com/bertjan/vertx3-examples
- http://vertx.io
- http://vertx.io/blog/my-first-vert-x-3-
application
- https://github.com/vert-x3/vertx-examples
- http://github.com/msoute/vertx-deploy-tools
Resources
Don’t worry, I’ll tweet a link to the slide deck ;-)
Q & A
@bjschrijver
Thanks!
@bjschrijver

bertjan@jpoint.nl
All pictures belong
to their respective authors
AMSTERDAM 9-12 MAY 2016

Codemotion Amsterdam 2016 - Building microservices with Vert.x

  • 1.
    Building microservices withVert.x Bert Jan Schrijver AMSTERDAM 11-12 MAY 2016 @bjschrijver
  • 2.
    Let’s meet Bert JanSchrijver @bjschrijver
  • 3.
    - Introduction - WhyVert.x? - Basic demo - Deep dive - Advanced demo - Microservices with Vert.x - Vert.x in practice Outline
  • 4.
    - Introduction - WhyVert.x? - Deep dive - Demo - Microservices with Vert.x Introduction Malmberg is an educational publisher in the Netherlands.
 Malmberg is building modern, rich and scalable e-learning applications using Java 8, Vert.x, AngularJS and MongoDB, running on Amazon cloud services.
  • 5.
  • 6.
    - Toolkit forbuilding reactive applications on the JVM - General purpose application framework - Swiss army knife for building modern and scalable web apps - Event-driven, non-blocking - Polyglot - Lightweight and fast - Fun to work with! Vert.x: the basics
  • 7.
    - We loveopen source - Powerful module system - Reactive characteristics Why did we choose Vert.x?
  • 8.
  • 9.
  • 10.
  • 11.
    - Verticle, application,instance, JVM: Vert.x in depth Host JVM Vert.x instance Verticle Verticle Verticle Verticle Event Bus JVM Vert.x instance Verticle Verticle Verticle Verticle
  • 12.
    - Verticle, application,instance, JVM: Host Vert.x in depth Host JVM Vert.x instance Verticle Verticle Verticle Verticle Event Bus JVM Vert.x instance Verticle Verticle Verticle Verticle
  • 13.
    - Event drivenand non blocking event loop - Multi-reactor pattern - Actor-like concurrency - Distributed event bus - Management and monitoring built-in Vert.x in depth
  • 14.
    - Both request/responseand publish/ subscribe - Messages are received by Handlers - All Vert.x instances have access to the event bus - Verticles interact using messages Vert.x event bus
  • 15.
    - Never everever block the event loop - Need to to blocking stuff? Use a worker Vert.x’s golden rule
  • 16.
  • 17.
  • 18.
  • 19.
    - Small insize, single responsibility - Runs in its own process - Has its own data store - Distributed by default - Independently develop, deploy, upgrade, scale - Potentially heterogeneous/polyglot - Light-weight communication Anatomy of a microservice
  • 20.
    microserviceAnatomy of aVert.x module - Small in size, single responsibility - Runs in its own process - Has its own data store - Distributed by default - Independently develop, deploy, upgrade, scale - Potentially heterogeneous/polyglot - Light-weight communication
  • 21.
  • 22.
    - Organisation structure: -Core platform team (infrastructure) - Core modules team (Vert.x modules) - Product teams - Deployment model: AWS, Nginx, MongoDB - Multiple lightweight artifacts 3 years of Vert.x: situation
  • 23.
    3 years ofVert.x: deployments - Rolled our own deployment tooling and open sourced it
 (https://github.com/msoute/vertx-deploy-tools) - Controlled from Jenkins - Zero-downtime deployments - Microservice deployments
  • 24.
    - Very suitablefor test driven development - Integration tests with embedded MongoDB - Good cooperation from the Vert.x team 3 years of Vert.x: experiences
  • 25.
    - Callback hell -Java 8 helped a LOT - Rx fixes the remaining issues - Blocking the event loop - Scaling / JVM overhead - Debugging - Static code analysis - Upgrade from Vert.x 2 to Vert.x 3 3 years of Vert.x: challenges
  • 26.
  • 27.
    - Vert.x: toolkitfor reactive applications on the JVM - Polyglot, event-driven - Very suitable for building microservices Summary
  • 28.
    - https://github.com/bertjan/vertx3-examples - http://vertx.io -http://vertx.io/blog/my-first-vert-x-3- application - https://github.com/vert-x3/vertx-examples - http://github.com/msoute/vertx-deploy-tools Resources Don’t worry, I’ll tweet a link to the slide deck ;-)
  • 29.
  • 30.
    Thanks! @bjschrijver
 bertjan@jpoint.nl All pictures belong totheir respective authors AMSTERDAM 9-12 MAY 2016