Is the monolithic application dead?

Microservices is another buzzword floating around the internet and the marketing engines of the world's leading IT companies. 'Microservices' is the latest jargon du jour, joining the likes of 'devops' and 'cloud' in the IT world. Everyone is clamouring to be associated with it, or thinking about why they're not part of the new revolution in IT. This series will (hopefully!) answer what Microservices are, why they're important and what they mean for you.

What are Microservices?

In short, Microservices are a software architecture style that focuses on developing a single application using a collection of small services. Each 'small service' is run independently in it's own process and communicates with other 'small services' though a lightweight communication medium that focuses on language-independent specifications. Each 'microservice' is run in a singular purpose and is deployed, managed and maintained by a central automation tool that effectively orchestrates all other microservices to provide a working single application.

Where did we come from? And where are we going?

To understand microservices architecture in the real world, we need to look what they are an alternative to. The monolithic style is the traditional way of building applications. As the name applies, it is a single mammoth application with several sub routines running within one code base to solve a business problem. More often than not, an enterprise application is built using not one but three main parts:

  • 'The client' - Consisting of an application that runs on the users side. This can be through a browser, mobile phone app or desktop app.
  • 'The database' - Where information from the client interaction is stored in a common data format. Usually this is in a relational database using SQL, but increasingly people are choosing to use alternatives that have no SQL.
  • 'The server' - The server side application will handle the core logic, understand the work flow and report any answers back to the client.

In this scenario, the server side application is the core of what you are building. This is the brains of the solution that will be executing the logic and providing the information requested by the client. The key factor here then is that it is all running under a single process. Crucially, any incremental changes involve building and deploying a new version of the whole server side application. Furthermore, any misbehaving and resource hungry sub-routine is a burden on the whole application.

The Cloud and scaling your application

A monolithic server application provides a single process through which to handle the logic that has been coded into it, allowing you to divide the application up into sub-routines. Scaling the monolith application to meet demand can also be achieved by running multiple instances of the application sitting behind a load-balancer.

The success of monolithic architecture is undeniable, as a majority of applications we use today leverage the monolith design principles. Changes in compute principles i.e. the shift to the cloud (no, it's not just a buzzword!) and utility computing has made us rethink the way we design and deploy applications. The principles of modular design in monolithic architecture provide a degree of fine grain control in deploying only the specific parts of an application that have changed. However, changes are interlinked and more often than not, the whole application needs to be rebuilt and redeployed. Scaling to meet the new generation of demand from multiple devices requires scaling the entire application rather than the actual components that require increased scalability. Going back to the concept of Cloud deployment and the 'utility' aspect of the new way of compute i.e. pay for what you use; we are now focusing on efficiency of resource applied to what needs it the most, and when.

Microservices architecture allows you to build applications through a collection of services that are deployed independently and scaled. What's more, as each service is a process managed by a central management 'engine' speaking in a language independent API, you are free to use the most efficient and relevant programming language for each service. This gives you greater freedom compared to making a programming language choice from the onset (and sticking to it!).

So is this just a new word for Service Oriented Architecture (SOA) ?

Good question! SOA was one of the first architectures that tackled breaking up the monolith into modules that have different domain ownerships. The SOA approach helped the developers immensely. Having cross domain involvement in building solutions for business problems gave better insight into the end product. Couple that cross domain involvement with the popularity of agile development and you're producing better solutions in a shorter time. There has been a tremendous amount of debate on whether Microservices is simply SOA evolved. The SOA purist will draw some parallels. However, microservices are more granular and encourage breaking down the monolithic application into services that have single responsibilities.

Part two of our series (published soon!) will focus on why 'Now is the perfect time for microservices'


About Quru

Quru is a market leader in the technical development, deployment and support of Linux and open source solutions that help organisations to reduce costs and increase operational agility and capability. We have also developed multiple award-winning software solutions ranging from mobile phone apps to global enterprise systems. Quru is based in Somerset House on the banks of the Thames, right in the centre of London. More...

Quru :: inspired open source solutions