What is a Service

Essentially, a service is some API that exposes methods through HTTP.

What a service must know

A service must know how to handle his own execution, and it must know how to handle its own failures.

• Given that we have a consul instance running:

  • When a service is started, Then it must know how to find a consul instance and register himself on that instance.

  • When a service is shutdown, for any reasons, Then it must know how to unregister himself from the consul instance.

  • When a service is shutdown, unless stopped, Then it must know that he has to restart in order to keep up and running.

How can I implement a service

Essentially, a service is a project that has a docker-compose.yml file specifying the service, and probably some others as his dependencies for running.

You can use this project as a boilerplate for an actual implementation of a service: armand1m/microservice-barebone

It cames configured to run a language-agnostic service, it only need to specify a Dockerfile inside the ./service folder that must be configured to run your service as entrypoint.

It runs an instance of ebay/fabio as a Gateway, and Consul as a Service Discovery mechanism.

Independent of your language choice, your API must be able to find this consul instance and register himself, as well as unregister himself and terminate when needed.

Good practices

Use the core services project.

The project must git submodule add the armand1m/core-services project in order to reproduce the same environment in the local machine of the developer while developing.

You can git submodule add other services to help development too.

Make sure your Dockerfile layers are cacheable

Every service has its own Docker image, so it good when the Dockerfile's are designed to cache as much as possible of its own layers, so it can rebuild images faster and keep a fast cycle of development and deployment.

Keep always 1 process per service

Each service must always run only one process inside a container.

Resiliency

If a service process throws an error to the STDOUT, the container must restart. After some tries, if the service can't stop throwing errors and operate normally, the environment must understand that the service is down and it's better wait for manual repair, and stop trying to restart the container.

Keep it stateless

Stateless services are far more scalable than stateful services. Try to not persist any state in your service during runtime and you'll scale easily.

Try to follow Twelve Factor

Follow the 12factor.net application manifesto. Create your service with scalability and flexibility in mind.

Tips

Create your service from the microservice-barebone project

You can clone the project armand1m/microservice-barebone, re initialize the repository and use it to start developing your service.

Use the compose utils project, if you don't know docker-compose.

You can use the armand1m/microservice-compose-utils as utility for developing your microservice independently as well.

(it is the ./commands repository in almost every service that I create for this environment)