Discusses Micro Services Architecture concepts in detail.

1. Cloud Native Computing
-Webinar Series-

3. “Cloud native computing uses an open source software stack to deploy applications
as microservices, packaging each part into its own container, and dynamically
orchestrating those containers to optimize resource utilization. Cloud native
technologies enable software developers to build great products faster”
- Clod Native Computing Foundation
What is Cloud Native Computing?
❖ Promotes Opensource
❖ Micro Services Architecture
❖ Containers and container orchestration tools
❖ Agility

4. “Cloud computing is shared pools of configurable computer system resources and
higher-level services that can be rapidly provisioned with minimal management effort,
often over the Internet. Cloud computing relies on sharing of resources to achieve
coherence and economies of scale, similar to a public utility”
- Wikipedia
What is Cloud Computing?
❖ On demand computing over internet
❖ Minimal management effort
❖ Cost efficiency through economies of scale

5. “Serverless computing is a cloud-computing execution model in which the cloud
provider acts as the server, dynamically managing the allocation of machine resources.
Pricing is based on the actual amount of resources consumed by an application, rather
than on pre-purchased units of capacity”
“Application designs that incorporate third-party “Backend as a Service” (BaaS)
services, and/or that include custom code run in managed, ephemeral containers on a
“Functions as a Service” (FaaS) platform. ”
What is Serverless Computing?
AWS Lamda
API Gateway
S3
Dynamo DB
RDS
❖ Reduced operational cost
❖ Reduced complexity
❖ Reduced engineering lead time

6. Part I - Micro Services
Presented by Linjith K Kunnon
13th Jan 2019

7. Part I – Micro Services
Overview
Monolithic Architecture
Service Oriented Architecture (SOA)
Micro Service Architecture
SOA Evolution
Micro Service Architecture Pros & Cons
Designing Micro Services
Breaking the domain
Micro Service Chassis Pattern
Communication Style & API Design
Event Driven Architecture
Micro Service Architecture Variations
Securing Micro Services
JSON Web Token
oAuth2
OpenID Connect
Identity Servers
Coordinating Micro Services
Service Discovery
API Gateway
Fault Tolerance
Monitoring Micro Services
Log Aggregation
Distributed Tracing
Application Metrics
Running Micro Services
Containerization
Configuration Management
Continuous Delivery

8. Overview
Monolithic Architecture
Service Oriented Architecture (SOA)
Micro Service Architecture
SOA Evolution
Micro Service Architecture Pros & Cons

9. Monolith Semi Mononlith Classic SOA
Fine grained SOA
(Micro Service)
Function as a service
(Serverless)
“Microservices are a software development technique—a variant of the service-
oriented architecture (SOA), an architectural style that structures an application as a
collection of loosely coupled services. In a microservices architecture, services are fine-
grained and the protocols are lightweight. The benefit of decomposing an application
into different smaller services is that it improves modularity”
-Wikipedia
What are Micro Services?

10. Monolithic Architecture
A monolithic application is self-contained, and independent. It is designed without modularity making it
not possible to repair or replace parts of the application without requiring complete replacement.
❖ Less Operational Overhead.
❖ Architectural simplicity.
❖ Too large and complex to fully understand and make changes fast and correctly.
❖ The size of the application can slow down the start-up time.
❖ Redeploy the entire application on each update.
❖ Impact of a change is usually not very well understood which leads to do extensive
manual testing.
❖ Continuous deployment is difficult.
❖ Difficult to scale when different modules have conflicting resource requirements.
❖ Less reliable. Bug in any module (e.g. memory leak) can potentially bring down the entire
process.
❖ Barrier to adopt new technologies.
User Interface
Business Logic
DB

11. Service Oriented Architecture
Service D Service E Service F
Service CService BService A
UIUI
Enterprise Service Bus
DB
User Interface
Web ServiceWeb Service
API Consumer
A service-oriented architecture (SOA) is a style of software design where services are provided to the other
components by application components, through a communication protocol over a network.
❖ Service Reusability
❖ Easy Maintenance
❖ Greater Reliability
❖ Platform Independence

12. Micro Service Architecture
A microservice is a software development technique—a variant of the service-oriented architecture (SOA). An
architecture style to build application as a collection of loosely coupled services
The fallacies of distributed computing
❖ The network is reliable.
❖ Latency is zero.
❖ Bandwidth is infinite.
❖ The network is secure.
❖ Topology doesn't change.
❖ There is one administrator.
❖ Transport cost is zero.
❖ The network is homogeneous. Classic SOA Micro Service

13. Yet another buzzword?
❖ Service Oriented Architecture has been there for a while. Micro Service is fine grained SOA – a natural
progression.
❖ Infrastructure revolution – containerization, elastic cloud & cloud native applications.
❖ Modern applications supports wide variety of digital devices like Mobile phones, PDA etc. Fine grained SOA is a
mandate for building such systems.
❖ What really new about Micro Services are the tools and techniques. Played a vital role in transforming IT
towards a DevOps-based culture.
❖ Emergence of public cloud and fully managed services.
❖ Business competency - Micro Service Architectural style helps deliver business capabilities faster and with
greater confidence.
❖ Agile methodology based development.

14. Micro Service Architecture Benefits
Agility
Fine-grained Scaling
Technology Independence
Parallel Development
Better Fault Isolation
Easier to Refactor
Easy to Understand
Faster Developer Onboarding

15. Micro Service Architecture Challenges
Operational Complexity
Performance Hit Due to Network Latency
Increased Configuration Management
Unsafe Communication Medium
Harder to Troubleshoot
Architectural Complexity
Higher Costs
Duplication of Developer Effort

16. Designing
Micro
Services
Breaking the domain
Micro Service Chassis Pattern
Communication Style & API Design
Event Driven Architecture
Micro Service Architecture Variations

17. Domain Driven Design (DDD) is about designing software based on models of the underlying domain. A model acts
as a Ubiquitous Language to help communication between software developers and domain experts.
Breaking the domain using DDD
❖ Ubiquitous Language – A common language between developers and the business.
❖ Bounded Context – The setting in which a word or statement appears that determines its meaning.
❖ Domain Entity – A domain object means something to the business, defined primarily by its identity.
❖ Value Object – Defined primarily by its attributes and is immutable.
❖ Aggregate Root – A group of entities and value objects that needs to be consistent while persisting.
❖ Core Subdomain - The core domain is so critical and fundamental to the business that it gives you a competitive
advantage and is a foundational concept behind the business.
❖ Supporting Subdomain - Help perform ancillary or supporting functions related directly to what the business
does. In these cases, high-quality code and perfectly designed structure are not necessary.
❖ Generic Subdomain - In general, these types of pieces can be purchased from a vendor and then wrapped in
such a way to communicate with the rest of the enterprise as necessary (Anti-corruption layer)

18. Breaking the domain using DDD
❖ Always decompose to Bounded Contexts
❖ Don’t go further, unless you have to
❖ Buy/adopt generic subdomains
❖ Core subdomain – don’t rush
❖ Evaluate consistency requirements
❖ Evaluate reasons for change
❖ Don’t expect the ideal model. Expect many iterations.
❖ Do not over engineer.
Courtesy: Martin Fowler

19. Micro Service Chassis Pattern
When you start the development of an application you often spend a significant amount of time putting
in place the mechanisms to handle cross-cutting concerns. Examples of cross-cutting concern includes
❖ Externalized configuration
❖ Logging
❖ Health checks
❖ Distributed tracing
❖ Boilerplate code for integrations with message broker, db etc.
Microservice Template
Web
DTO
Service
Domain
REST Client
Repository
Microservice Template
Interface
REST Endpoint
Implementation
REST Interface
REST Client
Microservice Template
Web
Domain

20. API design is important in a microservices architecture - all data exchange between services happens either through
messages or API calls.
❖ An API is a contract between a service and clients or consumers of that service. If an API changes, there is a risk of
breaking clients that depend on the API.
❖ REST over HTTP using JSON is a common choice for API interface.
❖ Consider using an Interface definition language (IDL) for designing API contracts. Latest standard is Open API.
❖ APIs should not leak internal implementation. It should change only when new functionality is added.
❖ Consider using the Backends for Frontends pattern to create separate backends for each client.
❖ For operations with side effects, consider making them idempotent and implementing them as PUT methods.
❖ Return proper http status codes.
❖ Consistent error handling. Create custom envelop for communicating errors.
API Design

21. Communication Style
❖ Synchronous protocol. HTTP is a synchronous protocol. The client sends a request and waits for a response from the
service. Client code can only continue its task when it receives the HTTP server response. Usually follow REST
architectural style.
Micro Service
A
Micro Service
B
Sync Request
Sync Response
Micro Service
C
❖ Asynchronous protocol. Protocol like AMQP use asynchronous messages. The client code or
message sender usually does not wait for a response. Follows Smart endpoints and dumb
pipes pattern.
Micro Service
A
Micro Service
B
Micro Service
C
Sync Request
Sync Response
Queue Queue
Service E
Service H
Service A
Service F
Service G
Service B
Service C
Service D

22. ❖ Event Notification
❖ Event Carried State Transfer
❖ Event Sourcing
❖ CQRS – Command Query Responsibility Segregation
Event Driven Architecture
Micro Service
A
Micro Service
B
Micro Service
C
Sync Request
Sync Response
Queue
Order.created
Order.created
Order.created
User Interface
Read Model
Write Model
Validation
Commands
Domain Logic
Data Persistance
Queries
(Generate
DTOs)
Domain Model
(Shopping cart aggregate)
Command
Handler
User Interface
Item a removed
Item c added
Item a added
...
Event Store
Query Event
CQRS Pattern
Event Sourcing Pattern
Event Notification
Availability over consistency

23. Shared Database & Database Per Service
Micro Service
A
DB
Micro Service
B
Micro Service
C
Micro Service
D
API Gateway
Micro Service
A
DB
Micro Service
B
Micro Service
C
Micro Service
D
DB DB
API Gateway
❖ Data needs to be encapsulated with the business logic that
operates on the data.
❖ Data access only via a published service interface.
❖ No direct database access is allowed from outside the service.
❖ No data sharing among the service
❖ Enables polyglot persistence
❖ Business transactions may need to query data that is owned by multiple services.
❖ Aggregating data that is owned by multiple services.
❖ A single database is much simpler to operate.
❖ Creates development time & run time coupling
❖ Widely Considered as anti-pattern. Shared Database
Database per service

24. ❖ Domain services and business process are not directly
exposed to internet facing users.
❖ Web & Mobile applications talks to Digital Experience APIs
❖ Data transformation specific to user experience.
❖ Domain API abstraction
Layered Micro Services & API Composition
Domain
APIs
Domain
APIs
Domain
APIsDomain
APIs
Domain
APIs
Domain
APIs
Domain
APIs
Digital
Experience
APIs
Digital
Experience
APIs
Digital
Experience
APIs
Digital
Experience
APIs
Digital
Experience
APIs
Digital
Experience
APIs
Digital
Experience
APIs
Digital
Experience
APIs
Digital
Experience
APIs
Digital
Experience
APIs
Digital
Experience
APIs
Digital
Experience
APIs
User Experience Layer
(Portal)
Digital Experience
API
Domain APIs & Business
Process
Data Assets
❖ Simple way to query data in a micro service architecture
❖ Restrict direct access to database.
❖ Aggregate data in higher order micro service.
❖ Prepare for possible performance issue due to network
latency.
Micro Service
A
Higher Order
Micro Service
Micro Service
B
Aggregator
Consumer
Request
Response

25. Coordinating
Micro
Services
Service Discovery
API Gateway
Fault Tolerance

26. Semi Monolith vs Micro Service
API Gateway
Discovery
Server
UI Server
Serves Static Assets
Micro Services
InfrastructureServices
Monitoring
Api Health
Dashboard
Performance
Monitoring
Log
Aggregation
& Analysis
Container
Dashboard
Configuration
Server
Messaging
Middleware
Identity
Server
External Systems
Distributed
Cache
Data Stores
Web ServiceUI Server
Serves Static Assets
DB
Semi-Monolith Micro Services

27. Semi-Monolith
VPC NAT gateway
VPC NAT gateway
Public Subnet-10.0.1.0/24
Public Subnet - 10.0.0.0/24 Private Subnet-10.0.2.0/24
Private Subnet-10.0.3.0/24
sgDataLayersgPublic sgWebLayer
vpc-demo:us-east-1 -10.0.0.0/16
us-east-1a
us-east-1b
us-east-1a-public
us-east-1b-public
us-east-1a-private
us-east-1b-private
Web Server
Web Server
DB-MasterAmazon S3

28. Micro Service
VPC NAT gateway
VPC NAT gateway
Public Subnet-10.0.1.0/24
Public Subnet - 10.0.0.0/24 Private Subnet-10.0.2.0/24
Private Subnet-10.0.3.0/24
sgDataLayersgPublic sgWebLayer
vpc-demo:us-east-1 -10.0.0.0/16
us-east-1a
us-east-1b
us-east-1a-public
us-east-1b-public
us-east-1a-private
us-east-1b-private
DB-MasterDB-MasterDB-MasterDB-MasterDB-MasterAmazon S3

29. Micro service instances changes dynamically and they have dynamically assigned network locations. Service
discovery mechanism address this issue.
❖ service provider registers itself with service registry when it enters and deregister itself when it leaves the system
❖ service consumer gets the location of a provider from registry, and then talks to the provider
❖ service registry maintains the latest location of providers
Service Discovery
Service
B
Service
C
Service
A
Service Registry
Registry
Client
Registry
Client
Registry
Client
Registry
Aware HTTP
Client
Service
B
Service
C
Service Registry
Registry
Client
Registry
Client
HTTP
Client
Service
A
Registry
Client
Load Balancer
Client side service discovery Server side service discovery

30. API Gateway
Service C
Service A
Service B
Service E
Service D
External API
Consumers
API
Gateway
An API gateway sits between clients and micro services. It acts as a reverse proxy, routing requests
from clients to services.
❖ Single URL and consistent interface.
❖ Reduces the coupling between client and backend.
❖ Act as aggregator.
❖ Exposes client-friendly protocol such as HTTP or WebSocket.
❖ SSL termination
❖ Authentication
❖ IP whitelisting
❖ Client rate limiting (throttling)
❖ Logging and monitoring
❖ Response caching

31. Fault Tolerance
❖ The Circuit Breaker pattern can prevent an application from repeatedly trying to execute an operation that's
likely to fail. It allows services to recover and limit cascading failures across multiple systems.
Failure threshold
reached
Operation
Success
Delay
(timeout)
Operation
Failed
Open Half Open
Closed❖ Closed state - Allowed to make remote calls when in closed state.
This state implies that the service is up and running. If the number
of error responses from the needed service passes a certain
threshold limit, the circuit is tripped.
❖ Open state – Remote calls are not made in this state. Circuit
breaker triggers the fallback method if defined. After a preset delay,
the circuit will be in half-open state.
❖ Half Open State – On time out, the circuit breaker allows remote
service calls. If request fails, the circuit will go to the open stage.
Otherwise the circuit will go to the closed stage.

32. Service Mesh
Service B
Proxy
Service C
Proxy
Service A
Proxy
Control Plane
Pilot Mixer Citadel
❖ The data plane is composed of a set of intelligent proxies
deployed as sidecars. These proxies mediate and control all
network communication between microservices.
❖ The control plane manages and configures the proxies to route
traffic, enforce policies and collect telemetry.
Istio Service MeshConsul Connect
A configurable infrastructure layer for a microservices application. It makes communication between service
instances flexible, reliable, and fast. It provides service discovery, load balancing, encryption, authentication
and authorization, support for the circuit breaker pattern, and other capabilities.

33. Running
Micro
Services
Containerization
Configuration Management
Continuous Delivery

34. Containerization using docker
❖ A platform for developers and sysadmins to develop, deploy, and run applications with containers.
❖ Image: An image is an executable package that includes everything needed to run an application -the code, a
runtime, libraries, environment variables, and configuration files.
❖ Container: A container is a runtime instance of an image.
Infrastructure
Host Operating System
Docker Engine
Container Container Container
Bins/Libs
App B
Bins/Libs
App C
Bins/Libs
App A
Infrastructure
Hypervisor
VM VM VM
Bins/Libs
App B
Bins/Libs
App C
Bins/Libs
App A
Guest OS Guest OS Guest OS
❖ Environment Standardization
❖ Isolation
❖ Light weight
❖ Portable
❖ Application Centric

35. Configuration Management
Separating configuration from application code is an important discipline in cloud-native development. This helps the
containerized application to run in multiple environments without modification.
Micro Service
B
Configuration
Server
Micro Service
A
Micro Service
C
Configuration
Store
❖ Share configurations with other services
❖ Centralized management
❖ Containerized apps once tested doesn’t require modifications.
❖ Easier administration

36. ❖ Low risk releases.
❖ Faster time to market.
❖ Higher quality.
❖ Lower costs.
❖ Better products.
Continuous Delivery
Develop
Build
TestDeploy
Release
Ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into
production, or into the hands of users, safely and quickly in a sustainable way.

37. Monitoring
Micro
Services
Log Aggregation
Distributed Tracing
Application Metrics

38. Log Aggregation
Application must emit telemetry events. Categorize them into metrics and text-based logs.
ELK for Log Aggregation
❖ Logstash - Collects log events from multiple types of sources using input plug-ins, transform using filter and
codec plug-ins and send them to a number of destinations using output plug-ins.
❖ Elasticsearch - Elasticsearch is a distributed and scalable full-text search database. It Allows to store and search
large volumes of log events.
❖ Kibana – Used for visualizing and analyzing logs stored in Elasticsearch.

39. Distributed Tracing
Gateway Service A
Service B
Service C
1
2
3
5
6
7
9
8
4
❖ Difficult to understand the flow of events across services.
❖ A single operation or transaction may involve calls to multiple services.
❖ To reconstruct the entire sequence of steps, each service should propagate a correlation ID that acts as a unique
identifier for that operation.
❖ The correlation ID enables distributed tracing across services.
❖ Helps troubleshoot latency problems in microservice architectures.

40. ❖ Key metrics are identified and monitored at the host, infrastructure, and microservice levels.
❖ Host and infrastructure key metrics: CPU, RAM, Threads, File descriptors, Database connections etc.
❖ Microservice key metrics – Availability, SLA, Latency, Errors & Exception etc.
❖ Appropriate logging that accurately reflects the past states of the microservice.
❖ Easy to interpret dashboard which contains key metrics.
❖ Actional alerts and are defined by signal-providing thresholds.
Application Metrics

41. Securing
Micro
Services
JSON Web Token
oAuth2
OpenID Connect
Identity Servers

42. JSON Web Token (JWT)
❖ Defines a compact and self-contained way for securely transmitting
information between parties as a JSON object.
❖ Information can be verified and trusted for digital signed tokens.
❖ JWTs can be encrypted to also provide secrecy between parties .
JSON Web Tokens are an open, industry standard method for representing claims securely between two parties.

43. OAuth 2
OAuth 2 Roles
❖ Resource Owner - The resource owner is the user who authorizes an application to access their account
❖ Client - The client is the application that wants to access the user's account.
❖ Resource Server - The resource server hosts the protected resources.
❖ Authorization Server - Authorization server verifies the identity of the user then issues access tokens.
OAuth 2 Tokens
❖ Access Token - The Access Token is a credential that can be used by an application to access an API.
❖ Refresh Token - Token that can be used to obtain a renewed access token.
Client
Resource Owner
Authorization Server
Identity
Server
Resource Server
Micro
Service
The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either
on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service,
or by allowing the third-party application to obtain access on its own behalf.

44. OAuth 2 Protocol Flows
Client Resource Owner
Authorization Server
Identity
Server
Resource Server
Micro
Service
Authorization Request
Authorization Grant
Authorization Grant
Access Token
Access Token
Protected Resource
❖ Authorization Code: used with server-side Applications. This is a
redirection-based flow, which means that the application must
be capable of interacting with the user-agent (i.e. the user's web
browser) and receiving API authorization codes that are routed
through the user-agent.
❖ Implicit: used with Mobile Apps or Web Applications
(applications that run on the user's device)
❖ Resource Owner Password Credentials: used with trusted
Applications, such as those owned by the service itself
❖ Client Credentials: used with Applications API access

45. ❖ OpenID Connect is a simple identity layer on top of the OAuth 2.0 protocol.
❖ Allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization
Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
❖ While OAuth 2.0 is about resource access and sharing, OIDC is all about user authentication.
❖ Its purpose is to give you one login for multiple sites. Each time you need to log in to a website using OIDC, you are
redirected to your OpenID site where you login, and then taken back to the website.
❖ ID Token – A JSON Web Token (JWT) that contains identity data. It is consumed by the application and used to get
user information like the user's name, email, and so forth, typically used for UI display.
Open Id Connect

46. Login Flow
Micro Service
Okta
Identiy Server
User Web Client
User Authorization Flow (Authorization Code Grant Flow)
Enter login credentials
Exchange authorization code
for access token
authorize user
access token + refresh token
GET/ Pipeline
(access_token)
Pipeline Response
opt
token expired
POST/token
(grant_type=refresh_token,
refresh_token)
access token + refresh token
Render dashboard
validate refresh token
Authorization Code Request
client_id, client_secret, redirect_url
response_type = code
Authorization code
authorize user

47. Reference Architecture

48. Reference Architecture
Micro Front Ends
Micro Services Platform
Business Micro Services
Supporting Services
UI App UI App UI AppUI App UI App
Generic Services
Platform Core Components
Core Services
UI App
Persistence Layer
Micro Service Data Stores
IntegrationGateway
MicroServicesObservability
API Gateway
Data lake
UI Framework
Persistence Layer
Platform Components
Business Micro
Services
Micro Front Ends
Third-party Service
Providers
Discovery Configuration
Message
Broker
Identity
Server
Distributed
Cache

49. Reference Architecture
API Gateway
Discovery
Server
UI Server
Serves Static Assets
Micro Services
InfrastructureServices
Monitoring
Api Health
Dashboard
Performance
Monitoring
Log
Aggregation
& Analysis
Container
Dashboard
Configuration
Server
Messaging
Middleware
Identity
Server
External API
Consumers
Distributed
Cache
Data Stores
IntegrationGateway
Third-party Service
Providers

50. Thank You