Microservice Architecture

• Presentation Layer — It is the topmost layer of the application and describes the user interface. The main function is to translate tasks and results to something that the user can understand. User interface code is written in the client-side technologies like HTML, JavaScript, and CSS.
• Business Layer — This layer makes logical decisions and performs calculations. It processes the data between two layers and uses technologies like Spring.
• Data Access Layer — Here the information is stored and retrieved from the database. The information is passed to the business layer and then ultimately to the user. It uses ORM tools like Hibernate to process the info

• Operational Overhead: Different stakeholders work with the different layer of monolithic application; hence the team will be confined to the specific domain expertise. The team who works on the presentation layer are specialized in UI technologies but have the least knowledge of data access layer. Hence, if a new feature is to be added, it requires different teams to coordinate and deliver a particular feature. This results in more time-span from ideation to time-to-market and ultimately affects the business ROI.
• Software stack autonomy: It limits technology choices and forces an entire layer to use the single framework. For instance, if the presentation layer is written in an HTML framework, the whole layer is to be implemented within the same framework. This refrains from implementing the latest technology, which results in the application code on becoming obsolete in a short time..
• Implicit Interface: As this codes are released in the single file, a minor change in the application calls for the rebuilding of the entire application. Due to this, on-going applications are put down and results in the need of redeploying the new version. This nature results in fewer updates and is not able to evolve as fast as they should.
• Scalability: Monolithic applications possess one-dimensional scalability; hence fails to scale the individual components. So, the entire application needs to be scaled even though most of the applications might not require scaling.

• Componentization to perform the single functionality
• Organized as per business capabilities
• Focuses on products not process
• Decentralized governance and data management
• Service is elastic, resilient, composable, minimal and complete

• Improved Productivity and Speed

With microservice, productivity and speed can be easily tackled. The different team works on different components simultaneously without having to wait for one team to finish the task. This results in speeding up the quality assurance as each micro-service can be tested individually. Other stakeholders can work on enhancing the components that are already developed, while other programmers are working on other ones. This increases the speed and leads to the faster release of the product.

• Aligned with the organization

If an organization is using micro-service, team size can be defined to match with the required tasks. Moreover, teams can be broken down into smaller groups and can focus on single components of the application. As the end goal is customer satisfaction and great user experience, the team is not divided into UI team, database team and so on. For instance, if a team working in UAE is handling three services while the team working in California is handling five services, each team working in California and UAE can release and deploy different functionalities independently. These cross-functional teams work towards the fulfillment of one single functionality breaking down the silos between team fostering better collaboration.

• Provides scalability

Microservices scale the parts that have performance issues and use the hardware that best matches service requirements. As each service is the separate component, scaling can be deployed using more containers, enabling more effective capacity planning, less licensing cost and appropriate hardware. Components of the critical service can be deployed on the multiple servers for the increased availability and performance without impacting the performance of the other service. This scalability results in better customer-experience and increases cost-savings.

• Easy to modify technology stack

With microservices, a software development company can try new stack or the latest technologies on the specific components to increase usability and avail larger benefits at the application level. As there are no dependency issues, software developers can avoid using particular technology stacks if they are not providing consistent user-experience. With such continuous modernization, your system won’t become easily outdated.

• Improves fault-isolation

In Microservice architecture, developers are aware of exactly on where to look for the issues to get solved. If a single module is affected, it can be easily demolished or resolved without other parts of an applications getting affected; increasing application’s availability. This is exactly contradictory in the monolithic application; failure of a single component can pull down entire application. For instance, mobile gaming applications (built on monolithic architecture) which have different components like payment, login, player, history, and others. If a particular component, starts to consume more memory space, the entire application will be affected which would result in a poor user experience.

• Testing of microservice based application can be a painful task because each dependent service needs to be confirmed before starting the testing. As the number of services increases, complexities don’t remain at the backstage! Keeping tabs on all services becomes impractical because, there may occur database errors, network latency, caching issues etc. Hence, resiliency testing and fault injection become a must.

• As microservice focuses on distributed systems and independent service each request needs to be handled carefully between the modules. It may happen that one of the services doesn’t respond which forces developers to write the extra code to avoid disruption.

• Each service depends on its own API and platform, tracking down everything can be a pain-stacking job. A leader needs to monitor multiple entities and manage the entire infrastructure because if in-case any service fails, it becomes tedious to track down the issues. Thus, robust monitoring becomes necessary.