Microservices Architecture

Microservices

• Microservices refers to an approach to application development
• Each element of functionality is placed into a separate service
• Each service is deployed independently
• Microservices relies on software engineering principles and best practices
• Low coupling and high cohesion are important aspects of microservices
• Asynchronous communication is used

History

• Traditional distributed systems are single, client/server based, and developed top-down
• Contemporary distributed systems need to include third-party sub-systems, such as insurance contracts and event tickets
• Traditional eServices relied on TCP/IP and proprietary protocols
• The focus has moved from interfaces to communication and protocols, and the Web is the de-facto communication infrastructure
• REST architectural style is the current trend for building applications

Advantages

• Microservices accelerate delivery by minimizing communication and coordination between people and change
• It is SOA without the commercialization
• Microservices are about people
• Microservices emphasize small, focused components that are autonomous and independent
• They are small enough to be handled by a single cross-functional team in a business area
• Microservices are composable, replaceable, and offer deployment benefits with lower risk
• Microservices allow for selective scaling, improve resilience against failure, and alignment with the organization structure
• Composability refers to the ability to construct complex systems by combining simpler components
• Replaceability refers to the ability to exchange components without affecting other parts of the system
• Deployment involves smaller pieces with decreased risk

Disadvantages

• They may also add complexity for simplicity, as there is no silver bullet for every problem
• Microservice-based applications favor simpler, lightweight protocols such as REST
• There are potential pitfalls if monolithic applications are not properly decomposed into microservices
• There are added challenges like implementing changes that span multiple services

Key Points

• Microservice-based applications avoid using ESBs and instead implement ESB-like functionality in the microservices themselves\
• A microservice architecture is similar to SOA
• High cohesion facilitates management and maintenance.
• Low coupling facilitates coordination
• With microservices, every module or class should have responsibility over a part of the functionality provided by the software
• High cohesion enables the implementation of the service to change without impacting its clients

The Hype

• As of March 2016, 68% of organizations were using and/or investigating microservices
• They report a 75% drop in development lead times

Microservices Adoption Status

• In 2020, most adopters are successful -Under 10% report "complete success", most (54%) describe their use as "mostly successful,” and 92% say "some success"
• Many are betting big on microservices with almost a third (29%) migrating a majority of their systems (over 50%). -Respondents cite adopting containers as a reason -Teams who were using containers for microservices indicated more success in adoption
• Also culture plays a key role

Monolithic Application

• Core is business logic, is implemented by modules that define services, domain objects, and events.
• The core is surrounded by adapters, the interface with the external world ie. database access, messaging, and web
• Has logically modular architecture that is packaged and deployed monolithically
• Is packaged as WAR files and deployed on application servers like Tomcat or Jetty.

Issues in Monolithic Software

• It is difficult to maintain and evolve
• It can suffer from "dependency hell,” adding or updating conflicting libraries
• "Rebooting" is required for any change
• It can show expensive or suboptimal delivery, for the requirement
• CPU-intensive ideally is Amazon EC2 Compute Optimized
• Memory-intensive would ideally be Amazon EC2 Memory optimized
• Can represent a tech "lock-in” for developers
• reliability problems, such as memory leaks, can potentially bring down the entire process

Architecture

• Splits the application into a set of smaller, interconnected services.
• Each service handles a set of features like order management, customer management, etc.
• Each microservice is a small application that exposes: -An API for other microservices; -A Web UI.
• Each instance is usually a cloud VM or a Docker container.
• Some REST APIs are exposed to mobile apps, using an API Gateway.
• It can be complex due to Developers needing to implement an inter-process communication
• It must also be able to handle partial failures like slowness and unavailability

Other elements

• API Gateway: Responsible for tasks such as load balancing, caching, access control, and monitoring. -Load balancing, caching, access control, API metering, and monitoring are also duties
• Each service has its own database schema.
• Is against the enterprise-wide data model.
• Can result in some data duplication
• Ensures loose coupling

Benefits of Microservices

• Tackles the problem of complexity
• It breaks it into manageable chunks or services
• Helps makes it easier to understand and maintain
• Enables each service to be developed independently
• Free to choose whatever technologies that make sense, provided that the service and API contract
• Ability to Rewrite an old service using current technology

Scaling

• Microservices can scale and deploy each service on its own.
• One can deploy a CPU-intensive image processing service on EC2 Compute Optimized instances
• One can also setup a in-memory database service on EC2 Memory-optimized instances.
• Microservice architecture is based on the single responsibility principle and high cohesion.

Scaling Dimensions

• The three major dimensions for scaling: -X-axis scaling runs multiple copies of the app -Y-axis scaling splits the application into microservices -Z-axis scaling splits the data
• Microservice architecture is an application of Y-axis scaling

Deployment

• Deploying a microservices-based application can be more complex than using a monolithic application
• With a monolithic application, you deploy on identical servers behind a traditional load balancer.
• Each app instance is configured with databases/message brokers
• With a microservice app, you have a large number of services.
• Need 100s of “moving parts” to configure, deploy, scale, monitor

Microservice Architecture Automation

• Automation can be done by using something Off the shelf ie. PaaS like Cloud Foundry.
• They'll allow easier management, deployment etc
• It lets them comply with company best practices, and compliance
• Create your own, use containerization to help
• Can use Kubernetes (clustering solution) & Docker (technology)

Drawbacks to Architectures

• One can place excessive emphasis on the size of your microservice
• Goal of microservices is to enable easy applications
• Complexity can also be a drawback
• The developers can pick and choose the approach to communication based on RPC messaging
• Microservices require partitioned architecture
• Another major drawback is the complexity that arises from the fact that a microservices application is the distributed system. -Need for inter-process communication -Handle partial failure. -All of which results in a system much more complex
• Business needs in microservices require different databases that are owned by different systems
• For that, one needs to update those databases which are not allowed

Microservices Adoption In 2020 and Beyond

• Permissionless Innovation -“the ability of others to create new things on top of the communications constructs that we create".
• Enable Failure -Mature one should enable failure
• Disrupt Trust -Effective model for evolving orgs

Hidden dividends in microservices

• Consist of the Build it, Own it methodology based on the idea of small teams being able to build and manage their own
• Microservices are encouraged to use the "you build it, you own it" model
• Deprecations
• Easy deprecations via a clear call
• Easily create different versions of a service, or build a new service
• Can be used to end centralized metadata
• Focuses on concentrate pay
• Makes Test Differently
• Eng team sees that as a chance to readdress tests as a team

Microservices in practice

• A pattern is a re-usable solution to a common problem. -forces to state other ignore-able parts. -Must identify context where it belongs. -If a bad match, it may not work.
• For the pattern, one must
• Define their forces, the issues that have too, be addressable during the resolution -Their context
• And related patterns.

Key Terms

• Pattern - reusable solution to a problem
• Forces
• Resulting context -What benefits -Drawbacks -Issues
• Related patterns -Predecessor -Successor -Alternative -General -Specific -Monolithic Architecture Pattern - Structure as single executable / deployable
• One can choose between Remote Proc Invocation and async patterns

This lesson explores the microservices architectural style. It covers the history of distributed systems and how microservices have evolved. The advantages of using microservices are also discussed in detail and how its faster to deliver.