Getting Started With Microservices

Posted By : Ankit Rai | 03-Sep-2020

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

 

 

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.

 

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. 

 

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. 

 

At Oodles Technologies, our experienced developers are skilled at using advanced tools like Kubernetes, Apache Kafka, and Spring Boot to build microservice-based applications. Explore our services and learn about our offerings in microservice-based application development. For project-related queries, contact us at info@oodlestechnologies.com.

About Author

Author Image
Ankit Rai

He is a dynamic Devops Engineer having good knowledge of AWS, Jenkins, Python, GIT, BASH, Docker, and Cloud Security

Request for Proposal

Name is required

Comment is required

Sending message..