PN
Uploaded byPeter Nijem
PPTX, PDF213 views

Intro to Microservices Architecture

The document provides an overview of microservices architecture, highlighting the transition from monolithic applications to microservices for improved modularity, scalability, and independent deployment. It discusses the benefits and drawbacks of microservices, the necessity of inter-process communication, service discovery, and event-driven data management in this architecture. Key considerations such as API gateways, managing complexity, and handling partial failures are also addressed to illustrate the operational challenges faced when implementing microservices.

Embed presentation

Downloaded 14 times
Intro to Microservices Architecture Peter Nijem
Table of Contents Introduction to Microservices Using API Gateway Inter-Process Communication Service Discovery Event-Driven Data Management References
Intro to Microservices Architecture Introduction
Building Monolithic Application • Applications written in this style are extremely common • These kinds of applications are simple to develop and test • Monolithic applications are also simple to deploy • You can also scale the application by running multiple copies behind a load balancer • In the early stages of the project it works well
Building Monolithic Application • This simple approach has a huge limitation • After a few years, your small, simple application will have grown into a monstrous monolith • The sheer size of the application will also slow down development • Complex monolithic application is an obstacle to continuous deployment
Building Monolithic Application • Monolithic applications can also be difficult to scale when different modules have conflicting resource requirements • Monolithic application can be unreliable. A bug in any module, can potentially bring down the entire process • Monolithic applications make it extremely difficult to adopt new frameworks and languages
Microservices –Tackling the Complexity • Many organizations such as Amazon, eBay and Netflix have started to adopt the Microservices Architectural Pattern • The idea is to split your application into set of smaller, interconnected services • A service typically implements a set of distinct features or functionality, such as order management, customer management, etc • Each microservice is a mini-application that has its own business logic along with various adapters
Microservices –Tackling the Complexity • Some microservices would expose an API that’s consumed by other microservices or by the application’s clients • At runtime, each instance is often a cloud virtual machine (VM) or a Docker container
Microservices –Tackling the Complexity Benefits • It tackles the problem of complexity.The application has been broken up into manageable chunks or services • It enforces a level of modularity. Consequently, individual services are much faster to develop, and much easier to understand and maintain • This architecture enables each service to be developed independently by a team that is focused on that service. • It enables each microservice to be deployed independently • enables each service to be scaled independently
Microservices –Tackling the Complexity Drawbacks • The complexity that arises from the fact that a microservices application is a distributed system • The partitioned DB architecture. In a microservices-based application, you need to update multiple databases owned by different services • The challenge to implement changes that span multiple services. • Testing a microservices application is also much more complex • Deploying a microservices-based application is also much more complex. Each service will have multiple runtime instancesThat’s many more moving parts that need to be configured, deployed, scaled, and monitored
Intro to Microservices Architecture Using API Gateway
Client-Microservices Interaction When you choose to build your application as a set of microservices, you need to decide how your application’s clients will interact with the microservices: • Direct Client-to-Microservices Communication • Using anAPI Gateway
Direct Client-to-MicroservicesCommunication In theory, a client could make requests to each of the microservices directly. Unfortunately, there are challenges and limitations with this option: • Mismatch between the needs of the client and the fine-grained APIs exposed by each of the microservices • Some might use protocols that are not web-friendly likeThrift binary RPC and AMQP • It makes it difficult to refactor the microservices.We might want to merge two services or split a service into two or more services
API Gateway • API Gateway comes to the rescue! It is a server that is the single-entry point into the system • The API Gateway encapsulates the internal system architecture and provides an API that is tailored to each client • It might have other responsibilities such as authentication, monitoring, load balancing, caching, and request management • The API Gateway is responsible for request routing, composition, and protocol translation. All requests from clients first go through the API Gateway. It then routes requests to the appropriate microservice
API Gateway Benefits • It encapsulates the internal structure of the application.Clients simply talk to the gateway, rather than having to invoke specific services • The API Gateway provides each kind of client with a specificAPI • It simplifies the client code Drawbacks • It is yet another highly available component that must be developed, deployed, and managed • It might become a development bottleneck.The gateway must be updated in order to expose each microservice's endpoint • Developers can be forced to wait in line in order to update the gateway
Implementing an API Gateway Performance and Scalability • The performance and scalability of the API Gateway is usually very important • It makes sense, to build the API Gateway on a platform that supports asynchronous, non-blocking I/O • There are a variety of different technologies that can be used to implement a scalable API Gateway i.e. Netty,Vertx, Spring Reactor, Node.js etc
Implementing an API Gateway Using a Reactive Programming Model • Sometimes, there are dependencies between requests. Authentication before routing a request to a BE service • WritingAPI composition code using the traditional asynchronous callback approach quickly leads you to callback hell • Better approach is to implement it in a declarative style using a reactive approach i.e. Future in Scala, CompletableFuture in Java8, Promise in JS, and Reactive Extensions (RxJava, RxJS)
Implementing an API Gateway Service Invocation • It is a distributed system which must use an inter-process communication mechanism • There are two styles of inter-process communications: 1) Asynchronous, messaging-based mechanism. Message brokers vs. brokerless 2) Synchronous mechanism such as HTTP orThrift • A system will typically use both asynchronous and synchronous styles. It might even use multiple implementations of each style
Implementing an API Gateway Service Discovery • The API Gateway needs to know the location (IP address and port) of each microservice with which it communicates • Application services have dynamically assigned locations. Also, the set of instances of a service changes dynamically because of autoscaling and upgrades • API Gateway, like any other service client in the system, needs to use the system’s service discovery mechanism: either server-side discovery or client-side discovery
Implementing an API Gateway Handling Partial Failures • Another issue you have to address when implementing an API Gateway is the problem of partial failure • This issue arises in all distributed systems whenever one service calls another service that is either responding slowly or is unavailable • The API Gateway should never block indefinitely waiting for a downstream service However, how it handles the failure depends on the specific scenario and which service is failing
Intro to Microservices Architecture Inter-Process Communication
Inter-Process Communication How the services within the system communicate with one another? • In a monolithic application, components invoke one another via language-level method or function calls • In contrast, a microservices-based application is a distributed system running on multiple machines Each service instance is typically a process • Microservices user inter-process communication (IPC) to interact • Interaction Styles, Defining APIs, Evolving APIs, Handling Partial Failure, and IPC Technologies need to be considered before choosing any IPC method
Interaction Styles When selecting an IPC mechanism for a service, it is useful to think first about how services interact • One-to-one – Each client request is processed by exactly one service instance • One-to-many – Each request is processed by multiple service instances • Synchronous –The client expects a timely response from the service and might even block while it waits • Asynchronous –The client doesn’t block while waiting for a response, and the response, if any, isn’t necessarily sent immediately
One-to-One Interactions Synchronous • Request/response – A client makes a request to a service and waits for a response The client expects the response to arrive in a timely fashion Asynchronous • Notification (a.k.a. a one-way request) – A client sends a request to a service but no reply is expected or sent • Request/async response – A client sends a request to a service, which replies asynchronouslyThe client does not block while waiting and is designed with the assumption that the response might not arrive for a while
One-to-Many Interactions Asynchronous • Publish/subscribe – A client publishes a notification message, which is consumed by zero or more interested services • Publish/async responses – A client publishes a request message, and then waits a certain amount of time for responses from interested services Each service typically uses a combination of these interaction styles. For some services, a single IPC mechanism is enough. Other services might need to use a combination of IPC mechanisms
DefiningAPIs • A service’s API is a contract between the service and its clients • It is important to define a service’s API using interface definition language (IDL i.e. OpenAPI & Swagger) • The nature of the API definition depends on which IPC mechanism you are using • For messaging as an IPC, the API consists of the message channels and the message types • For HTTP as an IPC, the API consists of the URLs and the request and response formats
Evolving APIs • A service’s API invariably changes over time • In a monolithic application it is usually straightforward to change the API and update all the callers • In a microservices-based application it is a lot more difficult • You usually cannot force all clients to upgrade in lockstep with the service • Probably both old and new versions of a service will be running simultaneously due to incremental deploy of new versions of a service
Evolving APIs • It makes sense to design clients and services so that they observe the robustness principle. Clients that use an older API should continue to work with the new version of the service • Sometimes, major and incompatible changes are made to an API. In this case clients can’t be forced to upgrade immediately; a service must support older versions of API for some period of time
Handling Partial Failure • In a distributed system there is the ever-present risk of partial failure • A service might be down or not be able to respond in a timely way to a client’s request • There are some strategies for dealing with partial failures: network timeouts, limiting the number of outstanding requests, Circuit breaker pattern, provide fallbacks
Handling Partial Failure - Strategies • Network timeouts - Never block indefinitely and always use timeouts when waiting for a response. Using timeouts ensures that resources are never tied up indefinitely • Limiting the number of outstanding requests – Impose an upper bound on the number of outstanding requests that a client can have with a particular service • Circuit breaker pattern –Track the number of successful and failed requests. If the error rate exceeds a configured threshold, trip the circuit breaker so that further attempts fail immediately • Provide fallbacks – Perform fallback logic when a request fails. For example, return cached data or a default value
IPCTechnologies • There are lots of different IPC technologies to choose from • Services can use synchronous request/response-based communication mechanisms such as HTTP-based REST • Alternatively, they can use asynchronous, message-based communication mechanisms such as AMQP • There are also a variety of different message formats. Human readable text-based formats such as JSON or XML vs. binary format such as Avro or Protocol Buffers
Async, Message-BasedCommunication • Processes communicate by asynchronously exchanging messages • A client makes a request to a service by sending it a message. If the service is expected to reply, it does so by sending a separate message back to the client • A message consists of headers (metadata such as the sender) and a message body • Messages are exchanged over channels. Any number of producers/consumers can send/receive any number of messages to/from a channel • There are two kinds of channels, point-to-point and publish-subscribe
Async, Message-BasedCommunication There are many messaging systems to choose from such RabbitMQ,Apache Kafka, Apache ActiveMQ, AMQP and STOMP etc Advantages • Decouples the client from the service - A client makes a request simply by sending a message to the appropriate channel • Message buffering - a message broker queues up the messages written to a channel until the consumer can process them • Flexible client-service interactions – Messaging supports all of the interaction styles described earlier • Explicit inter-process communication
Async, Message-BasedCommunication Drawbacks • Additional operational complexity –The messaging system is yet another system component that must be installed, configured, and operated • Complexity of implementing request/response-based interaction - Each request message must contain a reply channel identifier and a correlation identifier.The service writes a response message containing the correlation ID to the reply channel.The client uses the correlation ID to match the response with the request
Synchronous, Request/Response IPC • A client sends a request to a serviceThe service processes the request and sends back a response • In many clients, the thread that makes the request blocks while waiting for a response. Other clients might use asynchronous, event-driven client code that is perhaps encapsulated by Futures or Rx Observables • There are numerous protocols to choose from.Two popular protocols are REST and Thrift
Intro to Microservices Architecture Service Discovery
Why Use Service Discovery? • Let’s imagine that you are writing some code that invokes a service that has a REST API • In order to make a request, your code needs to know the network location of a service instance • Service instances have dynamically assigned network locations • the set of service instances changes dynamically because of autoscaling, failures, and upgrades • Consequently, your client code needs to use a more elaborate service discovery mechanism
The Client-Side Service Discovery Pattern • The client is responsible for determining the network locations of available service instances and load balancing requests across them • The client queries a service registry, which is a database of available service instances • The client then uses a load-balancing algorithm to select one of the available service instances and makes a request • This pattern is relatively straightforward.Also, since the client knows about the available services instances, it can make intelligent, application-specific load-balancing decisions such as using hashing consistently. • One significant drawback of this pattern is that it couples the client with the service registry
The Server-Side Service Discovery Pattern • The client makes a request to a service via a load balancer • The load balancer queries the service registry and routes each request to an available service instance • Service instances are registered and deregistered with the service registry • One great benefit of this pattern is that details of discovery are abstracted away from the client.This eliminates the need to implement discovery logic for each programming language and framework used by your service clients • Unless the load balancer is provided by the deployment environment, it is yet another highly available system component that you need to set up and manage
The Service Registry • The service registry is a key part of service discovery.The service registry is a key part of service discovery • A service registry needs to be highly available. It consists of a cluster of servers that use a replication protocol to maintain consistency • Netflix Eureka is good example of a service registry. It provides a REST API for registering and querying service instances • Other examples of service registries include: etcd, Consul, and Apache Zookeeper
Intro to Microservices Architecture Event-Driven Data Management
The Problem of Distributed Data Management • Data access becomes much more complex when we move to a microservices architecture • The data owned by each microservice is private to that microservice and can only be accessed via its API • Encapsulating the data ensures that the microservices are loosely coupled and can evolve independently of one another • Different microservices often use different kinds of databases
The Problem of Distributed Data Management • This approach has many benefits, including loosely coupled services and better performance and scalability. However, it does introduce some distributed data management challenges • The first challenge is how to implement business transactions that maintain consistency across multiple services • The second challenge is how to implement queries that retrieve data from multiple services
The Solution: Event-DrivenArchitecture • In this architecture, a microservice publishes an event when something notable happens, such as when it updates a business entity • Other microservices subscribe to those events When a microservice receives an event it can update its own business entities, which might lead to more events being published • You can use events to implement business transactions that span multiple services • A transaction consists of a series of steps. Each step consists of a microservice updating a business entity and publishing an event that triggers the next step
The Solution: Event-DrivenArchitecture • You can implement business transactions that span multiple services when: • The Message Broker guarantees that events are delivered at least once • Each service atomically updates the database and publishes an event • It is important to note that these are not ACID transactions.They offer much weaker guarantees such as eventual consistency • You can also use events to maintain materialized views that pre-join data owned by multiple microservices • The service that maintains the view subscribes to the relevant events and updates the view
Event-DrivenArchitecture Benefits & Drawbacks Benefits: • It enables the implementation of transactions that span multiple services and provide eventual consistency. • it also enables an application to maintain materialized views. Drawbacks: • the programming model is more complex than when using ACID transactions. • Often you must implement compensating transactions to recover from application-level failures • Subscribers must detect and ignore duplicate events
Event-DrivenArchitecture:AchievingAtomicity Publishing Events Using LocalTransactions • One way to achieve atomicity is for the application to publish events using a multi-step process involving only local transactions • The trick is to have an EVENT table, which functions as a message queue, in the database that stores the state of the business entities • The application begins a (local) database transaction, updates the state of the business entities, inserts an event into the EVENT table, and commits the transaction • A separate application thread or process queries the EVENT table, publishes the events to the Message Broker, and then uses a local transaction to mark the events as published
Event-DrivenArchitecture:AchievingAtomicity Publishing Events Using LocalTransactions Benefits • It guarantees an event is published for each update without relying on two phase commit • The application publishes business-level events, which eliminates the need to infer them Publishing Events Using LocalTransactions Drawbacks • It is potentially error-prone since the developer must remember to publish events. • A limitation of this approach is that it is challenging to implement when using some NoSQL databases because of their limited transaction and query capabilities.
Event-DrivenArchitecture:AchievingAtomicity Mining a DatabaseTransaction Log • Another way to achieve atomicity without 2PC is for the events to be published by a thread or process that mines the database’s transaction or commit log • TheTransaction Log Miner thread or process reads the transaction log and publishes events to the Message Broker • Examples of this approach is the open source LinkedIn Databus project & streams mechanism in AWS DynamoDB
Event-DrivenArchitecture:AchievingAtomicity Transactional Log Mining Benefits • It guarantees that an event is published for each update without using two phase commit • It can also simplify the application by separating event publishing from the application’s business logic Transactional Log Mining Drawbacks • The format of the transaction log is proprietary to each database and can even change between database versions • It can be difficult to reverse engineer the high-level business events from the low-level updates recorded in the transaction log
Event-DrivenArchitecture:AchievingAtomicity Event Sourcing • Achieves atomicity without two phase commit by using a radically different, event- centric approach to persisting business entities • Rather than store the current state of an entity, the application stores a sequence of state-changing events • The application reconstructs an entity’s current state by replaying the events • Whenever the state of business entity changes, a new event is appended to the list of events • Since saving an event is a single operation, it is inherently atomic
Event-DrivenArchitecture:AchievingAtomicity Event Sourcing Benefits • It solves one of the key problems in implementing an event-driven architecture and makes it possible to reliably publish events whenever state changes • It solves data consistency issues in a microservices architecture • provides a 100% reliable audit log of the changes made to a business entity • It makes your business logic consists of loosely coupled business entities that exchange events
Event-DrivenArchitecture:AchievingAtomicity Event Sourcing Drawbacks • It is a different and unfamiliar style of programming and so there is a learning curve • The event store only directly supports the lookup of business entities by primary key • You must use command query responsibility separation (CQRS) to implement queries.As a result, applications must handle eventually consistent data
References Microservices at Netflix Implementing Microservices Monolith to Microservices Microservices: From Design to Deployment Microservice.io How to Break a Monolith into Microservies

More Related Content

PPTX
The Overview of Microservices Architecture
byParia Heidari
 
PDF
Microservice Architecture
byRich Lee
 
PPTX
Microservices architecture
byAbid Khan
 
PDF
Microservices architecture
byMohammad Dameer
 
PDF
Architecture 2020 - eComputing 2019-07-01
byJorge Hidalgo
 
PPTX
Power of Microservices Architecture in Drupal Development
byOpenSense Labs
 
PPTX
Web Services and the Service-Oriented Architecture
byrbalderas
 
PDF
Microservices architecture
byAbdelghani Azri
 
The Overview of Microservices Architecture
byParia Heidari
 
Microservice Architecture
byRich Lee
 
Microservices architecture
byAbid Khan
 
Microservices architecture
byMohammad Dameer
 
Architecture 2020 - eComputing 2019-07-01
byJorge Hidalgo
 
Power of Microservices Architecture in Drupal Development
byOpenSense Labs
 
Web Services and the Service-Oriented Architecture
byrbalderas
 
Microservices architecture
byAbdelghani Azri
 

What's hot

PDF
Enterprise Integration in Cloud Native Microservices Architectures
byCrishantha Nanayakkara
 
PDF
Deep-dive into Microservice Outer Architecture
byWSO2
 
PPTX
Microservice architecture : Part 1
byNodeXperts
 
PDF
Microservices: Where do they fit within a rapidly evolving integration archit...
byKim Clark
 
PDF
Microservice Architecture
byNguyen Tung
 
PPTX
Micro-services architecture
byFarwa Ansari
 
PDF
Service mesh in Microservice World to Manage end to end service communications
bySatya Syam
 
PDF
[WSO2Con EU 2017] Creating Composite Services Using Ballerina
byWSO2
 
PDF
Microservices
byACCESS Health Digital
 
PDF
Microservices for Application Modernisation
byAjay Kumar Uppal
 
PPTX
Microservice architecture design principles
bySanjoy Kumar Roy
 
PPTX
Microservice vs. Monolithic Architecture
byPaul Mooney
 
PDF
Microservice architecture-api-gateway-considerations
byImam Uddin Ahamed - PRINCE2 ® , ITIL ®
 
PDF
Microservices for Enterprises
byKasun Indrasiri
 
PDF
[WSO2Con EU 2017] Microservices for Enterprises
byWSO2
 
PDF
Full lifecycle of a microservice
byLuigi Bennardis
 
PDF
Microservices in Practice
byKasun Indrasiri
 
PDF
DEVNET-1184 Microservices Patterns
byCisco DevNet
 
PPTX
Introduction to Microservices
byRoger van de Kimmenade
 
PDF
Microservices: an introduction
byDaniel Baptista Dias
 
Enterprise Integration in Cloud Native Microservices Architectures
byCrishantha Nanayakkara
 
Deep-dive into Microservice Outer Architecture
byWSO2
 
Microservice architecture : Part 1
byNodeXperts
 
Microservices: Where do they fit within a rapidly evolving integration archit...
byKim Clark
 
Microservice Architecture
byNguyen Tung
 
Micro-services architecture
byFarwa Ansari
 
Service mesh in Microservice World to Manage end to end service communications
bySatya Syam
 
[WSO2Con EU 2017] Creating Composite Services Using Ballerina
byWSO2
 
Microservices
byACCESS Health Digital
 
Microservices for Application Modernisation
byAjay Kumar Uppal
 
Microservice architecture design principles
bySanjoy Kumar Roy
 
Microservice vs. Monolithic Architecture
byPaul Mooney
 
Microservice architecture-api-gateway-considerations
byImam Uddin Ahamed - PRINCE2 ® , ITIL ®
 
Microservices for Enterprises
byKasun Indrasiri
 
[WSO2Con EU 2017] Microservices for Enterprises
byWSO2
 
Full lifecycle of a microservice
byLuigi Bennardis
 
Microservices in Practice
byKasun Indrasiri
 
DEVNET-1184 Microservices Patterns
byCisco DevNet
 
Introduction to Microservices
byRoger van de Kimmenade
 
Microservices: an introduction
byDaniel Baptista Dias
 

Similar to Intro to Microservices Architecture

PDF
Study Notes - Using an API Gateway
byRick Hwang
 
PDF
API Gateway How-To: The Many Ways to Apply the Gateway Pattern
byVMware Tanzu
 
PPTX
Api gateway : To be or not to be
byJaewoo Ahn
 
PDF
Api Gateway
byKhaqanAshraf
 
PDF
Backend for Frontend in Microservices
byIRJET Journal
 
PPTX
Microservices architecture
byFaren faren
 
PPTX
What is an API Gateway?
byLunchBadger
 
PDF
API’s and Micro Services 0.5
byRichard Hudson
 
PDF
Introduction to event based microservices
byGrigoris Grigoriadis
 
PDF
Bridging Microservices, APIs and Integration
byKasun Indrasiri
 
PDF
Microservices Interview Questions and Answers PDF By ScholarHat
byScholarhat
 
PPTX
02 api gateway
byJanani Velmurugan
 
PDF
3298 microservices and how they relate to esb api and messaging - inter con...
byKim Clark
 
PDF
[WSO2Con EU 2017] Microservice Architecture (MSA) and Integration Microservices
byWSO2
 
PDF
API Gateway report
byGleicon Moraes
 
PDF
#ATAGTR2020 Presentation - Microservices – Explored
byAgile Testing Alliance
 
PPTX
API Gateways are going through an identity crisis
byChristian Posta
 
PPTX
Micro Services
bySARADHIREDDYK
 
PPTX
Microservices: Breaking Apart the Monolith
byIron.io
 
PDF
OptiSol Microservices Architecture - Tech Meetup
byCareersOptiSol
 
Study Notes - Using an API Gateway
byRick Hwang
 
API Gateway How-To: The Many Ways to Apply the Gateway Pattern
byVMware Tanzu
 
Api gateway : To be or not to be
byJaewoo Ahn
 
Api Gateway
byKhaqanAshraf
 
Backend for Frontend in Microservices
byIRJET Journal
 
Microservices architecture
byFaren faren
 
What is an API Gateway?
byLunchBadger
 
API’s and Micro Services 0.5
byRichard Hudson
 
Introduction to event based microservices
byGrigoris Grigoriadis
 
Bridging Microservices, APIs and Integration
byKasun Indrasiri
 
Microservices Interview Questions and Answers PDF By ScholarHat
byScholarhat
 
02 api gateway
byJanani Velmurugan
 
3298 microservices and how they relate to esb api and messaging - inter con...
byKim Clark
 
[WSO2Con EU 2017] Microservice Architecture (MSA) and Integration Microservices
byWSO2
 
API Gateway report
byGleicon Moraes
 
#ATAGTR2020 Presentation - Microservices – Explored
byAgile Testing Alliance
 
API Gateways are going through an identity crisis
byChristian Posta
 
Micro Services
bySARADHIREDDYK
 
Microservices: Breaking Apart the Monolith
byIron.io
 
OptiSol Microservices Architecture - Tech Meetup
byCareersOptiSol
 

Recently uploaded

PDF
Getting started with Agent Framework.pdf
byNilesh Gule
 
PDF
ENTSO-E's Response to the European Commission Call for Evidence on the Strate...
byReynir Orn Bachmann Gudmundsson
 
PPSX
AppSec Role Based Training OWASP Global AppSec USA 2025-11-06
byRobert Grupe, CSSLP CISSP PE PMP
 
PDF
Transparency Exchange API: How Do You Find the SBOM for a Smart Light Bulb?
byPavel Shukhman
 
PDF
Writing GPU-Ready AI Models in Pure Java with Babylon
byAna-Maria Mihalceanu
 
PDF
Upskill to Agentic Automation - Working Smarter with AI: Real-World Tools for...
byDianaGray10
 
PPTX
Enhancing Web Security: Key Concepts & Strategies.pptx
byParham Abolghasemi
 
PPTX
GenAI GraphTalk - Kuala Lumpur - 4 Nov 2025
bygourisachdeva2
 
PDF
How to not make bugs (in JSC), and the future of 32-bits
byIgalia
 
PDF
Database Performance at Scale: The TL;DR
byScyllaDB
 
PDF
Configure and Secure SSH - RHCSA (RH124).pdf
byLinuxCert Guru
 
PDF
"Visual Guide to DSA: Big O Notation, Data Structures, and Algorithms Fundame...
byNusrat Gulbarga
 
PDF
Revolutionizing SQL Database Design for the Modern Era.pdf
bySQL DBM
 
PDF
AWS re:Invent 2025 Event Presentation Slides
byZilliz
 
PDF
Unveiling the Basics of Agentic AI - OSUG Mumbai
bythesubuiyer
 
PDF
Control Access to Files - RHCSA (RH124).pdf
byLinuxCert Guru
 
PDF
Unleash AI power with the Dell Pro 14 Plus - Interactive PDF
byPrincipled Technologies
 
PPTX
AI and Linux in 2025 - Jay LaCroix, Learn Linux TV
byAll Things Open
 
PDF
Exclusive Hands-On Workshop: Agentic Automation with UiPath (First Edition)
byanabulhac
 
PDF
Create, View and Edit Text Files - RHCSA (RH124).pdf
byLinuxCert Guru
 
Getting started with Agent Framework.pdf
byNilesh Gule
 
ENTSO-E's Response to the European Commission Call for Evidence on the Strate...
byReynir Orn Bachmann Gudmundsson
 
AppSec Role Based Training OWASP Global AppSec USA 2025-11-06
byRobert Grupe, CSSLP CISSP PE PMP
 
Transparency Exchange API: How Do You Find the SBOM for a Smart Light Bulb?
byPavel Shukhman
 
Writing GPU-Ready AI Models in Pure Java with Babylon
byAna-Maria Mihalceanu
 
Upskill to Agentic Automation - Working Smarter with AI: Real-World Tools for...
byDianaGray10
 
Enhancing Web Security: Key Concepts & Strategies.pptx
byParham Abolghasemi
 
GenAI GraphTalk - Kuala Lumpur - 4 Nov 2025
bygourisachdeva2
 
How to not make bugs (in JSC), and the future of 32-bits
byIgalia
 
Database Performance at Scale: The TL;DR
byScyllaDB
 
Configure and Secure SSH - RHCSA (RH124).pdf
byLinuxCert Guru
 
"Visual Guide to DSA: Big O Notation, Data Structures, and Algorithms Fundame...
byNusrat Gulbarga
 
Revolutionizing SQL Database Design for the Modern Era.pdf
bySQL DBM
 
AWS re:Invent 2025 Event Presentation Slides
byZilliz
 
Unveiling the Basics of Agentic AI - OSUG Mumbai
bythesubuiyer
 
Control Access to Files - RHCSA (RH124).pdf
byLinuxCert Guru
 
Unleash AI power with the Dell Pro 14 Plus - Interactive PDF
byPrincipled Technologies
 
AI and Linux in 2025 - Jay LaCroix, Learn Linux TV
byAll Things Open
 
Exclusive Hands-On Workshop: Agentic Automation with UiPath (First Edition)
byanabulhac
 
Create, View and Edit Text Files - RHCSA (RH124).pdf
byLinuxCert Guru
 

Intro to Microservices Architecture

  • 1.
  • 2.
    Table of Contents Introductionto Microservices Using API Gateway Inter-Process Communication Service Discovery Event-Driven Data Management References
  • 3.
  • 4.
    Building Monolithic Application •Applications written in this style are extremely common • These kinds of applications are simple to develop and test • Monolithic applications are also simple to deploy • You can also scale the application by running multiple copies behind a load balancer • In the early stages of the project it works well
  • 6.
    Building Monolithic Application •This simple approach has a huge limitation • After a few years, your small, simple application will have grown into a monstrous monolith • The sheer size of the application will also slow down development • Complex monolithic application is an obstacle to continuous deployment
  • 7.
    Building Monolithic Application •Monolithic applications can also be difficult to scale when different modules have conflicting resource requirements • Monolithic application can be unreliable. A bug in any module, can potentially bring down the entire process • Monolithic applications make it extremely difficult to adopt new frameworks and languages
  • 8.
    Microservices –Tackling theComplexity • Many organizations such as Amazon, eBay and Netflix have started to adopt the Microservices Architectural Pattern • The idea is to split your application into set of smaller, interconnected services • A service typically implements a set of distinct features or functionality, such as order management, customer management, etc • Each microservice is a mini-application that has its own business logic along with various adapters
  • 9.
    Microservices –Tackling theComplexity • Some microservices would expose an API that’s consumed by other microservices or by the application’s clients • At runtime, each instance is often a cloud virtual machine (VM) or a Docker container
  • 11.
    Microservices –Tackling theComplexity Benefits • It tackles the problem of complexity.The application has been broken up into manageable chunks or services • It enforces a level of modularity. Consequently, individual services are much faster to develop, and much easier to understand and maintain • This architecture enables each service to be developed independently by a team that is focused on that service. • It enables each microservice to be deployed independently • enables each service to be scaled independently
  • 12.
    Microservices –Tackling theComplexity Drawbacks • The complexity that arises from the fact that a microservices application is a distributed system • The partitioned DB architecture. In a microservices-based application, you need to update multiple databases owned by different services • The challenge to implement changes that span multiple services. • Testing a microservices application is also much more complex • Deploying a microservices-based application is also much more complex. Each service will have multiple runtime instancesThat’s many more moving parts that need to be configured, deployed, scaled, and monitored
  • 13.
  • 14.
    Client-Microservices Interaction When youchoose to build your application as a set of microservices, you need to decide how your application’s clients will interact with the microservices: • Direct Client-to-Microservices Communication • Using anAPI Gateway
  • 15.
    Direct Client-to-MicroservicesCommunication In theory,a client could make requests to each of the microservices directly. Unfortunately, there are challenges and limitations with this option: • Mismatch between the needs of the client and the fine-grained APIs exposed by each of the microservices • Some might use protocols that are not web-friendly likeThrift binary RPC and AMQP • It makes it difficult to refactor the microservices.We might want to merge two services or split a service into two or more services
  • 16.
    API Gateway • APIGateway comes to the rescue! It is a server that is the single-entry point into the system • The API Gateway encapsulates the internal system architecture and provides an API that is tailored to each client • It might have other responsibilities such as authentication, monitoring, load balancing, caching, and request management • The API Gateway is responsible for request routing, composition, and protocol translation. All requests from clients first go through the API Gateway. It then routes requests to the appropriate microservice
  • 18.
    API Gateway Benefits • Itencapsulates the internal structure of the application.Clients simply talk to the gateway, rather than having to invoke specific services • The API Gateway provides each kind of client with a specificAPI • It simplifies the client code Drawbacks • It is yet another highly available component that must be developed, deployed, and managed • It might become a development bottleneck.The gateway must be updated in order to expose each microservice's endpoint • Developers can be forced to wait in line in order to update the gateway
  • 19.
    Implementing an APIGateway Performance and Scalability • The performance and scalability of the API Gateway is usually very important • It makes sense, to build the API Gateway on a platform that supports asynchronous, non-blocking I/O • There are a variety of different technologies that can be used to implement a scalable API Gateway i.e. Netty,Vertx, Spring Reactor, Node.js etc
  • 20.
    Implementing an APIGateway Using a Reactive Programming Model • Sometimes, there are dependencies between requests. Authentication before routing a request to a BE service • WritingAPI composition code using the traditional asynchronous callback approach quickly leads you to callback hell • Better approach is to implement it in a declarative style using a reactive approach i.e. Future in Scala, CompletableFuture in Java8, Promise in JS, and Reactive Extensions (RxJava, RxJS)
  • 21.
    Implementing an APIGateway Service Invocation • It is a distributed system which must use an inter-process communication mechanism • There are two styles of inter-process communications: 1) Asynchronous, messaging-based mechanism. Message brokers vs. brokerless 2) Synchronous mechanism such as HTTP orThrift • A system will typically use both asynchronous and synchronous styles. It might even use multiple implementations of each style
  • 22.
    Implementing an APIGateway Service Discovery • The API Gateway needs to know the location (IP address and port) of each microservice with which it communicates • Application services have dynamically assigned locations. Also, the set of instances of a service changes dynamically because of autoscaling and upgrades • API Gateway, like any other service client in the system, needs to use the system’s service discovery mechanism: either server-side discovery or client-side discovery
  • 23.
    Implementing an APIGateway Handling Partial Failures • Another issue you have to address when implementing an API Gateway is the problem of partial failure • This issue arises in all distributed systems whenever one service calls another service that is either responding slowly or is unavailable • The API Gateway should never block indefinitely waiting for a downstream service However, how it handles the failure depends on the specific scenario and which service is failing
  • 24.
  • 25.
    Inter-Process Communication How theservices within the system communicate with one another? • In a monolithic application, components invoke one another via language-level method or function calls • In contrast, a microservices-based application is a distributed system running on multiple machines Each service instance is typically a process • Microservices user inter-process communication (IPC) to interact • Interaction Styles, Defining APIs, Evolving APIs, Handling Partial Failure, and IPC Technologies need to be considered before choosing any IPC method
  • 27.
    Interaction Styles When selectingan IPC mechanism for a service, it is useful to think first about how services interact • One-to-one – Each client request is processed by exactly one service instance • One-to-many – Each request is processed by multiple service instances • Synchronous –The client expects a timely response from the service and might even block while it waits • Asynchronous –The client doesn’t block while waiting for a response, and the response, if any, isn’t necessarily sent immediately
  • 28.
    One-to-One Interactions Synchronous • Request/response– A client makes a request to a service and waits for a response The client expects the response to arrive in a timely fashion Asynchronous • Notification (a.k.a. a one-way request) – A client sends a request to a service but no reply is expected or sent • Request/async response – A client sends a request to a service, which replies asynchronouslyThe client does not block while waiting and is designed with the assumption that the response might not arrive for a while
  • 29.
    One-to-Many Interactions Asynchronous • Publish/subscribe– A client publishes a notification message, which is consumed by zero or more interested services • Publish/async responses – A client publishes a request message, and then waits a certain amount of time for responses from interested services Each service typically uses a combination of these interaction styles. For some services, a single IPC mechanism is enough. Other services might need to use a combination of IPC mechanisms
  • 31.
    DefiningAPIs • A service’sAPI is a contract between the service and its clients • It is important to define a service’s API using interface definition language (IDL i.e. OpenAPI & Swagger) • The nature of the API definition depends on which IPC mechanism you are using • For messaging as an IPC, the API consists of the message channels and the message types • For HTTP as an IPC, the API consists of the URLs and the request and response formats
  • 32.
    Evolving APIs • Aservice’s API invariably changes over time • In a monolithic application it is usually straightforward to change the API and update all the callers • In a microservices-based application it is a lot more difficult • You usually cannot force all clients to upgrade in lockstep with the service • Probably both old and new versions of a service will be running simultaneously due to incremental deploy of new versions of a service
  • 33.
    Evolving APIs • Itmakes sense to design clients and services so that they observe the robustness principle. Clients that use an older API should continue to work with the new version of the service • Sometimes, major and incompatible changes are made to an API. In this case clients can’t be forced to upgrade immediately; a service must support older versions of API for some period of time
  • 34.
    Handling Partial Failure •In a distributed system there is the ever-present risk of partial failure • A service might be down or not be able to respond in a timely way to a client’s request • There are some strategies for dealing with partial failures: network timeouts, limiting the number of outstanding requests, Circuit breaker pattern, provide fallbacks
  • 35.
    Handling Partial Failure- Strategies • Network timeouts - Never block indefinitely and always use timeouts when waiting for a response. Using timeouts ensures that resources are never tied up indefinitely • Limiting the number of outstanding requests – Impose an upper bound on the number of outstanding requests that a client can have with a particular service • Circuit breaker pattern –Track the number of successful and failed requests. If the error rate exceeds a configured threshold, trip the circuit breaker so that further attempts fail immediately • Provide fallbacks – Perform fallback logic when a request fails. For example, return cached data or a default value
  • 36.
    IPCTechnologies • There arelots of different IPC technologies to choose from • Services can use synchronous request/response-based communication mechanisms such as HTTP-based REST • Alternatively, they can use asynchronous, message-based communication mechanisms such as AMQP • There are also a variety of different message formats. Human readable text-based formats such as JSON or XML vs. binary format such as Avro or Protocol Buffers
  • 37.
    Async, Message-BasedCommunication • Processescommunicate by asynchronously exchanging messages • A client makes a request to a service by sending it a message. If the service is expected to reply, it does so by sending a separate message back to the client • A message consists of headers (metadata such as the sender) and a message body • Messages are exchanged over channels. Any number of producers/consumers can send/receive any number of messages to/from a channel • There are two kinds of channels, point-to-point and publish-subscribe
  • 38.
    Async, Message-BasedCommunication There aremany messaging systems to choose from such RabbitMQ,Apache Kafka, Apache ActiveMQ, AMQP and STOMP etc Advantages • Decouples the client from the service - A client makes a request simply by sending a message to the appropriate channel • Message buffering - a message broker queues up the messages written to a channel until the consumer can process them • Flexible client-service interactions – Messaging supports all of the interaction styles described earlier • Explicit inter-process communication
  • 39.
    Async, Message-BasedCommunication Drawbacks • Additionaloperational complexity –The messaging system is yet another system component that must be installed, configured, and operated • Complexity of implementing request/response-based interaction - Each request message must contain a reply channel identifier and a correlation identifier.The service writes a response message containing the correlation ID to the reply channel.The client uses the correlation ID to match the response with the request
  • 40.
    Synchronous, Request/Response IPC •A client sends a request to a serviceThe service processes the request and sends back a response • In many clients, the thread that makes the request blocks while waiting for a response. Other clients might use asynchronous, event-driven client code that is perhaps encapsulated by Futures or Rx Observables • There are numerous protocols to choose from.Two popular protocols are REST and Thrift
  • 41.
  • 42.
    Why Use ServiceDiscovery? • Let’s imagine that you are writing some code that invokes a service that has a REST API • In order to make a request, your code needs to know the network location of a service instance • Service instances have dynamically assigned network locations • the set of service instances changes dynamically because of autoscaling, failures, and upgrades • Consequently, your client code needs to use a more elaborate service discovery mechanism
  • 44.
    The Client-Side ServiceDiscovery Pattern • The client is responsible for determining the network locations of available service instances and load balancing requests across them • The client queries a service registry, which is a database of available service instances • The client then uses a load-balancing algorithm to select one of the available service instances and makes a request • This pattern is relatively straightforward.Also, since the client knows about the available services instances, it can make intelligent, application-specific load-balancing decisions such as using hashing consistently. • One significant drawback of this pattern is that it couples the client with the service registry
  • 46.
    The Server-Side ServiceDiscovery Pattern • The client makes a request to a service via a load balancer • The load balancer queries the service registry and routes each request to an available service instance • Service instances are registered and deregistered with the service registry • One great benefit of this pattern is that details of discovery are abstracted away from the client.This eliminates the need to implement discovery logic for each programming language and framework used by your service clients • Unless the load balancer is provided by the deployment environment, it is yet another highly available system component that you need to set up and manage
  • 48.
    The Service Registry •The service registry is a key part of service discovery.The service registry is a key part of service discovery • A service registry needs to be highly available. It consists of a cluster of servers that use a replication protocol to maintain consistency • Netflix Eureka is good example of a service registry. It provides a REST API for registering and querying service instances • Other examples of service registries include: etcd, Consul, and Apache Zookeeper
  • 49.
  • 50.
    The Problem ofDistributed Data Management • Data access becomes much more complex when we move to a microservices architecture • The data owned by each microservice is private to that microservice and can only be accessed via its API • Encapsulating the data ensures that the microservices are loosely coupled and can evolve independently of one another • Different microservices often use different kinds of databases
  • 51.
    The Problem ofDistributed Data Management • This approach has many benefits, including loosely coupled services and better performance and scalability. However, it does introduce some distributed data management challenges • The first challenge is how to implement business transactions that maintain consistency across multiple services • The second challenge is how to implement queries that retrieve data from multiple services
  • 52.
    The Solution: Event-DrivenArchitecture •In this architecture, a microservice publishes an event when something notable happens, such as when it updates a business entity • Other microservices subscribe to those events When a microservice receives an event it can update its own business entities, which might lead to more events being published • You can use events to implement business transactions that span multiple services • A transaction consists of a series of steps. Each step consists of a microservice updating a business entity and publishing an event that triggers the next step
  • 53.
    The Solution: Event-DrivenArchitecture •You can implement business transactions that span multiple services when: • The Message Broker guarantees that events are delivered at least once • Each service atomically updates the database and publishes an event • It is important to note that these are not ACID transactions.They offer much weaker guarantees such as eventual consistency • You can also use events to maintain materialized views that pre-join data owned by multiple microservices • The service that maintains the view subscribes to the relevant events and updates the view
  • 54.
    Event-DrivenArchitecture Benefits &Drawbacks Benefits: • It enables the implementation of transactions that span multiple services and provide eventual consistency. • it also enables an application to maintain materialized views. Drawbacks: • the programming model is more complex than when using ACID transactions. • Often you must implement compensating transactions to recover from application-level failures • Subscribers must detect and ignore duplicate events
  • 55.
    Event-DrivenArchitecture:AchievingAtomicity Publishing Events UsingLocalTransactions • One way to achieve atomicity is for the application to publish events using a multi-step process involving only local transactions • The trick is to have an EVENT table, which functions as a message queue, in the database that stores the state of the business entities • The application begins a (local) database transaction, updates the state of the business entities, inserts an event into the EVENT table, and commits the transaction • A separate application thread or process queries the EVENT table, publishes the events to the Message Broker, and then uses a local transaction to mark the events as published
  • 57.
    Event-DrivenArchitecture:AchievingAtomicity Publishing Events UsingLocalTransactions Benefits • It guarantees an event is published for each update without relying on two phase commit • The application publishes business-level events, which eliminates the need to infer them Publishing Events Using LocalTransactions Drawbacks • It is potentially error-prone since the developer must remember to publish events. • A limitation of this approach is that it is challenging to implement when using some NoSQL databases because of their limited transaction and query capabilities.
  • 58.
    Event-DrivenArchitecture:AchievingAtomicity Mining a DatabaseTransactionLog • Another way to achieve atomicity without 2PC is for the events to be published by a thread or process that mines the database’s transaction or commit log • TheTransaction Log Miner thread or process reads the transaction log and publishes events to the Message Broker • Examples of this approach is the open source LinkedIn Databus project & streams mechanism in AWS DynamoDB
  • 59.
    Event-DrivenArchitecture:AchievingAtomicity Transactional Log MiningBenefits • It guarantees that an event is published for each update without using two phase commit • It can also simplify the application by separating event publishing from the application’s business logic Transactional Log Mining Drawbacks • The format of the transaction log is proprietary to each database and can even change between database versions • It can be difficult to reverse engineer the high-level business events from the low-level updates recorded in the transaction log
  • 60.
    Event-DrivenArchitecture:AchievingAtomicity Event Sourcing • Achievesatomicity without two phase commit by using a radically different, event- centric approach to persisting business entities • Rather than store the current state of an entity, the application stores a sequence of state-changing events • The application reconstructs an entity’s current state by replaying the events • Whenever the state of business entity changes, a new event is appended to the list of events • Since saving an event is a single operation, it is inherently atomic
  • 61.
    Event-DrivenArchitecture:AchievingAtomicity Event Sourcing Benefits •It solves one of the key problems in implementing an event-driven architecture and makes it possible to reliably publish events whenever state changes • It solves data consistency issues in a microservices architecture • provides a 100% reliable audit log of the changes made to a business entity • It makes your business logic consists of loosely coupled business entities that exchange events
  • 62.
    Event-DrivenArchitecture:AchievingAtomicity Event Sourcing Drawbacks •It is a different and unfamiliar style of programming and so there is a learning curve • The event store only directly supports the lookup of business entities by primary key • You must use command query responsibility separation (CQRS) to implement queries.As a result, applications must handle eventually consistent data
  • 63.
    References Microservices at Netflix ImplementingMicroservices Monolith to Microservices Microservices: From Design to Deployment Microservice.io How to Break a Monolith into Microservies

Editor's Notes

  • #13 Successfully deploying a microservices application requires greater control of deployment methods by developers and a high level of automation -> PaaS (platform as a service) come to the rescue with microservices deployment. One typical starting point is to use a clustering solution, such as Kubernetes, in conjunction with a container technology such as Docker. Kubernetes - open-source container-orchestration system for automating application deployment, scaling, and management. 
  • #17 For most microservices-based applications, it makes sense to implement an API Gateway, which acts as a single entry point into a system. The API Gateway is responsible for request routing, composition, and protocol translation. It provides each of the application’s clients with a custom API. The API Gateway can also mask failures in the backend services by returning cached or default data.