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?