Monolithic Architecture v/s Microservices

Monolithic Architecture v/s Microservices

Recently, there are a lot of discussions happening about microservices in almost all the IT companies. Microservices architecture can be easily understood when we compare it with traditional monolithic architecture.
When developing a server-side application you can start it with a modular hexagonal or layered architecture.Almost every enterprise application has a similar kind of layered architecture:

1. Presentation: The user interface. Responsible for handling HTTP requests and responding with either HTML or JSON/XML (for web services APIs).
2. Business logic: The application’s internal business logic.
3. Database access: Almost all applications need data access objects(like SQL or NoSQL) to access DB.
4. Application integration: Quite often, the application needs integration with other applications. This is usually achieved via web service calls (SOAP or REST API), or via messaging. 

Despite having a logically modular architecture, the application is packaged and deployed as a monolith. There are actually some advantages to doing this.

Advantages of Monolithic Architecture

1. Simple Development: Development is quite simple.
2. Simple Testing: Testing is very simple. Just launch the application and start end-to-end testing. We can also do test automation for  testing the UI with Selenium without any difficulty.
3. Simple Deployment: Simple to deploy. You just have to copy the packaged application to a server.
4. Simple Horizontal Scalibility: Simple to scale horizontally by running multiple copies behind a load balancer. However, as the monolithic application grows in size, scalability becomes a serious issue.

Disadvantages of Monolithic Architecture

1. Flexibility: Monolithic architecture is not flexible. Monolithic applications has a barrier to adopting new technologies. Since changes in frameworks or languages will affect an entire application it is extremely expensive in both time and cost. So, tech stack is decided in advance.
2. Reliability: Another problem with monolithic applications is reliability. It's not reliable. Bug in any module (e.g. memory leak) can potentially bring down the entire process. Moreover, since all instances of the application are identical, that bug will impact the availability of the entire application.
3. Development speed: Development is really slow in monolithic architecture. It's difficult for new team members to understand and modify the code of a large monolithic application. Impact of a change is usually not very well understood which leads to do extensive manual testing. Code quality declines over time. The larger the application, the longer it takes to start up. All these factors have a huge impact on the developers' productivity. 
4. Building complex applications: It's difficult to build a complex application because of the limitations in terms of technologies.
5. Scalability: Monolithic applications can also be difficult to scale when different modules have conflicting resource requirements.With monolithic architecture, we cannot scale each component independently.
6. Continuous deployment:  Large monolithic applications are actually an obstacle to frequent deployments. In order to update one component, we have to redeploy the entire application.
7. Size: The size of the application can slow down the start-up time. This simple approach has a limitation in size and complexity.

Because of all the above drawbacks of monolithic applications, microservice architecture is becoming more and more popular day by day. 

So what is microservice-based architecture?

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, usually via RESTful web services or messaging. Some microservices would expose a REST, RPC or message-based API and most services consume APIs provided by other services. Other microservices might implement a web UI. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There’s a bare minimum of centralized management of these services, which may be developed in different programming languages and use different data storage technologies. Microservices are small, independently deployable units which are cloud-enabled.
Some APIs are also exposed to the mobile, desktop, web apps. The apps don’t, however, have direct access to the back-end services. Instead, communication is mediated by an intermediary known as an API Gateway. The API Gateway is responsible for tasks such as load balancing, caching, access control, API metering, and monitoring. 

How Microservice Architecture Tackles the Drawbacks of Monolithic Architecture

1.  Flexibility: Microservices architecture is quite flexible. Different microservices can be developed in different technologies. Since a microservice is smaller, the code base is quite less, so it’s not that difficult to upgrade the technology stack versions. Also, we can incrementally adopt a newer technology without much difficulty.
2. Reliability: Microservices architecture can be very reliable. If one feature goes down, the entire application doesn’t go down. We can fix the issue in the corresponding microservice and immediately deploy it.
3. Development speed: Development is pretty fast in microservices architecture. Since the volume of code is much less for a microservice, it’s not difficult for new team members to understand and modify the code. They become productive right from the start. Code quality is maintained well. The IDE is much faster. A microservice takes much less time to start up. All these factors considerably increase developers' productivity. 
4. Building complex applications: With microservice architecture, it's easy to build complex applications. Deciding the boundaries of a microservice can be quite challenging. It’s actually an evolutionary process, but once we decide on a microservice, it’s easy to develop, as there are no limitation in technologies.
5. Scalability: Scalability is a major advantage in microservice architecture. Each microservice can be scaled individually. Since individual microservices are much smaller in size, caching becomes very effective.
6. Continuous deployment: Continuous deployment becomes easier. In order to update one component, we have to redeploy only that particular microservice.
7. Size: If the features of the application are analyzed properly, we can break it down into independent components which can be deployed independently. Then, even the independent components can be further broken down into small independent tasks which can be deployed independently as a microservice. And hence, the applications start-up time decreases.

The Microservice architecture pattern corresponds to the Y-axis scaling of the Scale Cube model of scalability.

Microservices do have distinct advantages:

• Better Organization: Microservice architectures are typically better organized. Each microservice has a very specific job, and it is not concerned with the jobs of other components.
• Decoupled: Decoupled services are also easier to recompose and reconfigure to serve the purposes of different apps (for example, serving both the web clients and public API). They also allow for fast, independent delivery of individual parts within a larger, integrated system.
• Performance: Under the right circumstances, microservices can also have performance advantages depending on how they’re organized. It’s possible to isolate hot services and scale them independently of the rest of the app.
• Fewer Mistakes: Microservices enable parallel development by establishing a hard-to-cross boundary between different parts of your system. By doing this, you make it hard — or at least harder — to do the wrong thing: namely, connecting parts that shouldn’t be connected, and coupling too tightly those that need to be connected.

But they also create unique challenges:

• Cross-cutting Concerns Across Each Service: As you’re building a new microservice architecture, you’re likely to discover lots of cross-cutting concerns that you did not anticipate at design time. You’ll either need to incur the overhead of separate modules for each cross-cutting concern (i.e. testing), or encapsulate cross-cutting concerns in another service layer that all traffic gets routed through. Eventually, even monolithic architectures tend to route traffic through an outer service layer for cross-cutting concerns, but with a monolithic architecture, it’s possible to delay the cost of that work until the project is much more mature.
• Higher Operational Overhead: Microservices are frequently deployed on their own virtual machines or containers, causing a proliferation of VM wrangling work. These tasks are frequently automated with container fleet management tools.
• Complexity: Microservices architecture adding a complexity to the project just by the fact that a microservices application is a distributed system. You need to choose and implement an inter-process communication mechanism based on either messaging or RPC and write code to handle partial failure and take into account other fallacies of distributed computing.
• Testing a microservices application: It is also much more complex than in monolithic web application. For a similar test for a service you would need to launch that service and any services that it depends upon (or at least configure stubs for those services).

When To Start With A Monolith?

Here are some scenarios that indicate that you should start your next project using monolithic architecture:

• Your Team Is At Founding Stage: Your team is small, between 2–5 members, and is thus unable to tackle a broader and high-overhead microservices architecture.
• You’re Building An Unproven Product or Proof of Concept: Are you building an unproven product in the market? If it’s a new idea, it’s likely going to pivot and evolve over time, so a monolith is ideal to allow for rapid product iteration. Same applies to a proof of concept where your goal is just to learn as much as possible as quickly as possible, even if you end up throwing it away.
• You Have No Microservices Experience: If your team has no prior experience with microservices, unless you can justify taking the risk of learning “on the fly” at such an early stage, it’s likely another sign you should stick to a monolith to start.

When To Start With Microservices?

Here are some scenarios that indicate that you should start your next project using microservices:

• You Need Quick, Independent Service Delivery: Microservices allow for fast, independent delivery of individual parts within a larger, integrated system. Note that, depending on your team size, it can take time to see service delivery gains versus starting with monolith.
• A Piece of Your Platform Needs to Be Extremely Efficient: If your business is doing intensive processing of petabytes of log volume, you’ll likely want to build that service out in a very efficient language (i.e. C++) while your user dashboard may be built in Ruby on Rails.
• You Plan To Grow Your Team: Starting with microservices gets your team used to developing in separate small services from the beginning. And having teams separated by service boundaries makes it much easier to scale up your team when you need to without introducing exponential complexity.

Summary:

Microservice architecture can be easily understood when we compare it with traditional monolithic architecture, but prior to microservices, there’s already similar kind of architecture available. Yes, I’m talking about SOA (Service-Oriented Architecture). SOA has been here for two decades. If you have already worked with SOA and are familiar with its concepts, it could be quite confusing to understand the differences between SOA and microservice architecture. In fact, the two have more in common than differences.

There are opinions which suggest to start from the monolith first and others which recommend not to start with monolith when your goal is a microservices architecture. But in my opinion it is important to understand Monolithic architecture since it is the basis for microservices architecture where each service by itself is implemented according to monolithic architecture. The Microservices architecture pattern is the better choice for complex, evolving applications. Actually the microservices approach is all about handling a complex system, but in order to do so the approach introduces its own set of complexities and implementation challenges.

"Choose the Architecture You Can Comfortably Live With"

Microservices has become an increasingly popular service architecture, but it’s essential to understand whether it’s the best fit for your project. Your own context, evaluated against the above considerations, is the key to deciding if you should start with monolith or microservices.