To Microservice or Not To Microservice Is Not The Question

Microservices are a way of breaking large software projects into loosely coupled modules, which communicate with each other through simple protocols. Microservices is a fairly familiar term, but do people understand the term fairly? It can be a fair question. I see a lot of companies approaching Opcito for consultation related to microservices architecture, and I like all the buzz around microservices. But I see junctures when an organization simply wants to go for microservices from existing monolithic or SOA architecture which is performing well, just because the Ubers and the Facebooks of the world are switching to microservices. Choosing the right architecture is the most important step for any software product or application development, so understanding one of the leading architectural platforms is more important than before.

Why Microservices when we have SOAs and monolithic running millions of applications perfectly fine?

Any application development goes through conceptualization, finalizing the architecture and the data flow diagrams, then developing the application with actual work on the presentation, application, integration, and databases. Once the application is created, it undergoes documentation, testing, bug fixing, framework, and results into finalized software product or application. As the application grows, the code and the dev team grow, and multiple teams soon start working on the same code. Without proper communication, coordination, and collaboration, irrespective of the company size, scaling up becomes a necessity. Horizontal scaling can be a solution that involves deploying a copy of the application on various servers which utilize the same amount of underlying resources. But with this monolithic approach, adding resources or modifying any code becomes difficult, and one failure can affect the entire development operation. The easiest way out could be microservices, where you can split your development operations into several small loosely coupled projects, which can communicate with each other without affecting and utilizing resources from other microservices. These microservices-based applications can be easily deployed inside container solutions such as Docker.

So, why go for microservices when we can go for SOA or monolithic architecture with some modifications and tuning? Updating, replacing, removing, and augmenting with microservices is easy. It eliminates interdependencies between teams allowing developers to develop and deploy services independently. It improves the start-up and shutdown time, gives freedom to choose the technology per the functional needs, and provides fault isolation as most applications remain unaffected by the single-point failure. The biggest advantage is high scalability, as the services with more demands can be deployed on multiple servers to enhance performance.

I read a very interesting article on MicroservicePrerequisites from Martin Fowler when microservices were in their growth stage. It talks about baseline competencies you should consider before using the microservice style of architecture.

Prerequisites:

Rapid Provisioning – You should have an infrastructure that is flexible, meaning it should be easily scalable, just like in cloud computing but not necessarily cloud computing, which means you will need a lot of automation. Your Ops team should be capable enough to deliver automation of a level where you can have microservices running on your own infrastructure with automatic relocation on the move.

Basic Monitoring – When you are going to have loosely coupled services running in a production environment, it is a must to have a system that will monitor the dev and test environments and make sure everything is going right. It is important to understand that monitoring microservices will be much more complex than monitoring a monolith. It will be just like monitoring a lot of small monoliths running independently. You can take the help of something like Prometheus and AIOps.

Rapid Application Deployment – With many services running in production and test environments, you should be able to deploy them quickly. You can use various platforms enabling continuous integration and deployment, including container ecosystems, to name one.

Even if you fulfill all the prerequisite criteria doesn’t necessarily mean you are ready or need to go for microservices. There are a few other factors that need to be considered.

Factors to be considered:

Deployment and development complexity – Microservices architecture is about breaking big operations into smaller ones to reduce system complexity. If the deployment using microservices results in a more complex setup, it will defeat its whole purpose. Better make some changes in the existing monolith and make it serve the purpose.

Non-uniformity – One of the advantages of microservices is that you can use different technology stacks for different components. This results in non-uniform application design and architecture, which can increase the maintenance cost in the long run.

Communication overhead, complexity, and reliability – Increased number of services communicating with each other means increased communication overhead and complexity. When there are multiple databases and control centers communicating continuously, you require reliable and fast network connections.
Other things which should be taken care of include security and access tokens, UI patterns, Observability with the help of different trackers, data management, external API and deployment patterns, network security, DevOps complexity, etc.

Should you go for Microservices?

Definitely, YES, provided you are ready for it. If you are well acquainted with the dependencies and boundaries of your system, microservices can provide you with better scalability, cleaner coding, and faster and easier deployments.

Are Microservices supposed to replace SOA?

The answer is not straightforward, as microservices architecture is part of SOA. So, we can’t answer this question with simple yes or no. They can go hand in hand, considering each has its own benefits.

So, to conclude, microservices obviously have their benefits and shortcomings, like everything else. Even though the benefits outweigh the shortcomings, don’t do it just because you want to go with the flow. The bottom line is, if you are facing some difficulty with monolithic architecture or SOA and are planning to go for microservices, analyze your existing system and if you fulfill the prerequisites for microservices, then only go for it. Opcito’s microservices expertise can help an organization analyze the feasibility and prepare its microservices. So, to microservice or not to microservice is not the question… But are you ready to microservice or not is the question.