Introducing microservices

November 10, 2015

Much advancement has been done in the field of software architecture in the past year. Due to a number of these advancements we have seen a rise in design patterns that enable developers to design and implement complex systems with greater ease, often using solutions and patterns already perfected by others in the field. One such pattern that has surfaced very recently, and which is being widely adopted across the industry, is the move from monolithic applications to microservices architecture.

 

 The past: Monolithic applications

In the development of software architecture there is often the requirement for a program to be able to function on its own, completing all the required tasks of a system within one element.

Historically this type of build has relied on the use of monolithic applications. A monolithic application is a self-contained application that is usually independent from other computing applications. The design philosophy behind this type of architecture is that the application should be responsible for every step needed to complete a particular function.

To look at an example of a monolithic application let’s delve into a typical architecture of a web application – such as an online storefront. We might require our virtual store to be able to manage a list of products online, maintain inventory data and sales data, as well as maintaining a database of customers and their related information. A monolithic application would include all these features and manage all the complexities in one code base.

 

 

Problems with the monolithic architecture

One of the major problems with monolithic architectures is scalability. Continuing with our virtual store example above, if the developers needed to upgrade or add features to the inventory system for our store then they would need to make changes to the entire code-base, regress test the entire application and hope that a bug does not occur in the new code as it could have the potential to bring down the entire system.

Another big issue with monolithic architecture is the restrictions on the technology stack the monolith is written in. Often the developers would have to stick to specific versions of the different platforms they are using which makes potential future developments and upgrades extremely difficult. Dividing the developers into teams to focus on only a certain aspect of the application is also often hard to do.

Before we to get an actual definition of what a microservice is, it would be worthwhile to explain what the different monolithic architecture scaling methods are:

 

X-axis scaling

This approach scales a monolithic application by cloning it. A typical example of this is to have multiple instances of the same application running at one time, such as in a load balanced application.

 

Y-axis scaling

Unlike x-axis scaling, this type of scaling breaks out functional components of the monolith, and creates a separate service for each of them. This technique is used when scaling a monolith into different self-contained services. This type of approach is also often used when developing a microservices architecture.

 

 

Microservices

A microservice is a self-contained service derived from a monolithic application to perform a specific set of functions. Functionality and data are made available to all clients via a standard application programming interface (API) e.g. a restful API.

Using our storefront as an example, we might scale out the inventory system into a microservice, the customer data system into a Customer Relationship Management System (CRM) and the sales data into its own service. This change would result in the monolithic application being more streamlined, providing access to all the data required from the various services through the use of standard APIs.

 

Advantages of microservices

Making use of microservices architecture means that each microservice can be written in a technology that is better suited for that purpose and that adding new functionality to one of the microservices does not require a redeployment of the entire code base. Developers can also easily be split into teams, each team focusing on a different aspect of the system.

Disadvantages of microservices

Microservices are not a silver bullet for bad software design and sound software design principles still need to remain a development team’s primary focus. As this technology is still fairly new, developers may have to learn a brand new technology stack to implement an efficient microservices back-end which could become really cumbersome, if the technology stack is brand new, or the initial learning curve is high.

Microservices are definitely not for everybody. Caution and pragmatism needs to be exercised when deciding which facets of the monolith will be abstracted out to their own service.