Microservices

Architecture
Introduction
 Get an introduction to the microservices architecture
and how it differs from the monolithic style of software
development.
 Microservices have emerged as the preferred approach
for complex business applications deployed at massive
scale.
 This architecture has increasingly been incorporated
into new applications for libraries.
Fundamental technology shift
 Mainframe computing
 Client/Server
 Cloud Computing

http://www.flickr.com/photos/carrick/619
52845/
http://soacloudcomputing.blogspot.com/2008/10/cloud-computing.html
http://www.javaworld.com/javaworld/jw-10-2001/jw-1019-jxta.html
Microservices
 Current prevailing approach for large scale globally
distributed applications
 Common choice for new development projects for
business software
 Many organizations are also evolving existing
monolithic applications to Microservices
What are microservices?
 A model of technical architecture
 Small independent functional applications
 Each microservices built on appropriate technical
components
 A software development pattern
 Decentralization of technical components
 Distributed programming / DevOps teams
 Responsibility to deploy, operate, and maintain services
From apps to systems
 Many microservices are assembled to create a complex
business application
 Separate independent components
 Brought together via middleware or API gateway
Software Development Styles
 Monolithic Applications
 Codebase of application deployed as a single bundle of
executables and libraries on a unified platform
 Microservices Architecture
 Multiple independent software components orchestrated to
form a unified application
 Common infrastructure:
 User interface toolkit
 API Gateway
 Persistence layer
Alternative approach: Monolithic
software
 Consolidated executable application
 Plus supporting libraries and modules
 Can be massively distributed across computing clusters
 Entire application based on a uniform technology stack:
 Server platform
 Operating system
 Programming language
 Database layer
 Enhancements mean recompilation of entire application
 Monolithic Application Conceptual Model
Scripts/
User Third Party Systems
Interfaces API endpoints

Web service

Presentation Layer

Application software
Business Logic
Run time libraries
Database Engine
Table Table Table Table Table Table Table Table
Table Table Table Table Table Table Table Table
Services-oriented Architecture (SOA)
 Longstanding approach to business application
development
 Monolithic application based on reusable services
 Complex applications rely on an enterprise service bus
to manage communications among services, database
connectivity, event triggers, etc
 Single uniform technology platform
 Code assembled into a monolithic package
 Scales to very high performance through clustered
deployment
SOA development issues
 Services are closely interrelated throughout the
application
 Developers must understand all aspects of the
application
 Single technology stack
 Small changes require full recompilation
 Complex applications can hit hardware or OS limits
 Centralized development pattern
 Operations separated from Development
 Monolithic Application: Enterprise SOA Model
Scripts/
User Third Party Systems
Interfaces API endpoints

Web service

Presentation Layer

Application software Business Logic

Reusable

} Composable
Services

Enterprise Service Bus

Database Engine
Table Table Table Table Table Table Table Table
Table Table Table Table Table Table Table Table
Difference between Monolithic and
SOA
Service-Oriented
Feature Monolithic Architecture
Monolithic Architecture
Single unit (but
Deployment Single unit
modular)
Modularity Poor Better modularization
Entire system scales Some flexibility, but
Scalability
together still constrained

Inter-Service Function calls (but

Function calls
Communication more structured)
Database Single database Shared database
Traditional web ERP systems with
Example
applications modular components
Building a microservice
 Small unit of functionality
 Complete and independent technology stack
 Separate data stores
 Synchronization with other services as needed through
persistence layers
 Invoked through API Request / Response
 Usually: REST, HTTP, JSON
 Self-contained components
 Inner workings not exposed externally
 Developers have free reign to select tech components
Microservice conceptual model

Request Response

REST / HTTPS

Web service

Service components

Microservice
Application
software
Run time libraries

Data Store
Assembling an application
 Each microservice performs a small limited task
 Not intended to be standalone applications
 Surrounded by specialized infrastructure
 Manage communications
 Orchestrate services into complex chains of tasks
 Load balancing
 API Gateway
 User Interface layer
 Externally exposed APIs
 Multiple instances of any microservice launched as needed
 Microservices-based Application
Scripts/
User Third Party Systems
Interfaces API endpoints

Presentation Layer / UI Toolkit

API Gateway

Web service

Service
components
Web service Web service
Web service

Service Service Web service

components Service components Microservice
components
Service
components
Web service Application
Web service Web service
Microservice Microservice Web service
Microservice Web service Service software
Service Service components
components components Service Microservice
Application Service Application components
Application components Run time libraries

software software Application

software Microservice
Microservice Microservice
Microservice software
Run time libraries Microservice Run time libraries
Run time libraries Application
Application Application Data Store
Application Run time libraries
Application software
software software
software
software
Data Store Data Store Run time libraries
Run time libraries Run time libraries Data Store
Run time libraries
Run time libraries Data Store

Data Store
Data Store Data Store
Data Store
Data Store

Persistence / System
Layer
Microservice Architecture step by
step…
 1. User Interfaces (Top Layer)
• Represents the frontend applications or user interfaces (UIs).
• Could be web applications, mobile apps, or desktop
applications.
• These interfaces send requests to the system via an API
Gateway.

 2. Presentation Layer / UI Toolkit

• This layer is responsible for handling the user experience.
• It interacts with the API Gateway to fetch data from microservices.
• Provides a consistent UI design and may include frontend
frameworks like React, Angular, or Vue.js.
Microservice Architecture step by
step…
 3. API Gateway
• Acts as a central entry point for all client requests.
• Routes requests to the appropriate microservice.
• Handles authentication, load balancing, rate
limiting, and logging.
• Improves security by hiding internal microservices
from direct exposure.
• Example tools: Kong, NGINX, AWS API Gateway.
Microservice Architecture step by
step…
 4. Microservices (Middle Layer)
 Each microservice is independent, handling a specific business
function. Key characteristics:
• Encapsulates business logic and provides a RESTful API.
• Communicates via HTTP (REST) or messaging (Kafka,
RabbitMQ).
• Has its own database for better scalability and independence.
 Each microservice contains:
1. Web Service Component: Handles API requests.
2. Application Software: Implements business logic.
3. Run-Time Libraries: Supports execution.
4. Data Store: Stores data specific to that microservice.
Microservice Architecture step by
step…

 5. Persistence/System Layer (Bottom Layer)

• Represents the databases used by different microservices.
• Each microservice has its own dedicated database to
prevent tight coupling.
• Ensures data consistency and isolation.
• Can include SQL (PostgreSQL, MySQL) or NoSQL
(MongoDB, Redis) databases.
Microservice Architecture step by
step…
 6. Third-Party Integrations & Scripts
• External systems interact with microservices through API
endpoints.
• Used for data exchange, external services (e.g., payment
gateways, analytics tools), and automation scripts.
Microservice Architecture step by
step…
 Step-by-Step Request Flow
1. A user interacts with the UI (e.g., placing an order).
2. The UI sends a request to the API Gateway.
3. The API Gateway routes the request to the relevant microservice.
4. The microservice processes the request using:
1. Business logic.
2. Data store interaction.

5. If needed, the microservice may communicate with another microservice.

6. Once processed, the response is sent back to the UI via the API
Gateway.
7. The user sees the result (e.g., "Order Placed Successfully").
Microservice Architecture step by
step…

 Key Benefits of This Architecture

 ✅ Scalability – Each microservice scales independently.
✅ Resilience – Failure in one microservice does not impact
others.
✅ Flexibility – Different services can use different tech stacks.
✅ Faster Development – Teams work independently on
different services.
 This architecture is ideal for large-scale applications like e-
commerce platforms, banking systems, and SaaS
applications.
Beyond Virtual Machines to
Containers
 Virtual machines are a common technology for
optimizing use of computing hardware
 Most applications use a small portion of computing and
storage capacity
 VM managers enable multiple instances of operating
environments to co-exist on each physical server
Virtual Machine Environment
 Multiple Virtual Machines can
VM-1 VM-2 VM-3 VM-4 share a single physical server
 VMs allocated via a Virtual
Apps Apps Apps Apps Machine Monitor or Hypervisor
Code Code Code Code
 Each VM contains its own
librari
es
librari
es
librari
es
librari
es operating system, code
Gues Gues Gues Gues
libraries, applications, web
t OS t OS t OS t OS
services, and other
Virtual Machine Monitor
components
Host operating system
 Each VM independent: can
host any OS, libraries, apps
Server Hardware
Containers
 Server hardware provides OS Kernel to any
container
 Code libraries and binaries, memory, disk
m m m m m m m m storage, and other resources residing on the
i i i i i i i i server can be provisioned to any container
c c c c c c c c
r r r r r r r r  Containers can be rapidly deployed based
o o o o o o o o
s s s s s s s s
on pre-defined configuration sets
e e e e e e e e  Containers require fewer resources: do not
r r r r r r r r
v v v v v v v v run an entire copy of OS and support
i i i i i i i i services
c c c c c c c c
e e e e e e e e  Containers can differ or replicate
Binaries / Libraries set A Bins / Libs B  High demand microservices may require many
Container Engine (eg: Docker) instances
 Containers share resources but are
Host operating system designed to be rigidly independent
 Container engine ensures against resource
Server Hardware collisions
API Gateway
 Requests to microservices usually not made directly from external
agents
 Need a layer to manage access to Microservices to enable flexible
deployment
 Multiple microservices may be required to perform a complex task
 Usually many instances of each microservice
 API Gateways provide a single entry point for all requests into the
application.
 Developers do not need to know physical address of each service
(nothing should be hardwired)
 Manage authentication, protocol conversions, communications, routing,
load balancing
DevOps
 Merges development with operations
 A single team takes responsibility for development,
deployment, operations, and maintenance of a
microservice
 Make independent technology decisions
 Programming language
 Databases
 (probably limited to contain technical overhead for the
organization)
 No need to understand all aspects of the application
Contracts
 Any given microservice will not necessarily be aware of all
the ways in which it is consumed
 Microservices must be persistent to avoid failures in the
broader application / ecosystem
 Agreement to provide specific requests/responses
 Versioning is an essential characteristic
 Any deprecation must be (technically) negotiated and
propagated through the microservice ecosystem
 Functionality cannot be withdrawn until it is no longer
required
Docker
 Leading technical environment for the management of
containers
 Supported in most infrastructure environments
 Amazon Web Services
Containers
 Allocate computing resources in even smaller
increments than Virtual Machines
 Share low-level components
 Self-contained pre-configured operating environment
 Container management environments provide fast and
easy approach to deploy microservices or other
computing components
 Used in all types of computing environments, but
especially well suited to microservices.
Container orchestration
 In a complex environment tools are needed to manage
the deployment of containers
 Components need to be allocated and deallocated
dynamically based on load and demand
 Examples:
 Docker Swarm
 Kubernentes (developed by Google)
 Apache Mesos
Benefits of Microservices
 Rapid development
 Quick path to MVP (minimal viable product)
 Distributed teams
 Modularity
 Scalability
Evolving from the Monolith to
Microservices
 Many organizations eventually press the limits of
applications built with SOA monolithic style
 Gradually offload selected tasks to microservices
 Full-fledged migration to microservices can be long and
expensive
State of the Art
 Business environments based on monolithic style
remain viable
 Trend to base new large-scale web applications on
microservices
 Well accepted, modern approach among tech giants
 A technical style that supports a level of scale not
previously possible
 Beginning to gain acceptance for mid-scale
development projects.