Microservices Architectures

What Is Microservices?

With the evolution of technology like IoT, Big Data, Cloud and the world moving towards the API economy, the traditional monolith architecture pattern (SOA) started showing problems. It became difficult to define the granularity of a project because of the complex systems and hundreds of interfaces. This was when the Microservices architecture was born. Its aim was to create applications that were developed around business domains and could be developed, handled and decomposed into services that communicated through APIs and network-based messaging protocols.

Microservices Architecture or Microservices is a method for developing software applications for enterprises that are more flexible and independently deployable with smaller modular services. Microservices architecture follows the DevOps implementation approach for service-oriented architectures (SOA) and communicates with each other over a network for building a continuously deployed system.

There have been lots of buzz around the word ‘Microservices’ in the past few years, which also made it to the Gartner Hype cycle, however, some critics in the software community are of the view that Microservices has nothing new and is just a rebranded version of an SOA. Despite all the hype and the criticisms, Microservices comes with its share of benefits especially when it is about adopting agile development for a complex software application.

Challenges of The Monstrous Monolithic Architecture

Let’s imagine that we are building a web application. We start with designing the Presentation layer for the user interface, the Application layer for handling the business logic, an Integration layer for integrating various component of the application layer and finally the Database layer which will be accessible to all the underlying system. We will then deploy all these layers to either a WAR/EAR package in order to run the entire application.

Which means that the business logic becomes the core of the application, while all the other interfaces and adapters surround the core. Isn’t this a very simple approach? It is easy to develop and simple to test. Then what is the huge limitation that actually paved the way for the invention of Microservices Architecture? Unfortunately, this simple approach has some huge limitations. It is a monolithic application because every component even after being separate and independent are packaged under one roof of EAR/WAR. Following are some of the limitations of this Monstrous Monolithic Architecture:
• Any popular software application will eventually grow and becomes huge with the frequent addition of new codes thus overloading the IDE and reducing the developer’s productivity.
• Changing the technology stack of the application will get difficult because everything is packaged in one EAR/WAR and you really can’t predict how it will impact the current functionality.
• Any minor malfunction in a single function or component in the application can affect the entire application. • Scaling such monolithic application can only be done by deploying the same EAR/WAR packages in more servers. Each of these copies of the application will consume the same amount of resources and time, thus making it inefficient.
• This inefficiency affects the development cycle. With the growth of an application, the developers are expected to break things down into workable units so that they can work independently and deploy their own modules, however with the monolithic architecture, they are always dependent on each other, overall increasing the development time.

The Advantages of Microservices

The advantages of Microservices over the monstrous monolithic system have convinced some of the major enterprises like Netflix, Amazon, and eBay. Listed are some of the advantages:
• Tackles the complexity problem of an application development by breaking the process into manageable chunks or services. Therefore, moving away from the monolithic code base and making the development process much faster and easier to understand and maintain.
• Improves fault isolation: malfunction or failure in any single module or component of the application cannot affect any large part of the applications.
• Scaling of the applications under microservices become easy as it allows each service to be scaled independently. You can deploy just the number of instances of a particular service or different services based on its capacity or constraints.
• Provides the much-needed independence to the developers thus providing them agility in the process of creating richer services. Developers can freely choose the technology or language that they want to code with and deploy them immediately after being tested without coordinating with the other developers. Therefore, enabling continuous deployment.
• Microservices architecture services are easy to use and understand.

The Disadvantages of Microservices Architecture

Every technology, even after its popularity in the industry, comes with its share of drawbacks. Listed some of the potential disadvantages of a Microservices architecture.
• There was so much hype around the size of services that Microservices Architecture provides, that it took away from its main goal which was to decompose the application sufficiently so that it provides enough agility to the development and deployment process.
• The more distributed and independent the services are, the more complicated it gets to handle requests between modules. Developers have to implement an inter-process communication mechanism based on messaging or RPC.
• Multiple databases and transaction management is a painful task.
• Testing a microservices-based application is also much more complex. Unlike the monolithic architecture where the test process was launched on the EAR/WAR files, testing the Microservices architecture one need to test each of the dependent services before giving a green go.
• Similarly deploying a microservices-based application can also be complex. Developers need to take care of the coordination between the independent services before initializing the deployment process. It is not as simple as deploying in a WAR container.

Conclusion