Micro-servicing your application

How Docker will change the way you test and deploy your applications.

If you never heard about docker, you probably missed a lot of other things but OK, we will try to give you a short introduction.

In the old times, most of the applications were a single executable. Later we moved to multiple executables talking together. As it became harder to deploy the applications on multiple servers we started to virtualise the servers (with tools like VMWare). Docker is the next step, it isolates each application on its own little mini virtual machine. (It is not really a virtual machine of course)

An application lives in a container that is hosted on a docker host. A container can be a simple hello world written with shell script or a full database system like PostgresQL.

Each container is isolated from the outside world and communicates mainly by tcp ports that can be mapped with the host or used by other containers to communicate.

Benefits from the system are:

  • The developer is responsible of the deployment of the application in the container. This means that if it is working on his local docker, it will work on all the other hosts.
  • Multiple versions of frameworks can exist on the same host because every container can have its own version.
  • The UAT testings do no longer required complex deployments, you simply move your containers from the test environment to the acceptance one.
  • This logic is highly compatible with the micro services. It pushes the software architect to clearly define the purpose of each containers and how it is possible to interact with them.
  • It is possible to increase the application performance by adding new hosts or deploying on a more powerful server.


A tomcat application that uses a PostgreSQL database.


The tomcat container uses a datasource that uses the PostgreSQL container name because it is possible to link containers together on the docker private network. Only linked containers can access postgres via the port 5432 because it is not linked with the host.

On the other hand, tomcat runs on port 8080 in its container, but this time we decided to link it with the host machine on another port (In this case 80)

So at the end, the only port open for the final client is port 80. A page request will happen like follows:

  • The host will direct the request to the port 80 to the tomcat container.
  • The tomcat container will connect to the database using the docker specific network.
  • The tomcat generates its answer on port 8080.
  • The client receives it on port 80.