Why And When To Choose Microservices Over Monolithic Application Architecture

Understand the pros and cons of monolithic and microservices architectures and when they should be used – Why microservices development is popular.

Business processes are largely dependent upon market-centric requirements. Consumer needs and buying-behavior evolve over time, and as they do, businesses need to change their product or services model to fulfil the changing consumer demands. In case of software, people had fewer and simpler needs in the past so it was easy to develop specialized software to fulfill consumer-centric demands.

However, with time, as technologies advanced, businesses started using them to improve the buying experience and create an upper edge in the market for their products by offering “something more” than what their competitors did. This, in turn, urged the competitors to follow suit by employing even more advanced forms of technologies to regain their competitive hold in the market.

The “dominoes” effect, thus produced, disrupted the manner in which how software was developed and services were made available to end users. The traditional method of building monolithic applications gradually started phasing out, giving way to microservice architectures.

What is a microservice?

Rather than building a single, huge application to fulfill all requirements, the entire block of requirements is split up into several sets of smaller, interconnected applications having their own architectures, business logic and databases. Most microservices now employ REST, or REpresentational State Transfer concept in which the client as well as the server are implemented independently of each other – The code on the client-side can be dynamically changed at any time without affecting server operations, and vice versa the code on server side can be updated or changed without affecting how clients work or function.

As long as both the client and the server know about the format of data sent between them, they can be kept modular and separate. The major benefit of separating the client-side from the server is that user interfaces and validation logic can be changed as and when required without affecting server operations. It helps to improve scalability and allows both the client and the server to evolve independently.

The microservices development model significantly affects the relationship between applications and databases since each service has its own database schema. Databases belonging to individual services are not shared, and this can create a duplication of commonly used data.

Some mobiles, desktops and web apps exposed to APIs don’t have direct access to back-end services, but instead communicate through API Gateways which are responsible for tasks like access control, caching, load balancing, API metering, and monitoring.

Benefits of Microservices Architecture

• Microservices platform helps to resolve complexity issues by decomposing application into individual sets of manageable services which are quicker to develop, and easier to understand as well as maintain.
• It helps each business logic or service to be developed independently by a team focused upon developing that particular service.
• Microservices development platforms such as Amazon microservices reduces the hassles of mastering new technologies since developers are free to choose whatever technology they’re comfortable with for developing a particular service. They are not bound to choices made at the time of project inception.
• Continuous deployment activities can be practiced for complex applications.
• It enables each service to be scaled independently.

Drawbacks of Microservices Architecture

• Microservice architecture adds complexity to the project since microservice applications form the part of a distributed system. You have to implement an inter-process communication mechanism based on either messaging or RPC. Moreover, you’re required to write special code to handle partial failures and account for issues pertaining to distributed computing.
• As each service uses its own database, it can increase the complexity of recording business transactions involving multiple entities as several databases all sharing common data might be required to be updated.
• It can be difficult to test microservice applications as you’re required to launch individual testing services for each application.
• In case of monolithic applications it can be relatively easy to incorporate changes as only the corresponding modules need to be updated with the changes and the entire system can be deployed at a go. With microservices platforms, such as the AWS microservices architecture, you have to plan and carefully coordinate the rollout of changes for each service.
• Deployment of microservices-based applications can be complex as each service can have multiple run time instances and needs to be configured, deployed, scaled, and monitored independently. A service discovery mechanism may also be required for successful deployment.

When to use Microservices Architecture

• Decentralized data management
  Each microservice platform service “owns” its database and other services are required to use that particular service’s API to access its data. Useful when the organization has several autonomous process flows and access to each process, including its databases, needs to be secured.
• Module with strong boundaries
  Divide the entire software into individual modules, with each module encompassing a unique business logic and/or functionality. It is easy to maintain decoupled software since the functionality is divided into individual modules. Moreover, to carry out changes one needs to thoroughly understand a particular module only and not the entire system. Useful for building large applications subjected to market changes and varying end user requirements.
• Independent deployment
  Microservices platforms like Amazon microservices support independent deployment of its services while releasing to production. Useful for organizations practicing continuous delivery and deployment. You don’t have to commit the entire build, but rather just deploy a single stream and do the commit. It allows organizations to do production releases several times a day.
• Technology diversity
  As each microservice is independently deployable, you have the freedom to choose your particular development technology while designing a module or service. Useful while building an architecture that requires different types of technologies to provide specific functionality. Ideal for IoT development and building cross-platform application systems.
• Remote or distributed development
  Each team works on a particular technology to develop a particular service. Very useful for companies offshoring their IT projects to various countries to cut down development costs. You don’t have to employ in-house team to develop technology-specific modules, but outsource those modules to remote teams specializing in that particular microservice technology.
• Maintain strong consistency levels
  Each miroservice, like those supported by AWS microservices architecture, can be individually tested. Moreover, each service can be tested frequently as and when changes are made in them. This makes the entire architecture highly stable and reliable. Useful for organizations working with real-time systems where platform reliability is a strong USP.
• Operational complexity
  As each service can be developed independently and you can design several services in the microservice architecture, you can build complex or large-scale applications supporting different business logic and functionality.

What is a Monolithic Application?

Monolithic applications have a single code base with multiple modules and a single build system. The entire application, with its inherent modules, including all dependencies, is compiled at a go and you have a single executable binary version for the entire app.

This is the traditional way of creating applications. Prior to the Windows operating system, developers created application code using single-build technologies such as COBOL and Fortran in which the source code was compiled and later “linked” to create a single .EXE file which comprised of binary executable code. Monolithic architecture is also called “multi-tier architecture” since applications are usually divided in three or more layers, or “tires.” Monolithic applications also have fewer dependencies as all supported files are compiled simultaneously and their functionality is automatically included in the single build version. The drawback of creating a single build is that the size of .EXE file increases drastically and requires pagination services to load successive pieces of executable code in the CPU memory, one at a time, to run the application. This drastically reduces the processing time, as the CPU has to undertake more I/O tasks at a time to load binary code.
Enterprises mainly focused upon desktop/laptop devices in the past, with the web browser functioning as a client. The process did not require exposing data with the API, since browsers could understand only HTML, CSS and JavaScript.

However, with time, the entire paradigm shifted from just serving the applications on browsers. A need was created to serve data on different devices and form factors such as smart phones, tablets, handheld devices, etc. This revolutionized the programming and code development scenario as traditionally built applications were required to be made compatible and rendered on different types of devices.

As businesses evolved and end user requirements started becoming more and more complex, and demanding, it started becoming increasingly difficult for developers to integrate code and manage added dependencies required to make the application compatible with other device-types in a single build. It became difficult to update and manage applications, and incorporate end user induced changes in it.  This is one of the main reasons why monolithic architecture started becoming obsolete and why microservices architecture gained popularity. 

Benefits of Monolithic Architecture

• Easy and simple to develop.
• Testing process is easy – You can do end-to-end testing simply by launching the application and testing its UI with Selenium.
• Can be effortlessly deployed. Just copy the packaged application to the server.
• Simple and easy to scale.
• Works well in the early stages. Most successful applications today were initially developed as monolith applications.

Drawbacks of Monolithic Architecture

• Can only handle limited complexity.
• Difficult to change and incorporate changes since the application is typically large and complex to understand.
• The bloated size of the application can drastically slow down start-up time.
• Redeployment required for the entire application with each update.
• Impact of end user changes is not understood well so extensive manual testing is necessary.
• Continuous deployment is made very difficult.
• Difficult to scale when modules having different functionalities have conflicting resource requirements.
• Not reliable. Bugs existing in a particular module can potentially bring down the entire system.

When to use Monolithic Architecture

• To reduce development costs

Generally, organizations select a technology that fulfils most of their development requirements and use that to develop their automation processes. You don’t need multi-skilled teams or cross platform developers to build your system since each developer will use the same technology to develop the functionality. This greatly reduces development costs and improves project sustainability.

• To reduce planning and design

You have to plan for and design a single app only so you need to create and maintain a single development plan. Useful when you’ve to build a simple and small-sized app – You can get started with development quickly since you don’t have to spend time setting up and configuring individual microservices.

• Increase code reusability

Since developers share a common development platform, homogenous code developed by one web developer can be reused by another. This significantly saves coding time and efforts.

Conclusion

Microservics architecture has gained popularity and momentum mainly due to the following factors:

• Frustration at not being able to get desired outputs and productivity levels using monolith architecture.
• Proliferation of tools and technologies to easily develop and deploy microservices applications.
• Large-scale adoption of Infrastructure as a Service (IaaS) like Amazon Web Services, Google Cloud Platform and others that have made DevOps operations easy.
• Majority of product-based companies adopt microservices architecture to make development quick and affordable.

In the coming years, monolith architecture may be used just for prototyping new products while mainstream development might be carried out using microservics architectures supporting modularity and easy-scalability of applications.