Thinking about Microservices

Introduction

 
Microservices are trending and the buzz word in the industry, but before knowing about Microservices, we should know about what is being used now and before – It is Monolithic. Here is a detailed look at Monolithic architecture.
 

Monolithic Architecture

 
Monolithic architectures are considerably known as traditional application architecture which has a single bundle of solutions. This single bundle consists of a:
  1. Presentation Layer
  2. Business Layer
  3. Database Layer
Monolithic Architecture
Figure 1
 
Each of these dependent parts belongs to the same single application bundle, which means they are tightly coupled. This architecture has several advantages and disadvantages as shown below:
 
Advantages
  1. Simple implementation in single technology
    Everyone is talking the same language and hence it’s easier. Team interaction and coordination is easy. Single repository also works perfectly where the team is enabled with easy branching and tagging.

  2. Basic setup and start is very easy
    Project setup with basic building blocks is easy and required only once. Further add-on features are implemented on top of it.

  3. Direct Communication
    Communication between Monolithic components happens within the single application boundaries. No additional strategy is required to maintain this.

  4. Easy Debugging and Testing
    Debugging is straightforward and easy because all components are available in a single bundle and linked together.

  5. Easy Deployment
    Even we need multiple instances of an application it is easy to deploy the entire solution in multiple servers behind a load balancer. Deployment practice and steps are pretty straight forward. 
Disadvantages
  1. Slow development when large and complex
    When features keep on increasing and the team is adding/modifying code, again and again, complexity increases and eventually development speed goes down.

  2. Scaling is not possible by individual components or modules
    Because of a single bundle in nature, scaling is not possible by component or module. If you need to scale up, then entire application has to scale up, even when only single or few components must be scaled up.

  3. When there's a bug, the entire application may go down
    There is a high possibility of entire application going down on occurrence of a bug. E.g. if bug is leading to take down your app domain then entire application will go down for sure.

  4. Small changes can lead entire testing
    While making any change in Monolithic application, other modules are possibly impacted and hence require the entire application to be gone through with complete test cycles. This can consume a lot of time.

  5. Hard to do continuous deployment
    Until the entire build is ready, frequent and continuous deployment is not possible. This includes a complete test cycle, ensuring that everything is working well.

  6. Entire application is deployed when a small change
    When there is a change due to any bug fix or enhancement, the entire build has to be deployed again and not the fixes or modified module. Deploying and testing the entire application is really a cumbersome task to ensure everything is working properly.

  7. Adoption of new technology is nightmare
    Monolithic architecture is bound to be developed in single technology stack which actually requires relatively a big team in that technology stack. Also when migrating from one technology to another latest technology, it is very difficult and time taken. 

Microservice Architecture

 
As the name implies, this architecture is based on services. This architecture is more than SOA architecture. Services are typically separated by either business capabilities or sub-domain. Once modules/components are defined, they can be implemented through a different set of teams. These teams would be the same or different technology stack teams. In this way, individual components can be scaled up when needed and quickly scaled down once the need is over. Let’s take a look at the Microservice architecture:
Microservice Architecture
Figure 2
 

Benefits of Microservice Architecture

  1. A small team can be engaged and become the owner
    Unlike the Monolithic approach, Microservices architecture does not require a large set of teams in a single tech stack but a small team of different tech stacks can also be engaged. So in terms of organizational cost, it leads to savings.

  2. Easy understandable code and logic
    Since Microservices are small and less in code with respect to Monolithic, it’s easy to understand the code and logic written by one to another.

  3. Agility is easy
    Agility enables you to develop and build the product in parts. Since the entire application is broken down into small components, it’s easy to keep track of each of them. This step by step incremental approach helps to move fast.

  4. Introducing Resiliency
    Because of application is broken down based on the domain (or business capability), it is easy to maintain individually. This also reduces downtime and increase scalability.

  5. Accelerating Time to Market
    Since the entire complex process is broken down into smaller sub pieces, it is easy to reduce errors and shorten the development time. Any new enhancement or modification would require changes in concerned service only. Small, independently tested and deployed components lead you to push your product into market faster.

  6. Continuous delivery is possible
    To get all types of changes and new features, it’s possible all in the same go. It makes your business up-to-date and client happy.

  7. Extensibility is simple
    Whenever a new feature is required, simply add new service to the existing application architecture. No need to go back to existing code, build new features, and then a new feature can be added relatively faster because this would require new service to be introduced and won’t affect the existing code base.

  8. Replaceability anytime
    When needed, existing service can be replaced all together rather than maintaining them for long. This also forces us to maintain code quality, rather than modifying the existing code again and again with lots of patches. 

Do you really need Microservices?

 
Now we talked about the benefits of Microservices, but it does not mean that every single application architecture should be drawn in Microservices. Before adopting Microservice architecture- ask yourself “Do you really need a Microservices based application?” Judge your decision by asking a simple set of questions before moving ahead with Microservices.
  1. Does your current application requirement is large enough to break down into multiple domains? (i.e. Microservices?) If not probably you don’t need this approach.
  2. Does your application really need to scale modules or components individually? If not, you are good to go with Monolithic. E.g. an e-commerce application would need to scale their Order module during the SALE period and other modules such as user, product, etc would not be required while being scaled up.
  3. Project cost/duration is less? Microservices would be certainly costly for small applications because of its implementation, security, monitoring, infrastructure, etc. All these have to be informed to all stakeholders, then collaborative decisions can be taken.
  4. Are you ready for complex integration testing? Development of complex applications can be easy in the long run using Microservices but integration testing of all services will surely not. Ensure that you have enough tools, techniques and members to handle the situation.
  5. Do you have Full-stack developers? They are the basic requirement. If you don’t have ready members in a team, you must have them before jumping into Microservice architecture.
  6. Are you Dev-Ops ready? Without continuous integration/continuous delivery/continuous deployment (CI/CD/CD) pipeline, Dev-Ops culture can’t be set up which would require faster production. If you don’t have this culture, the entire purpose will be defeated.
  7. Do you have a strong monitoring system? Microservice architecture is a mesh of services and if any of them go down, they should be soon recovered or duplicated. Without a strong monitoring system and good fault tolerance process, this wouldn’t be possible and you will lose business.
There are more factors to be checked first, but the above-mentioned points are good to clear your doubts on whether to choose Microservice architecture or not.
 

Key Consideration while Implementing Microservices

 
Now you have a good overview of Microservice architecture, but having said that, practical implementation still has lot of differences compared to Monolithic. They are really not the same as traditional Monolithic architecture. We have to ensure everything is up and running effortlessly. The following are the key points which must be taken care of in this architecture,
  1. Storing Data
    Each Microservice must have its own and individual database. Why? Because if we keep a single database for multiple domain/service, it defeats the purpose of having this architecture. Failing a dependent database will fail the entire system, but keeping separate databases for each service will isolate exception and the system will still up partially. E.g. in e-commerce applications, if order service is down, the user can still browse products and get details.

  2. Service Communications
    Communication with services can be done using API Gateway. API Gateway is the central gate from where all requests can be translated and appropriate service can be invoked. Communication among services can be achieved using synchronous and asynchronous request/response using messaging queues.

  3. Security
    Unlike the Monolithic system, the Authorization and Authentication process is different in Microservices architecture. Monolithic application is easily using session whereas Microservices uses token-based authentication.

  4. Testing
    Since Microservices are completely distributed in nature, integration testing is different than a Monolithic application. Interprocess communication testing could be a challenge for a newbie.

  5. Deployment
    Each Microservice should be deployed in such a way so that they are not blocking other service resources, and that’s why independent deployment recommended. Containerization should be followed to create a more efficient deployment. Independent Deploy, Update, Replace, Scale (DURS) is the beauty of Microservices and must be used. 

Summary

 
This article should enable you to get an overview of Microservices architecture, including advantages over Monolithic architecture, the decision to choose Microservices and key points to consider during implementation.


Similar Articles