Our journey to microservices

Recently our development team attempted migrating our software architecture to microservices architecture. Despite being the most popular pattern mentioned everywhere, our journey came to the end with a surprising result, that was the team eventually decided to cancel the migration. After one developer from our team wrote a post to share our experience, I also want to share some of my personal opinions about microservices, a term, architecture, or pattern that was so controversial in the team in the last couple months.

Engaging microservices

The first time the term attracted me was when I saw a post about doing microservices on top of Azure Service Fabric. I absolutely loved the idea of splitting a monolith service into several stateless and stateful services, each of which could be deployed and maintained separately. Shortly after Azure had its Kubernetes and docker hub, I was also amazed how easy it was to build a containerized ASP.Net Core application and deploy it as a microservice. So I imagined that one day, at work, I could have a chance to practically bring the benefits provided by microservices to the business and stakeholders. 

Turns out I might be dreaming? 

Though I have had a good dream, I still live in reality. I soon realized that not every development team needs microservices, at least here in Christchurch. Doing microservices certainly has its benefits, but it also has some major side affects that will certainly affect team's productivity. Unlike doing a microservice example, a real world microservices environment requires a decent platform where general concerns have all been resolved prior to building any service. 

A typical example of those concerns is communication. Doing method calls in local memory is way faster than calling a remote service over network, so how your team could balance between the incurred overhead costs and the benefits will become a must-answer question before you start doing any services that might depend on others. 

Creating and maintaining a microservice environment is also a nightmare to small teams. Splitting a monolith is also like splitting a single point of failure to multiple, but in bad. It certainly made your system more reliable, but you are going to need resources allocated from your team to keep eyes on all services that might fail at anytime. So have said that, you either need to invest a decent monitoring system, or hire more people. 

So no microservices is better?

Microservices certainly has its benefits, but you might want to apply it accordingly.

For example, if you always want to leverage different technology stacks, or your system has a fairly long history which leads your system to have some very legacy services,  you could turn services in your system into microservices, and in total, you will have a SOA architecture. You could then continue apply patterns to retire and replace your legacy systems with new systems built using latest technologies.

Another example would be if you have multiple teams doing components for well isolated bounded contexts, then you could consider doing microservices. So each team could be in charge of one or multiple bounded contexts, avoiding teams affecting teams. And artifacts from each team could be deployed and maintained separately.

However, if you have no dedicated feature teams, or your team is too small to afford the overhead costs. Doing microservices is way over complicated and like killing an ant with a 400 tons of hammer . In the meantime, if you do microservices for componentizing your system, you might be seeking something else, probably like interface isolation rather than microservices.