Vert.x is a toolkit for building reactive applications on the JVM. It's event driven, non blocking and polyglot, which makes it an excellent platform for building microservices. In this talk, I'll share experiences and from a Dutch company that started building reactive web applications with Vert.x about 3 years ago. You'll learn the concepts behind Vert.x, why we chose Vert.x, how we're using it and the challenges we faced. Topics include the anatomy of our projects, (micro)services architecture, deployment model and DevOps, scalability and the upgrade from Vert.x 2 to Vert.x 3.
Report
Share
Report
Share
1 of 30
Download to read offline
More Related Content
Building microservices with Vert.x - Bert Jan Schrijver - Codemotion Amsterdam 2016
3. - Introduction
- Why Vert.x?
- Basic demo
- Deep dive
- Advanced demo
- Microservices with Vert.x
- Vert.x in practice
Outline
4. - 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.
6. - 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
7. - We love open source
- Powerful module system
- Reactive characteristics
Why did we choose Vert.x?
13. - 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
14. - 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
15. - Never ever ever block the event loop
- Need to to blocking stuff? Use a worker
Vert.x’s golden rule
19. - 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
20. 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
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 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
24. - Very suitable for 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