Friday, August 4, 2017

Microservice-driven Software Architectures

Over the last few years, software development techniques have evolved to match the ever-changing present day requirements. These emerging technological trends present a few approaches to choose from when building new software solutions. In this article, we consider Microservice driven software architecture and Monolithic architecture. Which is the best choice for the system you are working on?

Monolithic Architecture

Monolithic software architectures have been around since the invention of computers. They implement a design that tends to bundle all the functionalities needed to achieve a task into one single application. This is the simplest form of design because it does not involve many modular end points fitting together.
For small applications, Monolithic architecture works quite well with a minimum of complexity. The codebase is also quite small and centralized hence easy to deploy an application. However, whenever there's a need to scale up, a problem arises. This is because the modules are highly dependent on each other and refactoring a code in a single part of the monolith will impact the whole system.

Many enterprise applications are built in three parts: the database holding the records, a server-side application, and client-side application. In this case, the server-side application reads and updates the database, and then populates the views in the client-side application. Making changes to such a system will involve changing the server-side application and changing the views in the client-side application. This is a single application – a good example of a monolith. Over time, as the application grows, it becomes increasingly hard to make changes. Monolithic Architecture is suitable when building small applications with no foreseeable need to scale up.


Microservice Architecture

Microservice-driven software architectural design has been a major topic in software conferences in the recent years. As Martin Fowler - a renowned software developer and speaker puts it: 
The design has been there for a while only that it didn't have a name to identify it. 
While there’s no precise definition of Microservice architecture, we can describe it as a way of designing software applications as modules of independent services that can function on their own. As aptly named, Microservice architecture states that a service should be minimal, else be split into multiple services. 

Now, while Monolithic architecture is easy to design and deploy, Microservice architecture brings in a lot of complexities just from the design level. There are many small actors involved to make a solution work. All these actors are independent of each other and only communicate through simple interfaces. Despite these complexities in setup, Microservice architecture has many advantages as we will find out soon enough. 

Microservice architecture brings together some of the thoughts of Service Oriented Architecture (SOA), only that the services are much smaller. Microservice architecture is simply a better implementation of SOA. The high abstraction between services makes this the best option for designing large and scalable applications. The implementation of the services is completely hidden from the interface. This means, the services can be used in multiple contexts or other business processes. Additionally, developers can modify the services which lie behind interfaces without any downstream impact. Big tech companies such as Netflix, Twitter, PayPal, Amazon, Soundcloud and many other large-scale websites have moved from monolithic to microservice architecture. 

An article published by Martin Fowler and James Lewis introduces microservice architectural style as:

"An approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies."


So, when it comes to choosing an architectural design for your application, there are tradeoffs to consider. Here are the benefits and drawbacks of Microservice driven software architectures over monolithic software architectures.



Benefits

Reliability: 
Since services in a microservice architecture are highly independent, a fault in a microservice affects it alone while other services continue to work. While in a monolithic architecture, a fault in one part of the system is likely to bring down the whole monolith.

Availability: 
In a microservice architecture, making improvements to the codebase of a service requires little downtime only for consumers that depend on that particular service. In a monolithic setup, it will require a complete shutdown of the whole system and subsequent slower restart.

Scalability: 
Since services are independent, with each one having its own codebase, microservices can be scaled independently. Microservices are thus perfect for large applications with a large a growing user base.

Design autonomy: 
The development team is free to employ different technologies and frameworks they are well familiar with to implement each microservice. It’s also easy to change each microservice independently. Whereas in a monolithic architecture, since it’s a single application setup, frameworks used must be able to match.

Management: 
The application design and development effort is divided across teams with each team managing and documenting its service. It’s easier to manage smaller teams than one big team working on one large monolithic driven software.


Drawbacks

Complexity: 
In a microservice architecture, there are many services which need to communicate. The operation effort increases because more runtime components have to fit in place for the system to function properly. Whereas in a monolithic setup, it’s only a single application hence complexities of integrating modules are avoided.

Memory use: 
Codebases are often replicated in each microservice bundle and the overall memory footprint increases. In a monolithic setup, there’s no replication of services hence a lower memory footprint. 

Latency: 
Microservices usually communicate with each other through Web API’s (for example REST or SOAP). This introduces additional network latency in comparison to monolithic applications. Depending how distributed the microservices are being deployed, this can have a noticeable effect on the overall performance.


Conclusion

Time to draw the line. Do you consider scalability? Is a smaller memory footprint important to you? How about improving the codebase in future? These two software design architectures have their pros and cons. You need to understand functional and non-functional requirements of the application in question to make an informed decision. 

Microservice architecture is certainly an interesting option. It allows for flexibility and scalability which are major requirements of modern applications. 


Sources