Moving into new microservices world

Question: What would new world look like?

First of all, let’s see my old world

My old world is one big monolith app with one big db. No one enjoy working with this messy world.

I know that microservices will bring the benefits as I’ve mentioned above. But which designs will bring more benefits to me? Why not take a look at several designs of my new world?

New world V.1

Still one big monolith app but refactored. Functionalities/Context have been separated into modules. Unit tests still take couple hours to finish.

New world V.2

As we are developers, We’d like to use advantage of characteristic of programming languages. So that, why not we extract our monolith into new 3 micro services? One uses power of Ruby on Rails. One uses NodeJS WebSocket and the last one uses Scala for handling concurrency. Every microservices share same db.

New world V.3

From business point of view, let’s extract the monolith app into 3 micro services by context of business. Each service has own context and also don’t overlap with others context. They might speak in different language.

You can notice that only db is shared among 3 services :p

New world V.4

I extract microservices by context of business. In additional, also separate from one original db into 3 dbs. Each db stores only relevant information for their own context. The db schemas might be different from original.

Which version of New World I prefer?

Version 1:

This is still a monolith app. But one good thing is if I could refactor like this successfully. I could extract this monolith into Version 3 or even Version 4 with less effort. Moreover, it proofs that Version 3 or Version 4 are doable.

Version 2:

When we focus too much on the implementation, we will lose focus on business. In this version, we don’t have clear mind about the definition of services except implementation. In additional, to understand functionalities of the services we have to look into implementation. The more of 3 microservices grow up, More likely that nightmare will come to me again.

However, we can do extract microservices by programming language. But that particular microservice must has well-defined context or functionality.

Version 3:

Well-defined context of microservices make my services easy to understand. Anyway shared db among them might not be such a good idea. It means we’ve pushed business knowledge into the db level. So, I can’t understand which tables, fields are belonging to which services if I don’t understand business context. And also each of my service understand business in their own different way from others. It would be real mess to put things in the same db. ( Note that: No concern about performance tuning at this point )

Version 4:

This is ideal new world which I really prefer. The microservices encapsulate their own db also has clear context!

Even though, I’ve to add more dbs and they also cost maintain effort. However, I believe that comparing to price that I have to pay for maintaining uncleared microservices in the future. It is totally worth!

Moving to Version 4

In order to archive this, it might take from couple of months to couple of years. I personally prefer to move one-by-one service rather than all services at once. The benefit is we could get feedback more quickly and frequently.

Team capabilities are also important factors to archive successful microservices.

1. BA — Understand the business. BA could identify clear context between each microservices
2. Developers — More services will cost us more maintenance/development effort. We have to keep in mind about balancing number of services and number of developers.
3. DevOps — We need separated and automated deployments, monitoring for these microservices.

Last words…

Microservices are very useful. However, in the same time it can be evil. My current project, we have 10+ microservices maintaining. So far (as I know), we still have good dream every night. Cheers!