Prawns & Corns of Microservices

Microservices

Few months back one of my friend, also an Architect reached out to me. Generally, we connect to each other once in 15–20 days, discuss about technology, world and anything else which comes to our minds in that point in time.

However, this incidence was really different, we were talking over the phone and somehow, I sensed that he is bit distracted. So, I Asked him about his health and family he responded with 200 OK response. But, the moment I asked him about his work and I received a constant loop of Exceptions, all you can imagine :).

I understood, that something big is going on here so let’s send one request at a time, I asked, “What happen, is there something I can help with?”, after few minutes my friend understood that I am least of his problems if not a problem at all. He then opened up, “We have this new Project, where we have to migrate this really large monolithic application to microservices!”, I was like, “So what, microservices are a big deal for you?”, My friend, “No, it’s the team.”

In less and precise words without dialogues… He was struggling with his team, he was the only Architect and he has a team of few dozen developers of all ages with almost all available technologies (Go, RUST, C#, JAVA, PHP, Python, JavaScript, NodeJS). So, in order to understand his problem, I asked him to explain me his entire problem from beginning. He started talking and I grabbed a pen and paper so that I can take my points, (pen and paper sounded good to me as I was playing doctor here).

Once I heard and understood his entire problem I was able to figure out few things.

  1. His team is trying to migrate a large monolithic application to microservices.
  2. Since his team is formed from different technological background it was difficult to choose a technology.
  3. Again due to different technological background, his team was not able create an architecture on best practices. (Java C# guys are more design based, everything event-driven for NodeJS team, GoLang team want generalization and they were more about concurrency), problem was everyone was right in their own scope.
  4. Once again the team fought over which Database to use.

There were a lot more issues, but for this article, I believe these points are more than enough.

So, moving on, my friend who supposed to architect this application somehow found himself in the center of this technology and ideology warfare. Speaking from experience after every war lot of destruction happens but after a technology and ideology war in IT, one thing gets build, we then call it huge non-maintainable monolithic application. Since he was my friend, I thought to help him, otherwise what’s the use of being and having a friend, HUH.

So, I asked him to bear with me for a while so that I can provide my help. After all the agreements happened, I started my counter. I told my friend that you have started your project in completely wrong manner.

  1. Monolithic application can’t be migrated to microservices, at least not literally, (I am sensing some eyebrows going up! are they?),  you technically assess your monolithic application understand its domain, identify its logical subdomains or sub-subdomains. create bounded context around each subdomain, create context map that how these smaller subdomains are going to talk to each other, you may go little crazy and create a ubiquitous language around them, (Now, it may sound like DDD, but spare me, I am not talking about DDD). Technically, you are going to create multiple microservices which are bounded context and purpose-specific able to accomplish a very specific set of instructions. Then after you will create a workflow or structure in which these microservices will communicate with each other or get exposed over message contract on certain protocol. Eventually, you will end up creating a bigger application by joining multiple really smaller applications which will mimic your original monolithic application, but it is not a migration as your monolithic application will stay where it was originally. My point is, applications don’t migrate users of those application migrate from one platform to another.
  2. Your team is composed of different technical backgrounds, that should be least of your worries, in fact, it’s a blessing. The point is how you use them. I am a big supporter of polyglot microservices because it gives you a guaranty that you will never end up having monolithic application in future. (Now you can argue on this, but it has its merit). If by any chance your application ended up being monolithic from microservices then the entire practicing microservices is invalidated. Now, the question is how you control this team of different ideology and technology. Simple, every team is writing their own microservices in their preferred technology using their best practices, don’t control their code just control their contracts and orchestration of all the microservices. GO is good in concurrency, JAVA, .NET and PHP, Python are well-established technologies for any kind of application development, NODE JS gives better event-driven programming model. Unique features of these technologies will help in the process of decision making.

NOTE: This is my personal and firm belief, that as an Architect it is not important for me to focus on internal programming of a microservices, instead designing a workflow to connect multiple different microservices to build a scale-able system has importance of higher magnitude, plus if a microservices application which is a smaller part of bigger application scheme is not performing well or not written correctly then the cost of replacing/refactoring/rewriting is not huge. I have seen well-written code performing bad to worse in the time of stress, but it all boil downs to the design. Whenever I see an application performing bad for a long time then I know there is something wrong about the design. refactoring a bad code is much easier task and cost-effective in comparison to fix a bad design, sometimes the only resort is expensive rewrite.

  1. Database goes same as above point; every database has its own benefits and merits as long as each microservices have autonomous control over data of their bounded context and implementation design of microservices is not very centric to any specific database. Select database on its merit but design should abstract to database.

In the end, I gave my version of microservices definition.

Microservices are bounded context and purpose-specific applications for nuclear domain (Domain Which cannot be decomposed into other subdomains), runs in isolation with its own persistence, horizontally scale-able, technology neutral, polyglot by nature, don’t share data with other microservices but communicate through message over agreed protocol.

It’s been few months now and that microservices project is in its full thrust, I am happy that I was able to help my friend, but I am not saying that I am expert in microservices. No one can get a large microservices applications right in single stride. I just shared my experience

Based on my personal learning at the projects I have worked upon, applications I have designed and learning’s from discussion with my teams and friends that microservices are more about shift of mindset then shift in technologies. I can say that working on microservices in last few years have made me a better application/system designer.

Personal note: I write few articles, so I would like to know about opinion of whoever is reading this. The least I am expecting is to learn some more things, so in my next microservices adventures I will be better than previous adventures, and if you apply any of my ideas or if you agree with them then also do let me know.

Till I write next article….

Loading Likes...
2 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published.