Category: microservices Design Patterns

Microservices Design Patterns – Aggregator ”; Previous Next Problem Statement Microservice architecture structures an application as a set of loosely coupled microservices and each service can be developed independently in agile manner to enable continous delivery/deployment. When a large, complex application is to be built using microservice architecture, we often need to get the combined result of multiple microservices and show on the application. Solution We can define an Aggragator as a simple web module will act as a load balancer, which means it will call different services as per requirements. Following is a diagram depicting a simple microservice web app with aggregator design. As seen in the following image, the “Aggregator” is responsible for calling different services one by one. If we need to apply any business logic over the results of the service A, B and C, then we can implement the business logic in the aggregator itself. An aggregator can be again exposed as another service to the outer world, which can be consumed by others whenever required. While developing aggregator pattern web service, we need to keep in mind that each of our services A, B and C should have its own caching layers and it should be full stack in nature. Print Page Previous Next Advertisements ”;

Decompose By Strangler ”; Previous Next Problem Statement Microservice architecture structures an application as a set of loosely coupled microservices and each service should be developed independently in agile manner to enable continous delivery/deployment. When a large, complex application is to be built using microservice architecture, the major problem is how to design loosely coupled microservices or to break a large application into small loosely coupled services? Solution We can define a microservice using strangler pattern. A strangler application has two types of services − Existing Behavior − These services exhibits the behavior that previously resides in Monolith. New Functionalities − These services implements new behavior. So over the time of development, microservices increases and monolith shrinks with features moving out from monolith to Strangler Application. Example Consider an example of an Online Book Store. Initially we have only developed Book Catalog management service and other services are supported in legacy monolith application. During the course of development, more and more services are developed and functionalities are moved away from a monolith. So when a new service is developed, the monolith is strangled, the old component is decommissioned and new microservice is deployed and supports the new functionality. A strangler pattern can be implemented using three steps − Transformation − Develop the microservices independently to implement a particular functionality of a monolith. Co-Exist − Both Monolith and Microservices will work. User can access functionality from both components. Elliminate − Once the newly developed functionality is production ready, remove the functionality from the monolith. Advantages Test Driven Development − As services are developed in chunks, we can use TDD for business logic and ensure the code quality. Independent Teams − Teams can work in parallel fashion on both monolith and microservices thus making a robust delivery mechanism. Print Page Previous Next Advertisements ”;

Microservices Design Patterns – API Gateway ”; Previous Next Problem Statement Microservice architecture structures an application as a set of loosely coupled microservices and each service can be developed independently in agile manner to enable continous delivery/deployment. When a large, complex application is to be built using microservice architecture, microservices can use different protocols. For example, some microservices are using REST and some are following AMQP. Now problem is how to allow clients to access each microservice seemlessly without worrying about protocols and other intricacies. Solution We can define an API Gateway which will acts as single entry point for all type of clients. Following are the other benefits of API Gateway − Simple Proxy − API Gateway can acts as simple proxy to some requests to redirects them to relevant service. Multiple Services − API Gateway can redirects call to multiple services. Client Specific API − API Gateway can provide client specific API as well, like a different API for Desktop version than a Mobile Application. Protocol Handling − API Gateway handles the communication protocols to each service call internally and clients are concerned only with request/response. Security and Authentication − API Gateway can implement a security that each request goes to service only after authentication and authorization. Example Consider an example of an Online Book Store. API Gateway allows to use the online Book store APIs on multiple devices seemlessly. Advantages Client Insulation − Clients are insulated from knowing the location of microservices or how to call them. Multiple Service Calls − API Gateway can handle multiple services and give result as one and thus can reduce the round trips and increase the performance. Standard Interface − API Gateway provides a standard interface to Clients to get responses from microservices. Print Page Previous Next Advertisements ”;

Microservices Design Patterns Tutorial PDF Version Quick Guide Resources Job Search Discussion Microservice is a service-based application development methodology. In this methodology, big applications will be divided into smallest independent service units. Microservice is the process of implementing Service-oriented Architecture (SOA) by dividing the entire application as a collection of interconnected services, where each service will serve only one business need. In this tutorial, we”ll cover all the important design patterns while using/developing the microservices which helps in solving the common problems developers/users face in a microservices based architecture. Audience This tutorial is designed for developers who would like to understand the microservices architecture and design patterns applicable in this architecture of software development. Prerequisites Before proceeding with this tutorial, you should have a reasonable knowledge of basic computer programming and Service-oriented architecture. Print Page Previous Next Advertisements ”;

Database per Service ”; Previous Next Problem Statement Microservice architecture structures an application as a set of loosely coupled microservices and each service can be developed independently in agile manner to enable continous delivery/deployment. What should be the database structure/architecture in microservices based application. Solution We can keep each microservice data private to that microservice and this data will be accessible only via relevant microservice. The microservice will use its own database for transactions. Following diagram shows database per service design pattern implementation. Database per Service does not always need to have seperate databases provisioned. We can implement the pattern using following ways considering a relational database. Private tables per Service − Each microservice can utilize a set of tables and these tables should be accessible only via their relevant microservice. Schema per Service − A seperate schema can be defined per microservice. Database Server per Service − Entire database server can be configured per microservice. Print Page Previous Next Advertisements ”;

Log Aggregation ”; Previous Next Problem Statement Microservice architecture structures an application as a set of loosely coupled microservices and each service can be developed independently in agile manner to enable continous delivery/deployment. Requests often span multiple services. Each service instance write some information in its log file in a standardized format. These logs can be info, error, warning or debug logs. How to analyze and troubleshoot application problems using these logs. Solution We can use a centralized logging service which aggregates the logs from each service. User should be able to search and analyze the logs provided by this logging service. User should be able to configure alerts when certain type of messages appear in logs. Corelation ID When first microservice receives a call, it should generate a corelation id which then can be passed to downstream services. This corelation id should be logged across all microservices. It will help to track the information spanning multiple services. Searchable Logs As logs should be placed at a centralized location, following diagram showcase how to use Kafka, LogStash and Kibana to aggregate logs and search the indexed logs using required filters. Microservices generates logs, which are published using kafka log appender which then output the log messages to kafka cluster. LogStash ingests the messages from kafka, transforms the messages and publish to elastic search container. Now kibana provides a visual interface to search/read indexed logs from elastic search container and provides required filters. Print Page Previous Next Advertisements ”;

Command Query Responsibility Segregator ”; Previous Next Problem Statement Microservice architecture structures an application as a set of loosely coupled microservices and each service can be developed independently in agile manner to enable continous delivery/deployment and if we”ve used a database per service design pattern then how to make query which needs data from multiple services. Solution We can define a view database which is a read-only data to support the required query. Application will keep the view database up to date by subscribing to the events raised by the services which owns the data. In this design pattern, we segregate the update and read operations. One service will only read the data and other services will update the data. In order to implement this pattern, we often need to refactor the domain model to support seperate operations for querying data and to update data so that each operation can be handled by microservices independently. CQRS patterns ensures that operation that reads data is seperate from that which updates the data. So an operation can either read or write data but cannot perform both together. Now multiple services can update the records and send events to application to update the view database. This helps the Query service to get the consistent data without any performance hit. Print Page Previous Next Advertisements ”;