Vert.x 3 and Microservices

Question

Microservices are gaining traction as an software architecture style that will better support continuous delivery, provide a model for rapid deployment and separation of concerns.

Vert.x 3 and Vert.x-Apex provide an interesting model for building a microservices. As one of the examples shows, a simple verticle can expose an HTTP service, so a REST service is available. The verticle binds its own tcp port.

When scaling up to multiple micro-services to support a full application you end up with a number of choices. Any thoughts on what style could eventually support continuous delivery, and minimizing downtime on upgrades?

Options

1. Run multiple verticles could be a solution, all containing there own routing, so http handling is contained in the verticle. A request/response can be handled completely by the verticle. This could mean that every verticle runs on it's own tcp port.
2. Using a router you can expose all paths on a single port, and handle them accordingly. Data will be handled by the verticle that contains the router, possible passing it on to other verticles. This then starts to look like a more monolithic approach.
3. Run separate instances of vert.x containing the service (possible cluster them). This could make it easier use continuous delivery, because the whole thing is self-contained.
4. Other possible options?

Deployment

On the deployment side rapid deployment of new services would be desirable, without bringing the whole application down.

• Option 3. could provide a way for this, but can also cause overhead, especially when there is a DB verticle running in every verticle.
• Option 1. could be easier, but what about reloading the new and updated verticles.

Separate micro-services offer an interesting way of development, but offers some challenges in orchestration and deployment.

Any thoughts?

Answer 1

Let's start with terminology.

• A verticle is a Java class that usually extends AbstractVerticle and implements a start(..) method. A verticle can expose one or more HTTP endpoints and expore one or more eventbus endpoints.
• A verticle runs inside a Vert.x application (previously called a 'module'). An application can contain one or more verticles. I usually keep it 1:1 to keep things small and simple.
• A Vert.x application runs inside a Vert.x instance. You can run multiple instances of an application to increase parallelization.
• A Vert.x instance runs inside a Vert.x container. A container is a running process with one or more instances of an application.
• A Vert.x container runs inside a JVM.

When building a microservices-style application with Vert.x, you typically want small independent logical units of work, call them services. Such a service should ideally run in its own process, be self-contained and indepedently upgradeable. Mapping it to the terminology above: build the service as a Vert.x application containing a single Verticle with the service logic.

Vert.x applications communicate with each other using the distributed eventbus, built with Hazelcast. This means that multiple JVM's running on the same server, or even on multiple servers, can communicate with each other over the Vert.x eventbus.

A web application built with Vert.x usually consists of one or more Vert.x applications exposing REST endpoints communicating over the eventbus with one or more Vert.x applications exposing (internal) eventbus endpoints.

To answer your question: option 3 is the most common in Vert.x setups, and stays the closest to a microservices architecture. You can choose between 2 options there: you either run 1 application with a REST endpoint that handles all HTTP calls and delegates request processing over the eventbus to other applications, or you give each service (or at least, each service providing functionality for end users) its own REST endpoint. The latter is a bit more complex to setup since there are multiple HTTP endpoints to connect to from the frontend, but it's more scalable and has less single points of failure.