Question #1: What is a microservice architecture? What are we trying to achieve here?

Hehe, basically this are two questions. Here I just want to answer the first one.

I think there is no real and agreed-on definition of a microservice architecture. What I think can be agreed on by a lot of people are the following characteristics of a microservices:

Being small and perform a single function

Being easy to replace

Being isolated (e.g. not sharing databases, often running in containers)

Communicating over the network

Not necessarily being in the same language ( → use the right tool for the job)

Should be resilient and scalable, keeping failure and faults in mind

Problems with microservices

Now that we have a rough idea what a microservices are, we could ask ourselves

“Why on earth anybody wants to burden themselves with deploying that many services instead of just one?”

Of course, a microservice architecture has its own problems and burdens like being a lot more complex than monoliths or having to debug errors across services. But I personally think these drawbacks are worth it if you are a company and have a lot of developers working on the same project.

With the introduction of microservices you gain a lot of potential for the developers and the whole architecture of your application. In a microservice architecture, a single failure of a service does not mean that the whole application is down — implemented in a good way the whole system may be very unaffected by one single service.

Another great opportunity is more about the spirit of a developer team. Microservices can enable a lot of agility in a development team. Each team can deploy their service independent of each other. No long release cycles anymore — only it has to be ensured that the APIs via which the services are communicating don’t change in between releases or at least stay compatible.

Main benefits

The main benefit as a developer is for me that the services are by design very small, have only one function and are isolated. With a good test suite setup, you can be pretty sure that you don’t introduce that many side-effects as in a big monolith. Also when starting to work on an existing microservice it is much easier to get a grasp of what it is doing.