From The CEO's Desk: To Microservice or Not To Microservice Is Not The Question

Microservices is 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 now, but do people understand the term fairly, 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, and 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, finalising on the architecture and the data flow diagrams, then developing the application with actual work on the presentation layer, application layer, integration layer, and databases. Once the application is created, it undergoes documentation, testing, bug fixing, framework and results into finalised software product or application. As the application grows, the code and the dev team grows and soon multiple teams 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 which involves deploying a copy of the application on various servers, which utilize the same amount of underlying resources. But with this monolithic approach it becomes difficult to add resources or modify any code 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 solution such as Docker.

So, why go for microservices when we can go for SOA or monolithic architecture with some modifications and tuning? It is easy to update, replace, remove, augment with microservices. It eliminates interdependencies between teams allowing developers to independently develop and deploy services. It improves the start-up and shutdown time, gives freedom to choose the technology as per the functional needs and provides fault isolation as most application remain unaffected by 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 was in its 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 which is flexible, meaning, it should be easily scalable just like in cloud computing but not necessarily cloud computing and which basically 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 must to have a system which will monitor the dev and test environments and make sure everything is going right. It is important to understand that monitoring a microservices is going to be much more complex than monitoring monolith. It will be just like monitoring lot of small monoliths running independently. You can take help of something like Prometheus and AIOps.

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

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

Factors to be considered:

Deployment and development complexity – Microservices architecture is all about breaking up big operations in to smaller one to reduce system complexity. If the deployment using microservices is going to result in more complex set up then it is going to defeat the whole purpose of it. Better make some changes in existing monolith and make it serve the purpose.

Non-uniformity – One of the advantages of microservices is, you can use different technology stack for a different component. This results in non-uniform application design and architecture, which can increase the maintenance cost in 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 better scalability, cleaner coding, faster and easier deployments.

Is Microservices supposed to replace SOA?

The answer is not so straightforward as microservices architecture is a 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 has its benefits and shortcomings like every other thing. Even though the benefits are more than 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, analyse your existing system and if you fulfil the prerequisites for microservices then only go for it. Opcito’s microservices expertise can help an organization in analysing the feasibility and make you microservices ready. So, to microservice or not to microservice is not the question… But are you ready to microservice or not is the question.