Menu Icon Close
App Development

Going Across the Board: Refactoring from Monolithic to Microservices

Blog-Going Across the Board: Refactoring from Monolithic to Microservices Image
March 02, 2017
By abhijeet
Reading Time: 3 minutes

Where there is the necessary technical skill to move mountains, there is no need for the faith that moves mountains. ~Eric Hoffer

If you have little or no IT prowess, it will be difficult for you to understand how complex it can be to manage Daedalian enterprise systems. A delicate balancing act it is, one that requires precision, expertise and the ability to improvise spontaneously.

Unless you’ve been living under a rock, you’ve heard of how microservices can turn this scenario on its head, enabling a new, more agile world in which developers and operations teams work hand in hand to deliver small, loosely coupled bundles of software quickly and safely. Instead of a single monolithic system, functionality is carried out by a smaller set of services coordinating their operations.

How do you make it work? You’ve come to the right place. We’ll explain it all. While a one-size-fits-all approach to adopting microservices cannot exist, it is helpful to examine the base principles that have guided successful adoption efforts.

Microservices architecture, or simply microservices has grown in popularity in recent years. It has become the preferred way of creating applications, although you might not find much written or discussed about it on the internet.

So, let’s get started, without further ado!

But wait: What, exactly, is a microservices architecture?

There is no formal definition of microservices, but there are a few distinct characteristics that define it. ‘Microservices architecture’ is a method of developing applications, as a suite of independently deployable and modular services. Each service runs a unique process and communicates through a well-defined, lightweight mechanism, to serve a common business goal.

No, it’s not magic! But then, how do they communicate?

The communication between services, depends on the application requirement, but most developers prefer using HTTP/REST with JSON. Any kind of communication protocol can be chosen; but in most cases, ‘REST’ (Representational State Transfer) is used, is less complex compared to some of the other protocols.

First things first: Why did we switch to microservices architecture?

The opposite of microservices is the monolithic architectural style. Monolithic applications are always built as a single, autonomous unit. In case of an application, the server-side is a monolith that handles HTTP requests, executes logic and does CRUD (Create-Read-Update-Delete) operations on the database.

In case of monolithic architecture, each change cycle usually ends up being tied to another. A small modification made to the application-make, require building and deploying an entirely new version! Scaling is again an overhead, as you can’t scale specific functions, you ought to scale the complete application. And that’s where microservices architecture can help.

The million-dollar question: how is microservices different from SOA (Service Oriented Architecture)

Yes, SOA and Microservices bear several similarities. Some would say microservices is a more refined form of SOA, but some microservices lover would reject that altogether. But we think, that there are clear differences to justify microservices concept (a special form of SOA):

  1. Microservices use faster messaging mechanism as compared to SOA which uses ESB’s (Enterprise service bus), which can be a single point of failure.

  2. SOA tends to have an outsized relational database, while microservices mostly use NoSQL or micro-SQL databases, which can be connected to conventional databases, this can have its own pros and cons.

  3. In microservices, services can operate and be deployed independently of other services, unlike SOA. So, it is easier to deploy new versions of services frequently or scale a service independently.

While the list can extend beyond pages, we chose to bring to your attention the best industry standards and never-to-miss microservices architecture practices first:

  1. Each microservice should have a separate data source

  2. There should be a separate build for each microservice

  3. Servers should be stateless

  4. Containers should be a preferred option for deployment as one tool can deploy everything

  5. Single responsibility principle should be kept in mind while designing microservices

Who uses it?

Netflix, eBay, Amazon, the UK Government Digital Service,, Forward, Twitter, PayPal, Gilt, Bluemix, Soundcloud, The Guardian, and many other large-scale websites and applications have all evolved from monolithic to microservices architecture.

We hope that you enjoyed our brief and crisp take on microservices. In the next blog, we will discuss Netflix OSS. Meanwhile, to satiate your tech-hunger, visit our blog section and learn, leverage and be amazed by astonishing tech happenings, tech insights, and everything geek, you can visit Bluepi website.

If you have a query, or need an expert’s opinion on anything tech, say hello at

Saubhagya Banerji

Saubhagya Banerji works as a System Analyst at BluePi Consulting Pvt. Ltd. His areas of interest include Spring Cloud, Android, Strongloop, and AWS. When he is not working on advances in the tech field, he likes to play Tennis, enjoys spending time on his PS4 and doing leisure activities. For anything and everything geek, he is right here to help you get answers and accelerate your tech-quench.


Invest in better
solutions today

Contact Us