Abstract
Micro service architecture (MSA) has undoubtedly become the most popular modern-day architecture, often used in conjunction with the rapidly advancing public cloud platforms to reap the best benefits of salability, elasticity and agility. Though MSA is highly advantageous and comes with a huge set of benefits, it has its own set of challenges. To achieve the separation of concerns and optimal performance, defining the boundaries for the services clearly and their underlying persistent stores is quintessential. But logically segregating the services is a major challenge faced while designing the MSA. Some of the guiding principles like Single responsibility principle (SRP) and common closure principle (CCP) are put in place to drive the design and separation of microservices. With the use of these techniques the service layer can be designed either by (i) Building the services related to a business subdomain and packaging them as a microservice; (ii) or Defining the entity relationship model and then building the services based on the business capabilities which are grouped together as a microservice; (iii) or understanding the big picture of the application scope and combining both the strategies to achieve the best of both worlds. This paper explains these decomposition approaches in detail by comparing them with the real-world use cases and explains which pattern is suitable under which circumstances and at the same time examines the impacts of these approaches on the performance and latency using a research project.
Highlights
In the recent past all the applications were built using a monolithic design pattern
Backend services are isolated and distributed. These services are handled by a layer called Enterprise Service Bus (ESB) which is an integration and guarding layer for the entire backend
Though ESB pattern has the advantages of conducting the health checks, performing the routing for the backend services, it was soon found to be a cumbersome layer and a bottle neck as the application services grow in size
Summary
In the recent past all the applications were built using a monolithic design pattern. It was soon discovered that monoliths are more complex in nature due to their fundamental design, where the entire application code into a single deployable unit Due to this design, the code changes need to be well planned in advance and need to be thoroughly tested before deploying to production and leading to longer build cycles. Though ESB pattern has the advantages of conducting the health checks, performing the routing for the backend services, it was soon found to be a cumbersome layer and a bottle neck as the application services grow in size To handle these shortfalls, Microservice Architecture (MSA) was introduced with the similar premise of isolation and separation of concerns as proposed by SOA [3], but with a lightweight design. In section (IV) summary, conclusions are provided and an overview of future research work is given
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
Free) 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a call
