Microservices

More and more organizations are interested in Microservices and as we have seen with other techniques this one also has a multitude of definitions. The Wikipedia page of Microservices can provide us a little introduction. The writing of James Lewis and Martin Fowler on Microservices has the usual deep explanation of the Microservices architecture.

Smartbear on Microservices is another great explanation.

Let me have my short explanation here.

Microservices is another step in the direction of more modularity.

1. When people start to write program they tend to write one file with lots of lines of code. Without any functions.
2. Then they learn about functions and start to refactor the code to use functions instead of copy-pasting the same code.
3. Then they learn about modules or libraries (or classes if they use an OO language) and spread the code into separate libraries. At this point they still have one application with lots of responsibilities and lots of features.
4. Then they can move to Microservices where they move some of the responsibilities to stand-alone applications. These applications then communicate with each other.

Let's try it shorter:

1. statements in a single file.
2. functions in a single file.
3. modules (libraries, classes)
4. Microservices

As you move up on that 4-step ladder the aim is to make the code more and more modular. With that come all kind of opportunities and challenges. One thing is clear. If you have your code in several files (in several modules) where each file (module) is responsible for one area of the application, it is much easier to distribute the work among several people than if you have everything in one gigantic file.

The same is true for the switch from a monolith application that has several modules to a Microservice-based architecture. In the latter it is easier for independent teams to work without interference with the work of other teams responsible for other areas of the application.

So the big selling point of Microservices is that you will be able to move forward in smaller teams independent from each other.

If that sound more agile then don't be surprised. Agile development methodologies and Microservices architecture can work together well.

Some people when they learn about the advantages of Microservices will want to build everything as Microservices. If splitting up a monolithic application into Microservices is good then they will want to move every module (or class) to its own service. This (dubbed the nanoservices anti-pattern) is of course as bad a moving every statement in your code into its own function or moving every function in its own module (or class).

Microservices is not a silver bullet. You still have to think hard which parts of you application you can put in a stand-alone service and where does it not make much sense.

In any case, the articles above provide a much more nuanced explanation what is considered a Microservice-base architecture. They also provide a lot more ideas on what to put in specific (micro) services.

If you are more into videos, here is on of Martin Fowler on Microservices.