Microservices Architecture - Cloud Native Apps

Microservices
Architecture
Building Cloud Native Apps
Design Patterns, Containers,
Kubernetes, Istio, Kafka,
Saga – Distributed Transactions,
Testing, Security, Kanban
SRE, DevOps
ARAF KARSH HAMID
Co-Founder / CTO
MetaMagic Global Inc., NJ, USA
@arafkarsh
arafkarsh

2Slides are color coded based on the topic colors.
Microservices
Containers &
Kubernetes, Kafka
1
Infrastructure Patterns
Capability Centric Design
DDD / ES & CQRS
Reactive Programming
2
Testing Strategies
Security Best
Practices
3
Agile: Kanban
ITSM, DevOps,
SRE
4

Architecture Styles/Patterns• LAYERED ARCHITECTURE
• COMPONENT BASED ARCHITECTURE
• SERVICE ORIENTED ARCHITECTURE
• SERVICE BASED ARCHITECTURE
• MICRO KERNEL BASED ARCHITECTURE
• DOMAIN DRIVE DESIGN INTRO
• EVENT SOURCING INTRO
1/11/2021 3
0

Layered Architecture
UI Layer
WS
BL
DL
Database
ShoppingCart
Order
Customer
Inventory
It was developed by John J. Donovan in Open Environment Corporation (OEC), a tools
company he founded in Cambridge, Massachusetts.
3 Tier Architecture Pattern
o All the 3 Layers are
separated by network and
data is transferred by Value.
o You can upgrade a layer
without worrying about
impact on the other layer as
long as contract between
the layers are intact.
o Logic Tier can be further
divided into
1. Web Services Layer
2. Business Layer
3. Database Layer
https://professordonovan.com/open-environment-corporation

Component Based Architecture
1. Logical Units: Breaking the App into well defined logical units.
2. Communication: Components communicate using a COM/DCOM, EJB, CORBA, RMI
and other protocols or standard API contracts.
3. Reusability: A well defined component can be reused and self deployable unit.
4. Maintenance: Easy to change and upgrade the components without affecting the
whole system
5. Ease of Development: With well defined API contracts, it’s easy to develop a
component to do a specific task without impacting other parts of the system.
6. Ease of Deployment: It is easy to upgrade the existing version of the component
with the latest version without impacting other parts of the system (Provided
backward compatibility is maintained).

SOA – Service Oriented Architecture
UI Layer
Database
ShoppingCart
Order
Customer
Inventory
Enterprise Service
Bus
Messaging
REST / SOAP
HTTP
MOM
JMS
ODBC / JDBC
Translation
Web Services
XML
WSDL
Addressing
Security
Registry
Management
Producers
Shared
Database
Consumers
3rd
Party
Apps
Smart Pipes
Lot of Business logic
resides in the Pipe
Traditional Monolithic App with SOA
Service properties
1. It logically represents a
business activity with a
specified outcome.
2. Each is self-contained.
3. Each Service is a Blackbox to
the Service Consumer.
4. A Service can contain other
Services too.
5. Service Can be re-used. For Ex
Customer Service can be used
by multiple Apps.

Service Based Architecture
SOA and Microservices based on Service Based Architecture
1. Distributed Computing: Common thing in Service based architecture is distributed
computing.
2. Communication: Services communicate using a Remote Access Protocol (SOAP, REST,
RMI, JMS, Message Queues, AMQP (Advanced Message Queuing Protocol)
3. Service Contracts are based on XML, JSON, ProtoBuf etc. Contract versioning is key
aspect of the contracts and its future evolution.
4. Availability and Responsiveness: Availability ensures that there are no single point of
failures and Responsiveness to ensure that the Service Respond in a timely manner.
5. Security: As Services are independent components, it’s important that security and
access controls are taken care off. JSON Web Token is a popular standard.
6. Transactions: Transaction management is a Big challenge in Service based Architecture.
2 Phase Commit or Saga Design Patterns are patterns focusing on addressing these
challenges.

Micro Kernel Architecture Pattern
The microkernel architecture
pattern consists of two types of
architecture components:
1. a core system and
2. plug-in modules.
Application logic is divided
between
1. independent plug-in modules
2. and the basic core system,
providing
1. extensibility,
2. flexibility, and
3. isolation of application features
4. and custom processing logic
Source: https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch03.html

DDD: Bounded Context – Strategic Design
11-01-2021 9
• Bounded Context is a Specific Business Process / Concern.
• Components / Modules inside the Bounded Context are context specific.
• Multiple Bounded Contexts are linked using Context Mapping.
• One Team assigned to a Bounded Context.
• Each Bounded Context will have it’s own Source Code Repository.
• When the Bounded Context is being developed as a key strategic
initiative of your organization, it’s called the Core Domain.
• Within a Bounded Context the team must have same language called
Ubiquitous language for Spoken and for Design / Code Implementation.
Domain Driven Design

DDD: App User’s Journey & Bounded Context
1/11/2021
10
An App User’s Journey can run across
multiple Bounded Context / Micro
Services.
User Journey X
Bounded
Context
Bounded
Context
Bounded
Context
User Journey Y
Bounded
Context
Bounded
Context
Bounded
Context
Dinning
Order
Reservation
Tables
Recipes
Raw
Materials
Frozen
Semi Cooked
Appetizer Veg
Appetizer Non
Veg
Soft Drinks
Main Course
Non Veg
Main Course
Veg
Hot Drinks Desserts
Steward
Chef
Menu
uses
uses
Dinning
Order
Reservation
Tables
Recipes
Raw
Materials
Frozen
Semi Cooked
Appetizer Veg
Appetizer Non
Veg
Soft Drinks
Main Course
Non Veg
Main Course
Veg
Hot Drinks Desserts
Steward
Chef
Menu
uses
uses
UnderstandingBoundedContext(DDD)ofaRestaurantApp
Dinning
Context
Kitchen
Context
Menu Context
Source: Domain-Driven Design
Reference by Eric Evans

Domain Driven Design – Tactical Design
1/11/2021 11
Source: Domain-Driven Design Reference by Eric Evans

Event Sourcing Intro
1/11/2021 12
Standard CRUD Operations – Customer Profile – Aggregate Root
Profile Created Title Updated New Address added
Derived
Notes Removed
Time T1 T2 T4T3
Event Sourcing and Derived Aggregate Root
Commands
1. Create Profile
2. Update Title
3. Add Address
4. Delete Notes
2
Events
1. Profile Created Event
2. Title Updated Event
3. Address Added Event
4. Notes Deleted Event
3
Current State of the
Customer Profile
4
Event store
Single Source of Truth
Greg
Young

Event Sourcing & CQRS (Command and Query Responsibility Segregation)
• In traditional data management systems, both
commands (updates to the data) and queries
(requests for data) are executed against the same
set of entities in a single data repository.
• CQRS is a pattern that segregates the operations
that read data (Queries) from the operations that
update data (Commands) by using separate
interfaces.
• CQRS should only be used on specific portions of a
system in Bounded Context (in DDD).
• CQRS should be used along with Event Sourcing.
1/11/2021 13
MSDN – Microsoft https://msdn.microsoft.com/en-us/library/dn568103.aspx |
Martin Fowler : CQRS – http://martinfowler.com/bliki/CQRS.html
CQS :
Bertrand Meyer
Axon
Framework
For Java
Java Axon Framework Resource : http://www.axonframework.org
Greg
Young
(C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA

Distributed Tx: SAGA Design Pattern instead of 2PC
1/11/2021 14
Long Lived Transactions (LLTs) hold on to DB resources for relatively long periods of time, significantly delaying
the termination of shorter and more common transactions.
Source: SAGAS (1987) Hector Garcia Molina / Kenneth Salem,
Dept. of Computer Science, Princeton University, NJ, USA
T1 T2 Tn
Local Transactions
C1 C2 Cn-1
Compensating Transaction
Divide long–lived, distributed transactions into quick local ones with compensating actions for
recovery.
Travel : Flight Ticket & Hotel Booking Example
BASE (Basic Availability, Soft
State, Eventual Consistency)
Room ReservedT1
Room PaymentT2
Seat ReservedT3
Ticket PaymentT4
Cancelled Room Reservation
C1
Cancelled Room Payment
C2
Cancelled Ticket Reservation
C3

MICROSERVICES
• CONCEPTS
• WHEN SHOULD YOU USE MICROSERVICES?
• WHAT’S THE RIGHT SIZE?
• ARCHITECTURE (INFRATRUCTURE AND SOFTWRE)
1/11/2021 15
1

16Source: https://cloud.google.com/kubernetes-engine/kubernetes-comic/

Pioneers in Microservices Implementation
11-01-2021 17
New Entrants

18
100s Microservices
1,000s Releases / Day
10,000s Virtual Machines
100K+ User actions / Second
81 M Customers Globally
1 B Time series Metrics
10 B Hours of video streaming
every quarter
Source: NetFlix: : https://www.youtube.com/watch?v=UTKIT6STSVM
10s OPs Engineers
0 NOC
0 Data Centers
So what do NetFlix think about DevOps?
No DevOps
Don’t do lot of Process / Procedures
Freedom for Developers & be Accountable
Trust people you Hire
No Controls / Silos / Walls / Fences
Ownership – You Build it, You Run it.

19
50M Paid Subscribers
100M Active Users
60 Countries
Cross Functional Team
Full, End to End ownership of features
Autonomous1000+ Microservices
Source: https://microcph.dk/media/1024/conference-microcph-2017.pdf
1000+ Tech Employees
120+ Teams

Microservices definition
1/11/2021 20
In short, the microservice architectural style is an approach to
developing a single application as a suite of small services, each
running in its own process and communicating with lightweight
mechanisms, often an HTTP resource API. These services are built
around business capabilities and independently deployable by
fully automated deployment machinery. There is a bare minimum
of centralized management of these services, which may be
written in different programming languages and use different
data storage technologies.
https://martinfowler.com/articles/microservices.html
By James Lewis and Martin Fowler
Bolo Definition Kya hai?
Tell me what’s the definition

Microservices Characteristics
21
We can scale our operation independently, maintain
unparalleled system availability, and introduce new
services quickly without the need for massive
reconfiguration. —
Werner Vogels, CTO, Amazon Web Services
Modularity ... is to a technological economy
what the division of labor is to a
manufacturing one.
W. Brian Arthur,
author of e Nature of Technology
The key in making great and growable systems is
much more to design how its modules communicate
rather than what their internal properties and
behaviors should be.
Alan Kay, 1998 email to the Squeak-dev list
Components
via
Services
Organized around
Business
Capabilities
Products
NOT
Projects
Smart
Endpoints
& Dumb Pipes
Decentralized
Governance &
Data Management
Infrastructure
Automation
Design for
Failure
Evolutionary
Design

When should I use them (Microservices)?
11-01-2021 22
• Strong Module Boundaries:
Microservices reinforce modular
structure, which is particularly important
for larger teams.
• Independent Deployment: Simple
services are easier to deploy, and since
they are autonomous, are less likely to
cause system failures when they go
wrong.
• Technology Diversity: With microservices
you can mix multiple languages,
development frameworks and data-
storage technologies.
When you have What’s the Cost
Distribution: Distributed systems are harder to
program, since remote calls are slow and are
always at risk of failure.
Eventual Consistency: Maintaining strong
consistency is extremely difficult for a
distributed system, which means everyone has
to manage eventual consistency.
Operational Complexity: You need a mature
operations team to manage lots of services,
which are being redeployed regularly.
Source: https://www.martinfowler.com/microservices/

What is the right size for a Microservice?
11-01-2021 23
• Rather than the size what matters is the Business Function /
Domain of the service.
• One Microservice may have half a dozen entities and other a
couple of dozen entities. What’s more important is the role
Microservices plays.
• Bounded Context from DDD helps you to decompose a large
multi domain Monolith into a Microservice for each Bounded
Context.
• Focusing on User stories will help you clearly define the
boundaries of the Business Domain.

Microservices Architecture / Design Patterns
11-01-2021 24
• API Gateway
• Service Discovery
• Load Balancer
• Config Service
• Circuit Breaker
• Service Mesh
• Event Bus / Streams
• Hexagonal Architecture
• Domain Driven Design
• Event Sourcing & CQRS
• Functional Reactive
Programming
• MVC, MV*, Redux
Infrastructure Architecture

25
Monolithic vs. Microservices Example
Traditional Monolithic App using
Single Technology Stack
Micro Services with Multiple Technology Stack
This 3-tier model is obsolete now.
Source: Gartner Market Guide for Application Platforms. Nov 23, 2016
Event Stream / Queues / Pub-Sub / Storage
UI Layer
Web Services
Business Logic
Database Layer
Micro
Service
4
EE 7
Product
UI Layer
Web Services
Business Logic
Database Layer
Micro
Service
1
Customer
SE 8
UI Layer
Web Services
Business Logic
Database Layer
Micro
Service
3
Order
UI Layer
Web Services
Business Logic
Database Layer
Micro
Service
2
ShoppingCart
UI Layer
WS
BL
DL
Database
ShoppingCart
Order
Customer
Product
API Gateway (Zuul Edge Server)
Load Balancer
(Ribbon)
Circuit Breaker
(Hystrix)
Service Discovery (Eureka)
Load Balancer
(Ribbon)
Circuit Breaker
(Hystrix)
Load Balancer
(Ribbon)
Circuit Breaker
(Hystrix)
Load Balancer
(Ribbon)
Circuit Breaker
(Hystrix)
12

26
SOA vs. Microservices Example
Traditional Monolithic App with SOA
Micro Services with Multiple Technology Stack
Event Stream / Queues/ Pub-Sub / Storage
UI Layer
Web Services
Business Logic
Database Layer
Micro
Service
1
Customer
SE 8
UI Layer
Web Services
Business Logic
Database Layer
Micro
Service
3
Order
UI Layer
Web Services
Business Logic
Database Layer
Micro
Service
2
ShoppingCart
API Gateway
Load Balancer
Circuit Breaker
Service Discovery
Load Balancer
Circuit Breaker
Load Balancer
Circuit Breaker
UI Layer
Database
ShoppingCart
Order
Customer
Product
Enterprise Service
Bus
Messaging
REST / SOAP
HTTP
MOM
JMS
ODBC / JDBC
Translation
Web Services
XML
WSDL
Addressing
Security
Registry
Management
Producers
Shared
Database
Consumers3rd Party Apps
Smart Pipes
Lot of Business logic
resides in the Pipe

Microservices Deployment Model
Microservices with Multiple Technology Stack – Software Stack for Networking
Event Stream / Queues / Pub-Sub / Storage
Users
Service
Discovery
(Eureka)
Config
Server
(Spring)
API (Zuul) Gateway
UI Layer
Web Services
Business Logic
Database Layer
Micro
Service
2
ShoppingCart
SE 8
LB = Ribbon
CB = Hystrix
LB = Ribbon
CB = Hystrix
UI Layer
Web Services
Business Logic
Database Layer
Product
SE 8
Micro Service 1
With 4 node cluster
LB = Ribbon
CB = Hystrix
UI Layer
Web Services
Business Logic
Database Layer
Order
SE 8
Micro Service 3
With 2 node
Cluster
LB = Ribbon
CB = Hystrix
UI Layer
Web Services
Business Logic
Database Layer
Customer
Micro Service 4
With 2 node
cluster
HTTP Server
All UI Code is
bundled
Virtual
Private
Network
11-01-2021 27

Shopping Portal – Docker / Kubernetes – Network Stack
/ui
/productms
Load Balancer
Ingress
Deployment / Replica / Pod NodesKubernetes Objects
Firewall
UI Pod
UI Pod
UI Pod
UI Service
N1
N2
N2
EndPoints
Product Pod
Product Pod
Product Pod
Product
Service
N4
N3
MySQL
Pod
EndPoints
Review Pod
Review Pod
Review Pod
Review
Service
N4
N3
N1
Service Call
Kube DNS
EndPoints
Internal
Load Balancers
28
Users
Routing based on Layer 3,4 and 7

Shopping Portal – Docker / Kubernetes – Network Stack
29
/customer
/product
/review
Load Balancer
Ingress
Deployment / Replica / Pod Nodes
Kubernetes Objects
Firewall
Customer Pod
Customer Pod
Customer Pod
Customer
Service
N1
N2
N2
EndPoints
Product Pod
Product Pod
Product Pod
Product
Service
N4
N3
MySQL
DB
EndPoints
Review Pod
Review Pod
Review Pod
Review
Service
N4
N3
N1
Service Call
Kube DNS
EndPoints
Internal
Load Balancers
Users
Redis
DB
Mongo
DB

Software Network Stack Vs Network Stack
1/11/2021 30
Pattern Software Stack Java Software Stack .NET Kubernetes
1 API Gateway Zuul Server SteelToe Istio Envoy
2 Service Discovery Eureka Server SteelToe Kube DNS
3 Load Balancer Ribbon Server SteelToe Istio Envoy
4 Circuit Breaker Hysterix SteelToe Istio
5 Config Server Spring Config SteelToe Secrets, Env - K8s Master
Web Site https://netflix.github.io/ https://steeltoe.io/ https://kubernetes.io/
The Developer needs to write code to integrate with the Software Stack
(Programming Language Specific. For Ex. Every microservice needs to subscribe to
Service Discovery when the Microservice boots up.
Service Discovery in Kubernetes is based on the Labels assigned to Pod and Services
and its Endpoints (IP Address) are dynamically mapped (DNS) based on the Label.

31
Source:https://cloud.google.com/kubernetes-engine/kubernetes-comic/
Each one of the
Microservices can now be
• Debugged,
• Updated, and
• Deployed individually
without the whole
Project coming to a
standstill.
An important step on
the path to
• Continuous
Integration and
• Continuous Delivery.

32
Source:https://cloud.google.com/kubernetes-engine/kubernetes-comic/

33Source: https://cloud.google.com/kubernetes-engine/kubernetes-comic/

34
12FactorAppMethodology
4 Backing Services Treat Backing services like DB, Cache as attached resources
5 Build, Release, Run Separate Build and Run Stages
6 Process Execute App as One or more Stateless Process
7 Port Binding Export Services with Specific Port Binding
8 Concurrency Scale out via the process Model
9 Disposability Maximize robustness with fast startup and graceful exit
10 Dev / Prod Parity
Keep Development, Staging and Production as similar as possible
Checkout the Shift – Left in DevOps (Slide 157)
11 Logs Treat logs as Event Streams
12 Admin Process
Run Admin Tasks as one of Process (Eg. DB Migration, Software
upgrades, etc..)
Factors Description
1 Codebase One Code base tracked in revision control
2 Dependencies Explicitly declare dependencies
3 Configuration Configuration driven Apps
Source:https://12factor.net/

Catalogues of Microservices
1/11/2021 35
System Z Model From Spotify
• Different types of Components Z Supports
• Libraries
• Data Pipelines
• Views in the client
• Data Store
• Service

Pros
1. Adds Complexity
2. Skillset shortage
3. Confusion on getting the
right size
4. Team need to manage
end-to-end of the Service
(From UI to Backend to
Running in Production).
11-01-2021 36
1. Robust
2. Scalable
3. Testable (Local)
4. Easy to Change and
Replace
5. Easy to Deploy
6. Technology Agnostic
Cons
Microservices Pros and Cons

Monolithic > Microservices
• FORRESTER RESEARCH
• MODERNIZATION JOURNEY
• ASSESS AND CLASSIFY YOUR APP PORTFOLIO
• PLAN AND PRIORITIZE
1/11/2021 37

Conway’s Law
1/11/2021
(C)COPYRIGHTMETAMAGICGLOBALINC.,NEWJERSEY,USA
38
Any Organization that designs a system
(defined broadly) will produce a design
whose structure is a copy of the
organization’s communication structure.

* For IT Services : They can do one more project of same size with ZERO COST in Platform Licensing (Based on 20 developer pack USD $50K per month for 3 months License cost = $150K)
3911-01-2021

Scale Cube and Micro Services
1/11/2021 40
1. Y Axis Scaling – Functional Decomposition : Business Function as a Service
2. Z Axis Scaling – Database Partitioning : Avoid locks by Database Sharding
3. X Axis Scaling – Cloning of Individual Services for Specific Service Scalability

Modernization Journey
1/11/2021 41
 Start new features as Microservices
Incrementally establish the success early.
 Expose Legacy On-Premise Apps API’s
If legacy Apps cant be shifted to Cloud
 Refactor Monolithic features to Microservices
Breakdown and Deploy Feature by Feature
 Containerize the Microservice
Reduce costs, simplifies the operations and consistent
environment between Dev, QA and Production
 Monolith De-commission Plan
Incrementally sunset the Monolith
Velocity as you
transform
Increase your
Delivery Velocity
along the Journey
High
FuturePresent
Low
Inspired by a paper from IBM

Assess and Classify your App Portfolio
1/11/2021 42
 Take inventory of your Apps
Classify the Apps based on
technology, complexity.
 Align Apps to your Business
Priorities
Identify the Apps that are critical for
Modernization.
 Identify Business
Modernization Requirements
Create a Roadmap with faster go to
market strategy
 Understand the effort and
Cost
Evaluate all possible Modernization
options
Container Refactor Expose APIsLift & Shift
BusinessValueCostComplexity
Product Catalogue
Product Review
Inventory Shopping Cart
Customer
Profile
Order Management

Plan and Prioritize
1/11/2021 43
Complexity Cost Value Score Rank
Weightage 35% 25% 40%
Customer
Med
3
Med
3
Low
1
2.20
7
6
Product
Reviews
Med
3
High
5
Med
3
3.50
11
3
Product
Catalogue
Med
3
Med
3
High
5
4.80
11
1
Shopping
Cart
High
5
Med
3
Med
3
3.70
11
4
Order
Very High
7
Med
3
High
5
5.20
15
2
Inventory
Very High
7
High
5
Med
3
4.90
15
5
 Prioritize
Low Priority projects are good
test cases but does not bring
much business value.
 Quick Wins
Identify a feature / project which
has good business value and low
in complexity.
 Project Duration
Focus on shorter duration
projects with high Business Value.
Shopping Portal Features Prioritization

Monolithic to Microservices Summary
1/11/2021 44
1. Classify your Apps into Following areas
1. Lift and Shit
2. Containerize
3. Refactor
4. Expose API
2. Prioritize High Business Value Low Technical
Complexity
3. Focus on Shorter Duration – From Specs to
Operation

Containers & Kubernetes
• DOCKER CONTAINERS
• KUBERNETES – CONTAINER ORCHESTRATION
• ISTIO – TRAFFIC MANAGEMENT / NETWORK POLICIES
1/11/2021
45

Servers / Virtual Machines / Containers
Hardware
OS
BINS / LIB
App
1
App
2
App
3
Server
Hardware
Host OS
HYPERVISOR
App 1 App 2 App 3
Guest
OS
BINS
/ LIB
Guest
OS
BINS
/ LIB
Guest
OS
BINS
/ LIB
Type 1 Hypervisor
Hardware
Host OS
App
1
App
2
App
3
BINS
/ LIB
BINS
/ LIB
BINS
/ LIB
Container
Hardware
HYPERVISOR
App 1 App 2 App 3
Guest
OS
BINS
/ LIB
Guest
OS
BINS
/ LIB
Guest
OS
BINS
/ LIB
Type 2 Hypervisor11-01-2021
46

Docker containers are Linux Containers
CGROUPS
NAME
SPACES
Copy on
Write
DOCKER
CONTAINER
• Kernel Feature
• Groups Processes
• Control Resource
Allocation
• CPU, CPU Sets
• Memory
• Disk
• Block I/O
• Images
• Not a File System
• Not a VHD
• Basically a tar file
• Has a Hierarchy
• Arbitrary Depth
• Fits into Docker
Registry
• The real magic behind
containers
• It creates barriers
between processes
• Different Namespaces
• PID Namespace
• Net Namespace
• IPC Namespace
• MNT Namespace
• Linux Kernel Namespace
introduced between
kernel 2.6.15 – 2.6.26
docker runlxc-start
47
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/resource_management_guide/ch01
11-01-2021

Linux Kernel
48
HOST OS (Ubuntu)
Client
Docker Daemon
Cent OS
Alpine
Debian
LinuxKernel
Host Kernel
Host Kernel
Host Kernel
All the containers
will have the same
Host OS Kernel
If you require a
specific Kernel
version then Host
Kernel needs to be
updated
HOST OS (Windows 10)
Client
Docker Daemon
Nano Server
Server Core
Nano Server
WindowsKernel
Host Kernel
Host Kernel
Host Kernel
Windows Kernel

Docker DaemonDocker Client
How Docker works….
$ docker search ….
$ docker build ….
$ docker container create ..
Docker Hub
Images
Containers
$ docker container run ..
$ docker container start ..
$ docker container stop ..
$ docker container ls ..
$ docker push ….
$ docker swarm ..
11-01-2021 49
21
34
1. Search for the Container
2. Docker Daemon Sends the request to Hub
3. Downloads the image
4. Run the Container from the image

Kubernetes Key Concepts
1/11/2021
50
o Declarative Model
Infrastructure as a code
o Desired State
Required state of your App /
Microservice
o Current State
Current State of the App due to
error or load factor
Pods
Replicas
Deploy
Service

Deployment – Updates and rollbacks, Canary Release
D
ReplicaSet – Self Healing, Scalability, Desired State
R
Worker Node 1
Master Node (Control Plane)
Kubernetes
Architecture
POD
POD itself is a Linux
Container, Docker
container will run inside
the POD. PODs with single
or multiple containers
(Sidecar Pattern) will share
Cgroup, Volumes,
Namespaces of the POD.
(Cgroup / Namespaces)
Scheduler
Controller
Manager
Using yaml or json
declare the desired
state of the app.
State is stored in
the Cluster store.
Self healing is done by Kubernetes using watch loops if the desired state is changed.
POD POD POD
BE
1.210.1.2.34
BE
1.210.1.2.35
BE
1.210.1.2.36
BE
15.1.2.100
DNS: a.b.com 1.2
Service Pod IP Address is dynamic, communication should
be based on Service which will have routable IP
and DNS Name. Labels (BE, 1.2) play a critical role
in ReplicaSet, Deployment, & Services etc.
Cluster
Store
etcd
Key Value
Store
Pod Pod Pod
Label Selector selects pods based on the Labels.
Label
Selector
Label Selector
Label Selector
Node
Controller
End Point
Controller
Deployment
Controller
Pod
Controller
….
Labels
Internet
Firewall
K8s Cluster
Cloud Controller
For the cloud providers to manage
nodes, services, routes, volumes etc.
Kubelet
Node
Manager
Container
Runtime
Interface
Port 10255
gRPC
ProtoBuf
Kube-Proxy
Network Proxy
TCP / UDP Forwarding
IPTABLES / IPVS
Allows multiple
implementation of
containers from v1.7
RESTful yaml / json
$ kubectl ….
Port 443API Server
Pod IP ...34 ...35 ...36EP
• Declarative Model
• Desired State
Key Aspects
Namespace1Namespace2
• Pods
• ReplicaSet
• Deployment
• Service
• Endpoints
• StatefulSet
• Namespace
• Resource Quota
• Limit Range
• Persistent
Volume
Kind
Secrets
Kind
• apiVersion:
• kind:
• metadata:
• spec:
Declarative Model
• Pod
• ReplicaSet
• Service
• Deployment
• Virtual Service
• Gateway, SE, DR
• Policy, MeshPolicy
• RbaConfig
• Prometheus, Rule,
• ListChekcer …
@
@
Annotations
Names
Cluster IP
Node
Port
Load
Balancer
External
Name
@
Ingress
11-01-2021 51

52
Container 1
172.17.3.2
Web Server 8080
Veth: eth0
Container 2
172.17.3.3
Microservice 9002
Veth: eth0
Container 3
172.17.3.4
Microservice 9003
Veth: eth0
Container 4
172.17.3.5
Microservice 9004
Veth: eth0
IP tables rules
eth0
10.130.1.101/24
Node 1
Docker0 Bridge 172.17.3.1/16
Veth0 Veth1 Veth2 Veth3
Container 1
172.17.3.2
Web Server 8080
Veth: eth0
Container 2
172.17.3.3
Microservice 9002
Veth: eth0
Container 3
172.17.3.4
Microservice 9003
Veth: eth0
Container 4
172.17.3.5
Microservice 9004
Veth: eth0
IP tables rules
eth0
10.130.1.102/24
Node 2
Docker0 Bridge 172.17.3.1/16
Docker Networking Vs. Kubernetes Networking
Pod 1
172.17.3.2
Web Server 8080
Veth: eth0
Pod 2
172.17.3.3
Microservice 9002
Veth: eth0
Pod 3
172.17.3.4
Microservice 9003
Veth: eth0
Pod 4
172.17.3.5
Microservice 9004
Veth: eth0
IP tables rules
eth0
10.130.1.101/24
Node 1
L2 Bridge 172.17.3.1/16
Same IP Range. NAT Required Uniq IP Range. netFilter, IP Tables / IPVS. No NAT required
5
Pod 1
172.17.3.6
Web Server 8080
Veth: eth0
Pod 2
172.17.3.7
Microservice 9002
Veth: eth0
Pod 3
172.17.3.8
Microservice 9003
Veth: eth0
Pod 4
172.17.3.9
Microservice 9004
Veth: eth0
IP tables rules
eth0
10.130.1.102/24
Node 2
L2 Bridge 172.17.3.1/16

Kubernetes Networking
3 Networks
53Source: https://github.com/meta-magic/kubernetes_workshop
eth0 10.130.1.102/24
Node 1
veth0
eth0
Pod 1
Container 1
172.17.4.1
eth0
Pod 2
Container 1
172.17.4.2
veth1
eth0
10.130.1.103/24
Node 2
veth1
eth0
Pod 1
Container 1
172.17.5.1
eth0
10.130.1.104/24
Node 3
veth1
eth0
Pod 1
Container 1
172.17.6.1
Service
EP EP EP
VIP
192.168.1.2/16
1. Physical Network
2. Pod Network
3. Service Network
End Points
handles
dynamic IP
Addresses of
the Pods
selected by a
Service based
on Pod Labels
Virtual IP doesn’t have any
physical network card or
system attached.
6
Virtual Network - L2 / L3 /Overlay / Cloud

Service Mesh – Sidecar Design Pattern
11-01-2021 54
CB – Circuit Breaker
LB – Load Balancer
SD – Service Discovery
Microservice
Process1Process2
Service Mesh Control Plane
Service
Discovery
Routing
Rules
Control Plane will have all the rules for Routing and
Service Discovery. Local Service Mesh will download the
rules from the Control pane will have a local copy.
Service Discovery Calls
Service
Mesh
Calls
Customer Microservice
Application Localhost calls
http://localhost/api/order/
Router
Network Stack
LBCB SD
ServiceMesh
Sidecar
UI Layer
Web Services
Business Logic
Order Microservice
Application Localhost calls
http://localhost/api/payment/
Router
Network Stack
LBCB SD
ServiceMesh
Sidecar
UI Layer
Web Services
Business Logic
Data Plane

Shopping Portal
/ui
/productms
/auth
/order
Gateway
Virtual Service
Deployment / Replica / Pod NodesIstio Sidecar - Envoy
Load Balancer
Kubernetes
Objects
Istio Objects
Firewall
P M CIstio Control Plane
UI Pod N5v2Canary
v2User X = Canary
Others = Stable
A / B Testing using
Canary Deployment
v1 UI Pod
UI Pod
UI Pod
UI
Service
N1
N2
N2
Destination
Rule
Stable / v1
EndPoints
Internal
Load Balancers
55
Source:https://github.com/meta-magic/kubernetes_workshop
Users
Product Pod
Product Pod
Product Pod
Product
Service
MySQL
Pod
N4
N3
Destination
Rule
EndPoints
Review Pod
Review Pod
Review Pod
Review
Service
N1
N4
N3
Service Call
Kube DNS
EndPoints

Shopping Portal
/ui
/productms
/auth
/order
Gateway
Virtual Service
Load Balancer
Kubernetes
Objects
Istio Objects
Firewall
UI Pod N5v2Canary
v2
v1 UI Pod
UI Pod
UI Pod
UI
Service
N1
N2
N2
Destination
Rule
Stable / v1
EndPoints
Internal
Load Balancers
56
Users
Product Pod
Product Pod
Product Pod
Product
Service
MySQL
Pod
N4
N3
Destination
Rule
EndPoints
Review Pod
Review Pod
Review Pod
Review
Service
N1
N4
N3
Service Call
Kube DNS
EndPoints
Traffic Shifting
Canary Deployment
10% = Canary
90% = Stable

Shopping Portal
/ui
/productms
/auth
/order
Gateway
Virtual Service
Load Balancer
Kubernetes
Objects
Istio Objects
Firewall
UI Pod N5
v2Canary
v2
v1 UI Pod
UI Pod
UI Pod
UI
Service
N1
N2
N2
Destination
Rule
Stable / v1
EndPoints
Internal
Load Balancers
57
Users
Product Pod
Product Pod
Product Pod
Product
Service
MySQL
Pod
N4
N3
Destination
Rule
EndPoints
Review Pod
Review Pod
Review Pod
Review
Service
N1
N4
N3
Service Call
Kube DNS
EndPoints
Blue Green Deployment
100% = Stable
When you want to shift to v2
Change 100% to Canary

Shopping Portal
/ui
/productms
/auth
/order
Gateway
Virtual Service
Load Balancer
Kubernetes
Objects
Istio Objects
Firewall
UI Pod N5
v2Canary
v2
v1 UI Pod
UI Pod
UI Pod
UI
Service
N1
N2
N2
Destination
Rule
Stable / v1
EndPoints
Internal
Load Balancers
58
Users
Product Pod
Product Pod
Product Pod
Product
Service
MySQL
Pod
N4
N3
Destination
Rule
EndPoints
Review Pod
Review Pod
Review Pod
Review
Service
N1
N4
N3
Service Call
Kube DNS
EndPoints
Mirror Deployment
100% = Stable
Mirror = Canary
Production Data is mirrored to
new release for real-time testing

59
Shopping Portal
/ui
/productms
/auth
/order
Gateway
Virtual Service
Load Balancer
Firewall
P M CIstio Control PlaneFault Injection
MySQL
Pod
N4
N3
Destination
Rule
Product Pod
Product Pod
Product Pod
Product
Service
Service Call
Kube DNS
EndPoints
Internal
Load Balancers
59
Fault Injection
Delay = 2 Sec
Abort = 10%
Kubernetes
Objects
Istio Objects
Users
Review Pod
Review Pod
Review Pod
Review
Service
N1
N4
N3EndPoints
UI Pod
UI Pod
UI Pod
UI
Service
N1
N2
N2
Destination
Rule
v1EndPoints

K8s Network Policies L3/L4
60
Kubernetes blocks the
Product UI to access
Database or Product
Review directly.
You can create
Network policies
across name spaces,
services etc., for both
incoming (Ingress) and
outgoing (Egress)
traffic.
Product UI Pod
Product UI Pod
Product UI Pod
Product Pod
Product Pod
Product Pod
Review Pod
Review Pod
Review Pod
MySQL
Pod
Mongo
Pod
Order UI Pod
Order UI Pod
Order UI Pod
Order Pod
Order Pod
Order Pod
Oracle
Pod
7
Blocks Access
Blocks Access

Network Security Policy for Microservices
11-01-2021 61
Product Review
Microservice
Product
Microservice
172.27.1.2
L3 / L4
L7 – API
GET /live
GET /ready
GET /reviews/{id}
POST /reviews
PUT /reviews/{id}
DELETE /reviews/{id}
GET /reviews/192351
Product review can be accessed ONLY by
Product. IP Tables enforces this rule.
Exposed
Exposed
Exposed
Exposed
Exposed
All other method calls are also
exposed to Product Microservice.
iptables –s 172.27.1.2
-p tcp –dport 80
-j accept
7

Network Security Policy for Microservices
11-01-2021 62
Product Review
Microservice
Product
MicroserviceL3 / L4
L7 – API
GET /live
GET /ready
GET /reviews/{id}
POST /reviews
PUT /reviews/{id}
DELETE /reviews/{id}
GET /reviews/192351
Rules are implemented by BPF (Berkeley
Packet Filter) at Linux Kernel level.
From Product Microservice
only GET /reviews/{id}
allowed.
BPF / XDP performance is much
superior to IPVS.
Except GET /reviews All other
calls are blocked for Product
Microservice
7

BPF / XDP (eXpress Data Path)
11-01-2021 63
Network Driver Software StackNetwork Card
BPF
Regular BPF (Berkeley Packet Filter) mode
BPF
XDP allows BPF program to run inside the network driver with access to DMA buffer.
Berkeley Packet Filters (BPF) provide a powerful tool for intrusion detection analysis.
Use BPF filtering to quickly reduce large packet captures to a reduced set of results
by filtering based on a specific type of traffic.
Source: https://www.ibm.com/support/knowledgecenter/en/SS42VS_7.3.2/com.ibm.qradar.doc/c_forensics_bpf.html
7

XDP (eXpress Data Path)
11-01-2021 64
BPF Program can
drop millions packet
per second when
there is DDoS attack.Network Driver Software StackNetwork Card
BPF
Drop
Stack
BPF
Drop
Stack
LB & Tx
BPF can perform
Load Balancing and
transmit out the
data to wire again.
Source: http://www.brendangregg.com/ebpf.html
7

Kubernetes Container Network Interface
65
Container Runtime
Container Network Interface
Weave Calico Romana Cilium Flannel
Layer 3
BGP
BGP Route Reflector
Network Policies
IP Tables
Stores data in Etcd
Project Calico
Layer 3
VXLAN (No Encryption)
IPSec
Overlay Network
Host-GW (L2)
Stores data in Etcd
https://coreos.com/
Layer 3
IPSec
Network Policies
Multi Cloud NW
Stores data in Etcd
https://www.weave.works/
Layer 3
L3 + BGP & L2 +VXLAN
IPSec
Network Policies
IP Tables
Stores data in Etcd
https://romana.io/
Layer 3 / 7
BPF / XDP
L7 Filtering using BPF
Network Policies
L2 VXLAN
API Aware (HTTP, gRPC,
Kafka, Cassandra… )
Multi Cluster Support
https://cilium.io/
BPF (Berkeley Packet Filter) – Runs inside the Linux KernelOn-Premise Ingress Load Balancer
Mostly Mostly Yes Yes Yes
7

Container & Kubernetes Summary
1/11/2021 66
1. Containers are NOT Virtual Machines
2. Containers are isolated area in the OS kernel
3. Kubernetes – is a Container Orchestration
Platform.
4. Kubernetes abstracts the cloud vendor (AWS,
Azure, GCP) scalability features.
5. Kubernetes Concepts – Declarative Model,
Desired State and Current State.

Kafka
• CONCEPTS : QUEUES / PUB – SUB / EVENT STREAMING
• WHY IS IT DIFFERENT FROM TRADITIONAL MESSAGE QUEUES?
• DATA STORAGE / CLUSTER / DURABILITY
• PERFORMANCE
1/11/2021
67

Kafka Core Concepts
11-01-2021 68
Publish & Subscribe
Read and write streams of data
like a messaging system
Process
Write scalable stream processing
apps that react to events in real-
time.
Store
Store streams of data safely in a
distributed, replicated, fault
tolerant cluster.

Traditional Queue / Pub-Sub Vs. Kafka
11-01-2021 69
0 1 2 3 4 5 6 7 8 9
8
7
9 Consumer 1
Consumer 2
Consumer 3
Queues
Data
Data can be partitioned for scalability for parallel
processing by same type of consumers
Pros:
Cons:
Queues are NOT multi subscribers. Once a Consumer
reads the data, its gone from the queue. Ordering of
records will be lost in asynchronous parallel processing.
0 1 2 3 4 5 6 7 8 9
9
9
9 Consumer 1
Consumer 2
Consumer 3
Pub – Sub
Data
Multiple subscribers can get the same data.Pros:
Scaling is difficult as every message goes to every
subscriber.
Cons:
Kafka generalizes these two concepts.
 As with a queue the consumer group allows you to
divide up processing over a collection of processes
(the members of the consumer group).
 As with publish-subscribe, Kafka allows you to
broadcast messages to multiple consumer groups.

Anatomy of a Topic
11-01-2021 70
Source : https://kafka.apache.org/intro
• A Topic is a category or feed name to which
records are published.
• Topics in Kafka are always multi subscriber.
• That is, a Topic can have zero, one, or many
consumers that subscribe to the data
written to it.
• Each Partition is an ordered, immutable
sequence of records that is continually
appended to—a structured commit log.
• A Partition is nothing but a directory of Log
Files
• The records in the partitions are each assigned a sequential id number called
the offset that uniquely identifies each record within the partition.

11-01-2021 71
Partition Log Segment
• Partition (Kafka’s Storage unit) is Directory of Log
Files.
• A partition cannot be split across multiple brokers or
even multiple disks
• Partitions are split into Segments
• Segments are two files: 000.log & 000.index
• Segments are named by their base offset. The base
offset of a segment is an offset greater than offsets in
previous segments and less than or equal to offsets in
that segment.
• Indexes store offsets relative to its segments base
offset
• Indexes map each offset to their message position in
the log and they are used to look up messages.
• Purging of data is based on oldest segment and one
segment at a time.
0 1 2 3 4 5 6 7 8 9
Partition
Data
6
3
0 Segment 0
Segment 3
Segment 6
9 Segment 9 - Active
$ tree kafka-logs | head -n 6
kafka-logs
|──── SigmaHawk-2
| |──── 00000000006109871597.index
| |──── 00000000006109871597.log
| |──── 00000000007306321253.index
| |──── 00000000007306321253.log
Topic /
Partition
Segment 1
Segment 2
Rel.Offset, Position Offset, Position, Size, Payload
0000.index 0000.log
0 0 0 0 7 ABCDEFG
1 7 1 7 4 ABCD
2 11 2 11 9 ABCDEFGIJ
4 Bytes 4 Bytes

11-01-2021 72
Kafka Cluster – Topics & Partitions
• The partitions of the log are distributed over the servers in the Kafka cluster with each server handling data and requests
for a share of the partitions.
Source : https://kafka.apache.org/intro
Broker 1
Leader
Broker 2
Follower
Broker 3
Follower
Broker 4
Follower
Broker 5
Leader
Partition 1
Partition 0
Topic ABC
• Each server acts as a leader for some of its partitions and a follower for others so load is well balanced within the cluster.
• Each partition has one server which acts as the "leader" and zero or more servers which act as "followers".

11-01-2021
73
Record Commit Process
Broker 1
Leader
Topic 1
Broker 2
Follower
Producer
Consumer
2
2
Commit
3
ack
• Each partition is replicated across a configurable
number of servers for fault tolerance.
• The leader handles all read and write requests for
the partition while the followers passively replicate
the leader.
• If the leader fails, one of the followers will
automatically become the new leader.1
Message with Offset
4
777743
Broker 3
Follower
Data Durability From Kafka v0.8.0 onwards
acks Acknowledgement Description
0
If set to zero then the producer will NOT wait for any
acknowledgment from the server at all. The record will be
immediately added to the socket buffer and considered sent.
No guarantee can be made that the server has received the
record in this case, and the retries configuration will not take
effect (as the client won't generally know of any failures). The
offset given back for each record will always be set to -1.
1
This will mean the leader will write the record to its local log
but will respond without awaiting full acknowledgement
from all followers. In this case should the leader fail
immediately after acknowledging the record but before the
followers have replicated it then the record will be lost.
All /
-1
This means the leader will wait for the full set of in-sync
replicas to acknowledge the record. This guarantees that the
record will not be lost as long as at least one in-sync replica
remains alive. This is the strongest available guarantee. This is
equivalent to the acks=-1 setting.
Source: https://kafka.apache.org/documentation/#topicconfigs
acks Steps
0 1
1 1,3
-1 1,2,3
Producer Configuration

11-01-2021 74
Replication 6
3.2
m1
m2
m3
L(A)
m1
m2
F(B)
m1
F(C)ISR = (A, B, C)
Leader A commits Message
m1. Message m2 & m3 not
yet committed.
1
m1
m2
F(C)
m1
m2
L(B)
m1
m2
m3
L(A)
ISR = (B,C)
A fails and B is the new
Leader. B commits m22
m1
m2
m3
L(A)
m1
m2
L(B)
m4
m5
m1
m2
F(C)
m4
m5
ISR = (B,C)
B commits new messages
m4 and m5
3
m1
m2
L(B)
m4
m5
m1
m2
F(C)
m4
m5
m1
F(A)
ISR = (A, B,C)
A comes back, restores to
last commit and catches
up to latest messages.
4
m1
m2
L(B)
m4
m5
m1
m2
F(C)
m4
m5
m1
m2
F(A)
m4
m5
ISR – In-sync Replica
• Instead of majority vote, Kafka
dynamically maintains a set of in-sync
replicas (ISR) that are caught-up to the
leader.
• Only members of this set are eligible for
election as leader.
• A write to a Kafka partition is not
considered committed until all in-sync
replicas have received the write.
• This ISR set is persisted to ZooKeeper
whenever it changes. Because of this, any
replica in the ISR is eligible to be elected
leader.

LinkedIn Kafka Cluster
11-01-2021 75
Brokers60
Partitions50K
Messages / Second800K
MB / Second inbound300
MB / Second Outbound1024
The tuning looks fairly
aggressive, but all of the
brokers in that cluster
have a 90% GC pause
time of about 21ms, and
they’re doing less than 1
young GC per second.

Uber Kafka Cluster
11-01-2021 76
Topics10K+
Events / Second11M
Petabytes of Data1PB+

Kafka Summary
1/11/2021 77
1. Combined Best of Queues and Pub / Sub
Model.
2. Data Durability
3. Fastest Messaging Infrastructure
4. Streaming capabilities
5. Replication

1/11/2021 78
Architecture & Design Patterns
• I N F R A ST R U C T U R E D ES I G N PAT T E R N S
• C A PA B I L I T Y C E N T R I C D ES I G N
• D O M A I N D R I V E N D ES I G N
• E V E N T S O U RC I N G & CQ RS
• F U N C T I O NA L R EAC T I V E P RO G R A M M I N G
• U I D ES I G N PAT T E R N S
• R EST F U L A P I S A N D V E RS I O N I N G
2

1/11/2021 79
Infrastructure Design Patterns
• API GATEWAY
• LOAD BALANCER
• SERVICE DISCOVERY
• CIRCUIT BREAKER
• SERVICE AGGREGATOR
• LET-IT CRASH PATTERN

API Gateway Design Pattern – Software Stack
UILayer
WS
BL
DL
Database
Shopping Cart
Order
Customer
Product
Firewall
Users
API Gateway
LoadBalancer
CircuitBreaker
UILayer
WebServices
BusinessLogic
DatabaseLayer
Product
SE
MySQL
DB
Product
Microservice
With 4 node
cluster
LoadBalancer
CircuitBreaker
UILayer
WebServices
BusinessLogic
DatabaseLayer
Customer
Redis
DB
Customer
Microservice
With 2 node
cluster
Users
Access the
Monolithic
App
Directly
API Gateway (Reverse Proxy Server) routes the traffic
to appropriate Microservices (Load Balancers)

API Gateway – Kubernetes Implementation
/customer
/product
/cart
/order
API Gateway
Ingress
Firewall
Customer Pod
Customer Pod
Customer Pod
Customer
Service
N1
N2
N2
EndPoints
Product Pod
Product Pod
Product Pod
Product
Service
N4
N3
MySQL
DB
EndPoints
Review Pod
Review Pod
Review Pod
Review
Service
N4
N3
N1
Service Call
Kube DNS
EndPoints
Internal
Load Balancers
Users
Redis
DB
Mongo
DB
Load Balancer

82
API Gateway – Kubernetes / Istio
/customer
/product
/auth
/order
API Gateway
Virtual Service
Load Balancer
Firewall
MySQL
Pod
N4
N3
Destination
Rule
Product Pod
Product Pod
Product Pod
Product
Service
Service Call
Kube DNS
EndPoints
Internal
Load Balancers
82
Kubernetes
Objects
Istio Objects
Users
Review Pod
Review Pod
Review Pod
Review
Service
N1
N4
N3EndPoints
Customer Pod
Customer Pod
Customer Pod
Customer
Service
N1
N2
N2
Destination
Rule
EndPoints
Redis
DB
Mongo
DB

Load Balancer Design Pattern
Firewall
Users
API Gateway
Load
Balancer
CircuitBreaker
UILayer
WebServices
BusinessLogic
DatabaseLayer
Product
SE
MySQL
DB
Product
Microservice
With 4 node
cluster
Load
Balancer
CB=Hystrix
UILayer
WebServices
BusinessLogic
DatabaseLayer
Customer
Redis
DB
Customer
Microservice
With 2 node
cluster
API Gateway (Reverse Proxy Server) routes
the traffic to appropriate Microservices
(Load Balancers)
Load Balancer Rules
1. Round Robin
2. Based on
Availability
3. Based on
Response Time

Ingress
Load Balancer – Kubernetes Model
Kubernetes
Objects
Firewall
Users
Product 1
Product 2
Product 3
Product
Service
N4
N3
N1
EndPoints
Internal
Load Balancers
DB
Load Balancer
API Gateway
N1
N2
N2Customer 1
Customer 2
Customer 3
Customer
Service
EndPoints
DB
Internal
Load Balancers
Pods Nodes
• Load Balancer receives the (request) packet from the User and it picks up
a Virtual Machine in the Cluster to do the internal Load Balancing.
• Kube Proxy using IP Tables redirect the Packet using internal load
Balancing rules.
• Packet enters Kubernetes Cluster and reaches Node (of that specific Pod)
and Node handover the packet to the Pod.
/customer
/product
/cart

Service Discovery – NetFlix Network Stack Model
Firewall
Users
API Gateway
LoadBalancer
CircuitBreaker
Product
MySQL
DB
Product
Microservice
With 4 node
cluster
LoadBalancer
CircuitBreaker
UILayer
WebServices
BusinessLogic
DatabaseLayer
Customer
Redis
DB
Customer
Microservice
With 2 node
cluster
• In this model Developers write the
code in every Microservice to register
with NetFlix Eureka Service Discovery
Server.
• Load Balancers and API Gateway also
registers with Service Discovery.
• Service Discovery will inform the Load
Balancers about the instance details
(IP Addresses).
Service Discovery

Ingress
Service Discovery – Kubernetes Model
Kubernetes
Objects
Firewall
Users
Product 1
Product 2
Product 3
Product
Service
N4
N3
N1
EndPoints
Internal
Load Balancers
DB
API Gateway
N1
N2
N2Customer 1
Customer 2
Customer 3
Customer
Service
EndPoints
DB
Internal
Load Balancers
Pods Nodes
• API Gateway (Reverse Proxy Server) doesn't know the instances (IP
Addresses) of News Pod. It knows the IP address of the Services
defined for each Microservice (Customer / Product etc.)
• Services handles the dynamic IP Addresses of the pods. Services
Endpoints will automatically discover the new Pods based on Labels.
Service Definition
from Kubernetes
Perspective
/customer
/product
/cart
Service Call
Kube DNS

Circuit Breaker Pattern
87
/ui
/productms
If Product Review is not
available Product service
will return the product
details with a message
review not available.
Reverse Proxy Server
Ingress
Firewall
UI Pod
UI Pod
UI Pod
UI Service
N1
N2
N2
EndPoints
Product Pod
Product Pod
Product Pod
Product
Service
N4
N3
MySQL
Pod
EndPoints
Internal
Load Balancers
Users
Review Pod
Review Pod
Review Pod
Review
Service
N4
N3
N1
Service Call
Kube DNS
EndPoints

Service Aggregator Pattern
/newservice
Ingress
Kubernetes
Objects
Firewall
Service Call
Kube DNS
Users
Internal
Load Balancers
EndPoints News Pod
News Pod
News Pod
News
Service
N4
N3
N2
News Service Portal
• News Category wise
Microservices
• Aggregator Microservice to
aggregate all category of news.
Auto Scaling
• Sports Events (IPL / NBA) spikes
the traffic for Sports Microservice.
• Auto scaling happens for both
News and Sports Microservices.
N1
N2
N2National
National
National
National
Service
EndPoints
Internal
Load Balancers
DB
N1
N2
N2Politics
Politics
Politics
Politics
Service
EndPoints
DB
Sports
Sports
Sports
Sports
Service
N4
N3
N1
EndPoints
Internal
Load Balancers
DB

Music UI
1/11/2021 89
Play Count
Discography
Albums

Service Aggregator Pattern
90
/artist
Ingress
Kubernetes
Objects
Firewall
Service Call
Kube DNS
Users
Internal
Load Balancers
EndPoints Artist Pod
Artist Pod
Artist Pod
Artist
Service
N4
N3
N2
Spotify Microservices
• Artist Microservice combines all
the details from Discography,
Play count and Playlists.
Auto Scaling
• Scaling of Artist and downstream
Microservices will automatically
scale depends on the load factor.
N1
N2
N2Discography
Discography
Discography
Discography
Service
EndPoints
Internal
Load Balancers
DB
N1
N2
N2Play Count
Play Count
Play Count
Play Count
Service
EndPoints
DB
Playlist
Playlist
Playlist
Playlist
Service
N4
N3
N1
EndPoints
Internal
Load Balancers
DB

Config Store – Spring Config Server
Firewall
Users
API Gateway
LoadBalancer
CircuitBreaker
Product
MySQL
DB
Product
Microservice
With 4 node
cluster
LoadBalancer
CircuitBreaker
UILayer
WebServices
BusinessLogic
DatabaseLayer
Customer
Redis
DB
Customer
Microservice
With 2 node
cluster
• In this model Developers write the
code in every Microservice to
download the required configuration
from a Central server (Ex. Spring
Config Server for the Java World).
• This creates an explicit dependency
order in which service to come up will
be critical.
Config Server

Let-it-Crash Design Pattern – Erlang Philosophy
1/11/2021 92
• The Erlang view of the world is that everything is a process and that processes can
interact only by exchanging messages.
• A typical Erlang program might have hundreds, thousands, or even millions of processes.
• Letting processes crash is central to Erlang. It’s the equivalent of unplugging your router
and plugging it back in – as long as you can get back to a known state, this turns out to be
a very good strategy.
• To make that happen, you build supervision trees.
• A supervisor will decide how to deal with a crashed process. It will restart the process, or
possibly kill some other processes, or crash and let someone else deal with it.
• Two models of concurrency: Shared State Concurrency, & Message Passing Concurrency.
The programming world went one way (toward shared state). The Erlang community
went the other way.
• All languages such as C, Java, C++, and so on, have the notion that there is this stuff called
state and that we can change it. The moment you share something you need to bring
Mutex a Locking Mechanism.
• Erlang has no mutable data structures (that’s not quite true, but it’s true enough). No
mutable data structures = No locks. No mutable data structures = Easy to parallelize.

Let-it-Crash Design Pattern
1/11/2021 93
1. The idea of Messages as the first class citizens of a system, has been
rediscovered by the Event Sourcing / CQRS community, along with a strong
focus on domain models.
2. Event Sourced Aggregates are a way to Model the Processes and NOT things.
3. Each component MUST tolerate a crash and restart at any point in time.
4. All interaction between the components must tolerate that peers can crash.
This mean ubiquitous use of timeouts and Circuit Breaker.
5. Each component must be strongly encapsulated so that failures are fully
contained and cannot spread.
6. All requests sent to a component MUST be self describing as is practical so
that processing can resume with a little recovery cost as possible after a
restart.

Let-it-Crash : Comparison Erlang Vs. Microservices Vs. Monolithic Apps
94
Erlang Philosophy Micro Services Architecture Monolithic Apps (Java, C++, C#, Node JS ...)
1 Perspective
Everything is a
Process
Event Sourced Aggregates are a way to
model the Process and NOT things.
Things (defined as Objects) and
Behaviors
2
Crash
Recovery
Supervisor will
decide how to
handle the
crashed process
Kubernetes Manager monitors all the
Pods (Microservices) and its Readiness
and Health. K8s terminates the Pod if
the health is bad and spawns a new
Pod. Circuit Breaker Pattern is used
handle the fallback mechanism.
Not available. Most of the monolithic
Apps are Stateful and Crash Recovery
needs to be handled manually and all
languages other than Erlang focuses
on defensive programming.
3 Concurrency
Message Passing
Concurrency
Domain Events for state changes within
a Bounded Context & Integration Events
for external Systems.
Mostly Shared State Concurrency
4 State
Stateless :
Mostly Immutable
Structures
Immutability is handled thru Event
Sourcing along with Domain Events and
Integration Events.
Predominantly Stateful with Mutable
structures and Mutex as a Locking
Mechanism
5 Citizen Messages
Messages are 1st class citizen by Event
Sourcing / CQRS pattern with a strong
focus on Domain Models
Mutable Objects and Strong focus on
Domain Models and synchronous
communication.

Infrastructure Design Patterns Summary
1/11/2021 95
1. API Gateway
2. Service Discovery
3. Load Balancer
4. Circuit Breaker
5. Service Aggregator Pattern
6. Let It Crash Pattern

CAPABILITY CENTRIC DESIGN
• BUSINESS FUNCTIONS
• BUSINESS PROCESS
• TEAM STRUCTURE
1/11/2021 96

Business Solution & Business Process
1/11/2021 97
 Business Solution focuses the entire Journey of the User which
can run across multiple Microservices.
 Business Solution comprises a set of Business Processes.
 A specific Microservice functionality will be focused on a
Business Process / Concern
 Business Process can be divided further into Business Functions
Business Solution: Customer Dining Experience
Order PaymentFood Menu KitchenDining
Browse Menu Order Dinner Dinner Served Get Bill Make Payment

1/11/2021 98
Capability Centric Design
Vertically sliced Product Team
Business Centric Development
• Focus on Business Capabilities
• Entire team is aligned towards
Business Capability.
• From Specs to Operations – The
team handles the entire spectrum
of Software development.
• Every vertical will have it’s own
Code Pipeline
Front-End-Team Back-End-Team Database-Team
In a typical Monolithic way the team is
divided based on technology / skill set
rather than business functions. This leads
to not only bottlenecks but also lack of
understanding of the Business Domain.
QA / QC Team
Front-End
Back-End
Database
Business
Capability 1
QA/QCTeam
Front-End
Back-End
Database
Business
Capability 2
QA/QCTeam
Front-End
Back-End
Database
Business
Capability 3
QA/QCTeam

99
From
Project Based
Activity
Oriented
To
Product Based
Outcome
Oriented
Source: Sriram Narayan– https://martinfowler.com/bliki/BusinessCapabilityCentric.html

Capability Centric Design Summary
1/11/2021 100
1. Business Solutions
2. Business Process
3. Business Capabilities
4. Business Driven Teams (From Specs to Ops)
5. Outcome Oriented instead of Activity
Oriented.

1/11/2021
101
Software Design Patterns
• DOMAIN DRIVEN DESIGN
• EVENT SOURCING AND CQRS
• FUNCTIONAL REACTIVE PROGRAMMING
• DISTRIBUTED TRANSACTIONS
• REDUX UI PATTERN
• CASE STUDY

1/11/2021 102
• STRATEGIC: BOUNDED CONTEXT, UBIQUITOUS LANGUAGE
• TACTICAL DESIGN: ENTITIES, AGGREGATE ROOT, VALUE OBJECT,
FACTORIES, REPOSITORY, EVENTS, SERVICES
• CASE STUDY: SHOPPING PORTAL

DDD: Bounded Context – Strategic Design
11-01-2021 103
• Bounded Context is a Specific Business Process / Concern.
• Components / Modules inside the Bounded Context are context specific.
• Multiple Bounded Contexts are linked using Context Mapping.
• One Team assigned to a Bounded Context.
• Each Bounded Context will have it’s own Source Code Repository.
• When the Bounded Context is being developed as a key strategic
initiative of your organization, it’s called the Core Domain.
• Within a Bounded Context the team must have same language called
Ubiquitous language for Spoken and for Design / Code Implementation.

DDD: App User’s Journey & Bounded Context
1/11/2021
104
An App User’s Journey can run across
multiple Bounded Context / Micro
Services.
User Journey X
Bounded
Context
Bounded
Context
Bounded
Context
User Journey Y
Bounded
Context
Bounded
Context
Bounded
Context
Dinning
Order
Reservation
Tables
Recipes
Raw
Materials
Frozen
Semi Cooked
Appetizer Veg
Appetizer Non
Veg
Soft Drinks
Main Course
Non Veg
Main Course
Veg
Hot Drinks Desserts
Steward
Chef
Menu
uses
uses
Dinning
Order
Reservation
Tables
Recipes
Raw
Materials
Frozen
Semi Cooked
Appetizer Veg
Appetizer Non
Veg
Soft Drinks
Main Course
Non Veg
Main Course
Veg
Hot Drinks Desserts
Steward
Chef
Menu
uses
uses
UnderstandingBoundedContext(DDD)ofaRestaurantApp
Dinning
Context
Kitchen
Context
Menu Context
Source: Domain-Driven Design
Reference by Eric Evans

1/11/2021 105
Ubiquitous
Language
Vocabulary shared by
all involved parties
Used in all forms of spoken /
written communication
Ubiquitous
Language
Domain
Expert
Analyst Developers
QA
Design
Docs
Test Cases
Code
Restaurant Context – Food Item :
Eg. Food Item (Navrathnakurma)
can have different meaning or
properties depends on the
context.
• In the Menu Context it’s a
Veg Dish.
• In the Kitchen Context it’s
is recipe.
• And in the Dining Context
it will have more info
related to user feed back
etc.
DDD: Ubiquitous Language: Strategic Design
As an Restaurant Owner
I want to know who my Customers are
So that I can serve them better
Role-Feature-Reason Matrix
BDD – Behavior Driven Development
Given Customer John Doe exists
When Customer orders food
Then
Assign customer preferences
as Veg or Non Veg customer
BDD Construct

11-01-2021 106
Hexagonal Architecture
Ports & Adapters
The layer between the Adapter and
the Domain is identified as the Ports
layer. The Domain is inside the port,
adapters for external entities are on
the outside of the port.
The notion of a “port” invokes the
OS idea that any device that adheres
to a known protocol can be plugged
into a port. Similarly many adapters
may use the Ports.
Source : http://alistair.cockburn.us/Hexagonal+architecture
https://skillsmatter.com/skillscasts/5744-decoupling-from-asp-net-hexagonal-architectures-in-net
Services
for UI
Ports
File
system Database
Order Tracking
JPA Repository
Implementation
Adapters
OrderProcessing
Domain Service
(Business Rules)
Implementation
Domain
Models
Domain Layer
Order Data
Validation
OrderService
REST Service
Implementation
OrderProcessing
Interface
p
Order Tracking
Repository
Interface
p
A
A
External
Apps
A
A A
Others
A
A
OrderService
Interface
p
Web
Services
Data
Store
Use Case Boundary
Bounded Context
A
• Reduces Technical Debt
• Dependency Injection
• Auto Wiring

Layered Architecture
11-01-2021 107
• Explicit Domain Models – Isolate your models from UI, Business
Logic.
• Domain Objects – Free of the Responsibility of displaying
themselves or storing themselves or managing App Tasks.
• Zero Dependency on Infrastructure, UI and Persistent Layers.
• Use Dependency Injection for Loosely Coupled Objects.
• All the Code for Domain Model in a Single Layer.
• Domain Model should be Rich enough to represent Business
Knowledge.
Source: DDD Reference by Chris Evans Page 17

1/11/2021 108
Domain Driven Design – Tactical Design
Source: Domain-Driven Design Reference by Eric Evans

DDD: Understanding Aggregate Root
109
Order
Customer
Shipping
Address
Aggregate
Root
Line Item
Line Item
Line Item
*
Payment
Strategy
Credit Card
Cash
Bank Transfer
Source: Martin Fowler : Aggregate Root
• An aggregate will have one of its component
objects be the aggregate root. Any references
from outside the aggregate should only go to the
aggregate root. The root can thus ensure the
integrity of the aggregate as a whole.
• Aggregates are the basic element of transfer of
data storage - you request to load or save whole
aggregates. Transactions should not cross
aggregate boundaries.
• Aggregates are sometimes confused with
collection classes (lists, maps, etc.).
• Aggregates are domain concepts (order, clinic visit,
playlist), while collections are generic. An
aggregate will often contain multiple collections,
together with simple fields.
125
Domain
Driven
Design
(C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA11-01-2021

DDD: Domain Events & Integration Events
11-01-2021 110
1. Domain Events represent something happened in a specific Domain.
2. Domain Events should be used to propagate STATE changes across
Multiple Aggregates within the Bounded Context.
3. The purpose of Integration Events is to propagate committed
transactions and updates to additional subsystems, whether they are
other microservices, Bounded Contexts or even external applications.
Source: Domain Events : Design and Implementation – Microsoft Docs – May 26, 2017
Domain
Data Behavior
Order (Aggregate Root)
Data Behavior
Address (Value Object)
Data Behavior
OrderItem (Child)
1
n
1
1
Order Created
Domain Event
Domain Layer
Enforce consistency
with other Aggregates
Event Handler 1
Event Handler n
Create and Publish Integration
Event to Event Bus.
Example: Order Placed
Integration Event can be
subscribed by Inventory system
to update the Inventory details.
Event Handler 2

1/11/2021 111
Shopping Portal Modules – Code Packaging
Auth Products Cart OrderCustomer
Domain Layer
• Models
• Repo
• Services
• Factories
Adapters
• Repo
• Services
• Web Services
Domain Layer
• Models
• Repo
• Services
• Factories
Adapters
• Repo
• Services
• Web Services
Domain Layer
• Models
• Repo
• Services
• Factories
Adapters
• Repo
• Services
• Web Services
Packaging Structure
Bounded Context
Implementation
(Repositories, Business Services, Web Services)
Domain Models
(Entities, Value Objects, DTOs)
(Repositories, Business Services, Web Services)
Entity Factories
Interfaces (Ports)

1/11/2021 112
DDD: Use Case Order Module
Models
Value Object
• Currency
• Item Value
• Order Status
• Payment Type
• Record State
• Audit Log
Entity
• Order (Aggregate Root)
• Order Item
• Shipping Address
• Payment
DTO
• Order
• Order Item
• Shipping Address
• Payment
Domain Layer Adapters
• Order Repository
• Order Service
• Order Web Service
• Order Query Web Service
• Shipping Address Web Service
• Payment Web Service
Adapters Consists of Actual
Implementation of the Ports like
Database Access, Web Services
API etc.
Converters are used to convert
an Enum value to a proper
Integer value in the Database.
For Example Order Status
Complete is mapped to integer
value 100 in the database.
Services / Ports
• Order Repository
• Order Service
• Order Web Service
Utils
• Order Factory
• Order Status Converter
• Record State Converter
• Order Query Web Service
• Shipping Address Web Service
• Payment Web Service
Shopping Portal

Procedural Design Vs. Domain Driven Design
113
1. Anemic Entity Structure
2. Massive IF Statements
3. Entire Logic resides in Service
Layer
4. Type Dependent calculations are
done based on conditional checks
in Service Layer
4
1
23
Domain Driven Design with Java EE 6
By Adam Bien | Javaworld
Source: http://www.javaworld.com/article/2078042/java-app-dev/domain-driven-design-with-java-ee-6.html

Polymorphic Business Logic inside a Domain object
11-01-2021 114
Computation of the total cost
realized inside a rich
Persistent Domain Object
(PDO) and not inside a service.
This simplifies creating very
complex business rules.

Type Specific Computation in a Sub Class
115
We can change the
computation of the shipping
cost of a Bulky Item without
touching the remaining
classes.
Its easy to introduce a new
Sub Class without affecting
the computation of the total
cost in the Load Class.
of

Object Construction : Procedural Way Vs. Builder Pattern
116
Procedural Way Builder Pattern

Domain Driven Design Summary
1/11/2021 117
1. Strategic Patterns
1. Bounded Context
2. Ubiquitous Language
2. Tactical Patterns
1. Aggregate Root
2. Repository
3. Entity and Value Object
4. Domain Events

1/11/2021 118
Event Storming
• EVENT SOURCING / CQRS
• CASE STUDY: SHOPPING PORTAL
• CASE STUDY: RESTAURANT APP
• CASE STUDY: MOVIE BOOKING
• CASE STUDY: MOVIE STREAMING

Mind Shift : From Object Modeling to Process Modeling
1/11/2021 119
Developers with Strong Object Modeling experience
will have trouble making Events a first class citizen.
• How do I start Event Sourcing?
• Where do I Start on Event Sourcing / CQRS?
The Key is:
1. App User’s Journey
2. Business Process
3. Ubiquitous Language – DDD
4. Capability Centric Design
5. Outcome Oriented The Best tool to define your process and its tasks.
How do you define your End User’s Journey & Business Process?
• Think It
• Build It
• Run IT

120
Process
• Define your Business Processes. Eg. Various aspects of Order
Processing in an E-Commerce Site, Movie Ticket Booking,
Patient visit in Hospital.1
Commands • Define the Commands (End-User interaction with your App) to
execute the Process. Eg. Add Item to Cart is a Command.2
Event Sourced
Aggregate
• Current state of the Aggregate is always derived from the Event
Store. Eg. Shopping Cart, Order etc. This will be part of the Rich
Domain Model (Bounded Context) of the Micro Service.4
Projections
• Projections focuses on the View perspective of the Application.
As the Read & Write are different Models, you can have
different Projections based on your View perspective.
5
Write
Data
Read
Data
Events • Commands generates the Events to be stored in Event Store.
Eg. Item Added Event (in the Shopping Cart).3
Event Storming – Concept

1/11/2021 121
Event Sourcing Intro
Standard CRUD Operations – Customer Profile – Aggregate Root
Profile Created Title Updated New Address added
Derived
Notes Removed
Time T1 T2 T4T3
Event Sourcing and Derived Aggregate Root
Commands
1. Create Profile
2. Update Title
3. Add Address
4. Delete Notes
2
Events
1. Profile Created Event
2. Title Updated Event
3. Address Added Event
4. Notes Deleted Event
3
Current State of the
Customer Profile
4
Event store
Single Source of Truth
Greg
Young

Event Sourcing & CQRS (Command and Query Responsibility Segregation)
• In traditional data management systems, both
commands (updates to the data) and queries
(requests for data) are executed against the same
set of entities in a single data repository.
• CQRS is a pattern that segregates the operations
that read data (Queries) from the operations that
update data (Commands) by using separate
interfaces.
• CQRS should only be used on specific portions of a
system in Bounded Context (in DDD).
• CQRS should be used along with Event Sourcing.
1/11/2021 122
MSDN – Microsoft https://msdn.microsoft.com/en-us/library/dn568103.aspx |
Martin Fowler : CQRS – http://martinfowler.com/bliki/CQRS.html
CQS :
Bertrand Meyer
Axon
Framework
For Java
Java Axon Framework Resource : http://www.axonframework.org
Greg
Young
(C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA

1/11/2021 123
Case Study: Restaurant Dining – Event Sourcing and CQRS
Order Payment
• Add Drinks
• Add Food
• Update Food
Commands • Open Table
• Add Juice
• Add Soda
• Add Appetizer 1
• Add Appetizer 2
• Serve Drinks
• Prepare Food
• Serve Food
Events
• Drinks Added
• Food Added
• Food Updated
• Food Discontinued
• Table Opened
• Juice Added
• Soda Added
• Appetizer 1 Added
• Appetizer 2 Added
• Juice Served
• Soda Served
• Appetizer Served
• Food Prepared
• Food Served
• Prepare Bill
• Process
Payment
• Bill Prepared
• Payment Processed
• Payment Approved
• Payment Declined
• Cash Paid
When people arrive at the Restaurant and take a table, a Table is opened. They may then order drinks and
food. Drinks are served immediately by the table staff; however food must be cooked by a chef. Once the
chef prepared the food it can then be served. Table is closed then the bill is prepared.
Microservices
• Dinning Order
• Billable Order
Customer Journey thru Dinning Processes
Processes
Food Menu KitchenDining
• Remove Soda
• Add Food 1
• Add Food 2
• Place Order
• Close Table
• Remove Soda
• Food 1 Added
• Food 2 Added
• Order Placed
• Table Closed
ES Aggregate
3
2 4
1

Case Study: Shopping Site – Event Sourcing / CQRS
1/11/2021 124
Catalogue Shopping Cart Order Payment
• Search Products
• Add Products
• Update Products
Commands
• Add to Cart
• Remove Item
• Update Quantity
Customer
• Process Order
• Select Address
• Select Delivery Mode
Events
• Product Added
• Product Updated
• Product Discontinued
• Item Added
• Item Removed /
Discontinued
• Item Updated
• Order Initiated
• Address Selected
• Delivery Mode Selected
• Order Created
• Proceed for Payment
• Confirm Order for Payment
• Cancel Order
• Payment Initiated
• Order Cancelled
• Order Confirmed
• OTP Send
Commands are End-User interaction with the App and based on the commands (Actions) Events are created. These Events includes
both Domain Events and Integration Events. Event Sourced Aggregates will be derived using Domain Events. Each Micro Service will
have its own separate Database. Depends on the scalability requirement each of the Micro Service can be scaled separately. For
Example. Catalogue can be on a 50-node cluster compared to Customer Micro Service.
Microservices
• Customer
• Shop.. Cart
• Order
Customer Journey thru Shopping Process
The purpose of this example is to demonstrate the concept of ES / CQRS thru Event Storming principles.
2
3
ESA 4

Case Study: Movie Booking – Event Sourcing / CQRS
1/11/2021 125
Order Payment
• Search Movies
• Add Movies
• Update Movies
Commands
• Select Movie
• Select Theatre / Show
• Select Tickets
• Process Order
• Select Food
• Food Removed
• Skip Food
• Process Order
Events
• Movie Added
• Movie Updated
• Movie Discontinued
• Movie Added
• Theatre / Show Added
• Tickets Added
• Order Initiated
• Popcorn Added
• Drinks Added
• Popcorn Removed
• Order Finalized
• Proceed for Payment
• Confirm Order for Payment
• Cancel Order
• Payment Initiated
• Order Cancelled
• Order Confirmed
• OTP Send
Movies Theatres Food
Microservices
Commands are End-User interaction with the App and based on the commands (Actions) Events are created. These Events includes both
Domain Events and Integration Events. Event Sourced Aggregates will be derived using Domain Events. Each Micro Service will have its
own separate Database. Depends on the scalability requirement each of the Micro Service can be scaled separately. For Example.
Theatre can be on a 50 node cluster compared to Food Micro Service.
ESA
• Theatre
• Show
• Order
Customer Journey thru booking Movie Ticket

Case Study: Movie Streaming – Event Sourcing / CQRS
1/11/2021 126
Subscription Payment
• Search Movies
• Add Movies
• Update Movies
Commands
• Request Streaming
• Start Movie Streaming
• Pause Movie Streaming
• Validate Streaming
License
• Validate Download
License
Events
• Movie Added
• Movie Updated
• Movie Discontinued
• Streaming Requested
• Streaming Started
• Streaming Paused
• Streaming Done
• Streaming Request
Accepted
• Streaming Request
Denied
• Subscribe Monthly
• Subscribe Annually
• Monthly
Subscription Added
• Yearly Subscription
Added
Discovery
Microservices
Commands are End-User interaction with the App and based on the commands (Actions) Events are created. These Events includes both
Domain Events and Integration Events. Event Sourced Aggregates will be derived using Domain Events. Each Micro Service will have its
own separate Database. Depends on the scalability requirement each of the Micro Service can be scaled separately. For Example.
Theatre can be on a 50 node cluster compared to Food Micro Service.
ESA
• Stream List
• Favorite List
Customer Journey thru Streaming Movie / TV Show
LicenseStreaming

Event Sourcing & CQRS Summary
1/11/2021 127
1. Process
Ex. Various aspects of Order Processing in an E-Commerce Site, Movie Ticket Booking,
Patient visit in Hospital.
2. Commands
End-User interaction with your App) to execute the Process. Eg. Add Item to Cart is a
Command.
3. Events
Item Added Event (in the Shopping Cart).
4. Event Sourced Aggregate
Current state of the Aggregate is always derived from the Event Store. Eg. Shopping Cart
5. Read & Write Separates Databases

1/11/2021 128
Reactive Programming
• BUILDING BLOCKS: OBSERVABLE, OBSERVER, SCHEDULER, OPERATOR
• COMPARISON: ITERABLE (JAVA 6), STREAMS (JAVA 8), RX JAVA
• CASE STUDY: MERGE STREAMS, FILTER, SORT, TAKE

1/11/2021 129
Functional Reactive Programming: 4 Building Blocks of RxJava
Source of Data Stream [ Sender ]Observable1
Listens for emitted values [ Receiver ]Observer2
Source: http://reactivex.io/
Schedulers3
Schedulers are used to manage and control concurrency.
1. observeOn: Thread Observable is executed
2. subscribeOn: Thread subscribe is executed
4 Operators
Content Filtering
Time Filtering
Transformation
Operators that let you
Transform, Combine,
Manipulate, and work
with the sequence of
items emitted by
Observables

1/11/2021 130
Comparison : Iterable / Streams / Observable 1Building Block
First Class Visitor (Consumer)
Serial Operations
Parallel Streams (10x Speed)
Still On Next, On Complete and
On Error are Serial Operations
Completely Asynchronous
Operations
Java 8 – Blocking CallJava 6 – Blocking Call Rx Java - Freedom
Source Code: https://github.com/meta-magic/rxjava

131
Rx 2 Java Operator : Filter / Sort / FlatMap 4Building
Block
Objective:
toSortedList() returns an Observable with a single List containing Fruits.
Using FlatMap to Transform Observable <List> to Observable <Fruit>
Rx Example 2
SourceCodeGitHub:https://github.com/meta-magic/Rx-Java-2
• Merge
• Filter
• Sort
• Take

Functional Reactive Programming Summary
1/11/2021 132
1. Observable
Source of the Data Stream
2. Observer
Listens to emitted values
3. Scheduler
Are used to manage and control and concurrency.
4. Operators
Operators that let you Transform, Combine, Manipulate, and work with the
sequence of items emitted by Observables

1/11/2021 133
UI DESIGN PATTERNS
• TRADITIONAL PATTERNS: MVC, MVP, MVVM
• FLUX DESIGN PATTERN
• REDUX DESIGN PATTERNS

1/11/2021 134
UI DesignPatterns
MVC/ MVP/ MVVM
View
Controller
Model
Passes
calls To
Fire
Events
Manipulates
• The Controller is responsible to process incoming
requests. It receives input from users via the View,
then process the user's data with the help of Model
and passing the results back to the View.
• Typically, it acts as the coordinator between the
View and the Model.
Model
View
Controller
1
*
• The View Model is responsible for exposing methods,
commands, and other properties that helps to maintain
the state of the view, manipulate the model as the
result of actions on the view, and trigger events in the
view itself.
• There is many-to-one relationship between View and
ViewModel means many View can be mapped to one
ViewModel.
• Supports two-way data binding between View and
ViewModel.
View
ViewModel
Model
Passes
calls To
Manipulates
Updates
Fire
Events
Model
View
ViewModel
• The Presenter is responsible for handling all UI events on
behalf of the view. This receive input from users via the
View, then process the user's data with the help of Model
and passing the results back to the View.
• Unlike view and controller, view and presenter are
completely decoupled from each other’s and
communicate to each other’s by an interface. Also,
presenter does not manage the incoming request traffic as
controller.
• Supports two-way data binding.
Model
View
Presenter
View
Presenter
Model
Passes
calls To
Fire
Events
Manipulates
Updates1
1

1/11/2021 135
UI Design Patterns
Flux / Redux
ViewDispatcher
Every action is sent to all Stores via callbacks the
stores register with the Dispatcher
Store
Action
Action
1 *
Controller-Views
• Listens to Store changes
• Emit Actions to Dispatcher
Dispatcher
• Single Dispatcher per Application
• Manages the Data Flow View to Model
• Receives Actions and dispatch them to Stores
Stores
• Contains state for a Domain (Vs. Specific Component)
• In Charge of modifying the Data
• Inform the views when the Data is changed by emitting the
Changed Event.
Flux Core Concepts
1. One way Data Flow
2. No Event Chaining
3. Entire App State is resolved in store before Views Update
4. Data Manipulation ONLY happen in one place (Store).
Actions
• Simple JS Objects
• Contains Name of the Action and Data (Payload)
• Action represent something that has happened.
• Has No Business Logic

1/11/2021 136
UI Design Patterns
Redux
Actions
• Simple JS Objects
• Contains Name of the
Action and Data
(Payload)
• Has NO Business Logic
• Action represent
something that has
happened.
Store
• Multiple View layers can Subscribe
• View layer to Dispatch actions
• Single Store for the Entire Application
• Data manipulation logic moves out of
store to Reducers
Reducer
• Pure JS Functions
• No External calls
• Can combine multiple reducers
• A function that specifies how the state changes in response to an Action.
• Reducer does NOT modify the state. It returns the NEW State.
Redux Core Concepts
1. One-way Data Flow
2. No Dispatcher compared to Flux
3. Immutable Store
Available for React & Angular
View
Action
State
Dispatcher
Reducer
R R
R
Store
Middleware
Middleware
Middleware
• Handles External calls
• Multiple Middleware's can be chained.

UI Design Pattern Summary
1/11/2021 137
1. MVC
2. MVP
3. MVVM
4. Flux
5. Redux
Redux is a much better pattern if you are building complex enterprise
applications.

1/11/2021 138
Distributed Transactions
• 2 PHASE COMMIT
• SAGA DESIGN PATTERN
• HANDLING INVARIANTS
• FORWARD RECOVERY

Distributed Transactions : 2 Phase Commit
2 PC or not 2 PC, Wherefore Art Thou XA?
11January2021
139
How does 2PC impact scalability?
• Transactions are committed in two phases.
• This involves communicating with every database (XA
Resources) involved to determine if the transaction will commit
in the first phase.
• During the second phase each database is asked to complete
the commit.
• While all of this coordination is going on, locks in all of the data
sources are being held.
• The longer duration locks create the risk of higher contention.
• Additionally, the two phases require more database
processing time than a single-phase commit.
• The result is lower overall TPS in the system.
Transaction
Manager
XA Resources
Request to Prepare
Commit
Prepared
Prepare
Phase
Commit
PhaseDone
Source : Pat Helland (Amazon) : Life Beyond Distributed Transactions Distributed Computing : http://dancres.github.io/Pages/
Solution : Resilient System
• Event Based
• Design for failure
• Asynchronous Recovery
• Make all operations idempotent.
• Each DB operation is a 1 PC

Scalability Best Practices : Lessons from
Best Practices Highlights
#1 Partition By Function
• Decouple the Unrelated Functionalities.
• Selling functionality is served by one set of applications, bidding by another, search by yet another.
• 16,000 App Servers in 220 different pools
• 1000 logical databases, 400 physical hosts
#2 Split Horizontally
• Break the workload into manageable units.
• eBay’s interactions are stateless by design
• All App Servers are treated equal and none retains any transactional state
• Data Partitioning based on specific requirements
#3
Avoid Distributed
Transactions
• 2 Phase Commit is a pessimistic approach comes with a big COST
• CAP Theorem (Consistency, Availability, Partition Tolerance). Apply any two at any point in time.
• @ eBay No Distributed Transactions of any kind and NO 2 Phase Commit.
#4
Decouple Functions
Asynchronously
• If Component A calls component B synchronously, then they are tightly coupled. For such systems to
scale A you need to scale B also.
• If Asynchronous A can move forward irrespective of the state of B
• SEDA (Staged Event Driven Architecture)
#5
Move Processing to
Asynchronous Flow
• Move as much processing towards Asynchronous side
• Anything that can wait should wait
#6 Virtualize at All Levels • Virtualize everything. eBay created their on O/R layer for abstraction
#7 Cache Appropriately • Cache Slow changing, read-mostly data, meta data, configuration and static data.
140
Source: http://www.infoq.com/articles/ebay-scalability-best-practices

1/11/2021 141
Distributed Tx: SAGA Design Pattern instead of 2PC
Long Lived Transactions (LLTs) hold on to DB resources for relatively long periods of time, significantly delaying
the termination of shorter and more common transactions.
Source: SAGAS (1987) Hector Garcia Molina / Kenneth Salem,
Dept. of Computer Science, Princeton University, NJ, USA
T1 T2 Tn
Local Transactions
C1 C2 Cn-1
Compensating Transaction
Divide long–lived, distributed transactions into quick local ones with compensating actions for
recovery.
Travel : Flight Ticket & Hotel Booking Example
BASE (Basic Availability, Soft
State, Eventual Consistency)
Room ReservedT1
Room PaymentT2
Seat ReservedT3
Ticket PaymentT4
Cancelled Room Reservation
C1
Cancelled Room Payment
C2
Cancelled Ticket Reservation
C3

SAGA Design Pattern Features
1/11/2021 142
1. Backward Recovery (Rollback)
T1 T2 T3 T4 C3 C2 C1
Order Processing, Banking
Transactions, Ticket Booking
Examples
Updating individual scores in
a Team Game.
2. Forward Recovery with Save Points
T1 (sp) T2 (sp) T3 (sp)
• To recover from Hardware Failures, SAGA needs to be persistent.
• Save Points are available for both Forward and Backward Recovery.
Type
Source: SAGAS (1987) Hector Garcia Molina / Kenneth Salem, Dept. of Computer Science, Princeton University, NJ, USA

Handling Invariants – Monolithic to Micro Services
1/11/2021 143
In a typical Monolithic App
Customer Credit Limit info and
the order processing is part of
the same App. Following is a
typical pseudo code.
Order CreatedT1 Order
Microservice
Credit ReservedT2
Customer
Microservice
In Micro Services world with Event Sourcing, it’s a
distributed environment. The order is cancelled if
the Credit is NOT available. If the Payment
Processing is failed then the Credit Reserved is
cancelled.
Payment
MicroservicePayment ProcessedT3
Order Cancelled due to
credit unavailability /
payment failureC1
Credit Cancelled due to
payment failureC2
Begin Transaction
If Order Value <= Available
Credit
Process Order
Process Payments
End Transaction
Monolithic 2 Phase Commit
https://en.wikipedia.org/wiki/Invariant_(computer_science)

1/11/2021 144
Use Case : Restaurant – Forward Recovery
Domain
The example focuses on
the concept of a
Restaurant which tracks
the visit of an individual
or group to the
Restaurant. When
people arrive at the
Restaurant and take a
table, a table is opened.
They may then order
drinks and food. Drinks
are served immediately
by the table staff,
however food must be
cooked by a chef. Once
the chef prepared the
food it can then be
served.
PaymentBillingDining
Source: http://cqrs.nu/tutorial/cs/01-design
Soda Cancelled
Table Opened
Juice Ordered
Soda Ordered
Appetizer Ordered
Soup Ordered
Food Ordered
Juice Served
Food Prepared
Food Served
Appetizer Served
Table Closed
Aggregate Root : Dinning Order
Billed OrderT1
Payment CCT2
Payment CashT3
T1 (sp) T2 (sp) T3 (sp)
Event Stream
Aggregate Root : Food Bill
Transaction doesn't rollback if one payment
method is failed. It moves forward to the
NEXT one.
sp
Network
ErrorC1 sp

Distributed Transaction Summary
1/11/2021 145
1. 2 Phase Commit
Doesn’t scale well in cloud environment
2. SAGA Design Pattern
Raise compensating events when the local transaction fails.
3. SAGA Supports Rollbacks & Roll
Forwards
Critical pattern to address distributed transactions.

1/11/2021 146
RESTful APIs
• STANDARDS
• API VERSIONING STANDARDS

1/11/2021 147
RESTful Guidelines
1. Endpoints as nouns, NOT verbs
Ex. /catalogues
/orders
/catalogues/products
and NOT
/getProducts/
/updateProducts/
2. Use plurals
Ex. /catalogues/{catalogueId}
and NOT
/catalogue/{catalogueId}
3. Documenting
4. Paging
5. Use SSL
6. HTTP Methods
GET / POST / PUT / DELETE / OPTIONS / HEAD
7. HTTP Status Codes (Effective usage)
8. Versioning
Media Type Version
GET /account/5555 HTTP/1.1
Accept: application/vnd.catalogues.v1+json
URL path version
https://domain/v1/catalogues/products

1/11/2021 148
RESTful Guidelines – Query Examples
Search All
Products
Search Products By
Catalogue ID
Search Products By
Catalogue ID & Product ID

1/11/2021 149
RESTful Guidelines – Query Examples
Two different
implementation
of same query

1/11/2021 150
# Name * Who Uses Pros Cons
1
Media Type Versioning
Accept:
Application/vnd.api.article+xml;
version=1.0
Med GitHub
• Version Directly @
resource level
• Preserve URI
• Close to RESTful Specs
• Harder to Test
• Distort HTTP Headers purpose
• Tools required for testing
2
Custom Headers Versioning
X-API-Version: 2.
Med Microsoft • Preservers URI
• Harder to Test
• Tools required for testing
3
URI Versioning
api.example.com/v1/resource
High
Google
Twitter
Amazon
• Most common method
• Versions can be explored
using Browser
• Easy to use
• Disrupts RESTful Compliance.
URI should represent resource
and not versions
4
Domain Versioning
apiv1.example.com/resource
Low Facebook
• Same as are URI
Versioning
• Same as URI Versioning
5
Request Parameter
Versioning
GET /something/?version=0.1
High
Pivotal
NetFlix
• Similar to URI versioning • It can get messy
6
Date Versioning
First request saves the date.
Low Clearbit
• New APIs can be shipped
without changing the
end points
• Complex to implement
• Traceability is difficult.
API Versioning

Functional Reactive Programming Summary
1/11/2021 151
1. 2 Phase
Doesn’t scale well in cloud environment
2. Observer
Listens to emitted values
3. Scheduler
Are used to manage and control and concurrency.
4. Operators
Operators that let you Transform, Combine, Manipulate, and work with the
sequence of items emitted by Observables

1/11/2021 152
Testing & Security
• TESTING STRATEGIES
• DOCKER SECURITY PRACTICES
• KUBERNETES SECURITY PRACTICES
3

1/11/2021 153
Testing Strategies
• UNIT TESTING
• COMPONENT TESTING
• INTEGRATION CONTRACT TESTING
• INTEGRATION TESTING

1/11/2021 154
Microservices Testing Strategies
Ubiquitous
Language
Domain
Expert
Analyst Developers
QA
Design
Docs
Test Cases
Code
E2E
Testing
Integration
Testing
Contract Testing
Component Testing
Unit Testing
Number of Tests
Speed
Cost
Time
Mike Cohen’s Testing Pyramid
Test Pyramid: https://martinfowler.com/bliki/TestPyramid.html
70%
20%
10%

1/11/2021 155
Microservices Testing Strategy
Unit Testing
A unit test exercises the
smallest piece of testable
software in the application
to determine whether it
behaves as expected.
Source: https://martinfowler.com/articles/microservice-testing/#agenda
Component Testing
A component test limits the
scope of the exercised
software to a portion of the
system under test,
manipulating the system
through internal code
interfaces and using test
doubles to isolate the code
under test from other
components.
Integration Testing
An integration test verifies
the communication paths
and interactions between
components to detect
interface defects
Integration Contract Testing
An Integration Contract test is a
test at the boundary of an
external service verifying that it
meets the contract expected by a
consuming service.
End 2 End Testing
An end-to-end test verifies that a
system meets external
requirements and achieves its
goals, testing the entire system,
from end to end
Say NO to End 2 End Tests - Mike
Walker April 22, 2015. Google Test Blog

1/11/2021 156
Testing ToolsMicroservices Testing Scenarios / Tools
Contract Testing Scope
Integration Testing
Verifies the communication
paths and interactions
between components to
detect interface defects
Contract Testing
It is a test at the boundary of an
external service verifying that it
meets the contract expected by a
consuming service.
Payment Mock
IntegrationContractTestingScope
Test Double
Montebank
Cart
Component Testing
Unit
Testing
IntegrationTestingScope
Order
REST / HTTP or
Events / Kafka
Item ID,
Quantity,
Address..
Mock Order
Component Testing
A component test limits
the scope of the exercised
software to a portion of
the system under test.
Order
Payment
Unit
Testing
Firewall
Integration Testing Scope
REST / HTTP
Payment
Sandbox
Component
Testing

Behavior Driven Development
11-01-2021 157
Source: https://dannorth.net/introducing-bdd/
As an insurance Broker
I want to know who my Gold Customers are
So that I sell more
Given Customer John Doe exists
When
he buys insurance ABC for
$1000 USD
Then He becomes a Gold Customer
BDD Construct
As a Customer
I want to withdraw Cash from ATM
So that I don’t have to wait in line at the bank
Given
The account is in Credit
AND the Card is Valid
AND the dispenser contains Cash
BDD Construct
When The Customer requests Cash
Then
Ensure that the Account is debited
AND Ensure cash is dispensed
AND ensure that Card is returned.

Features of BDD
11-01-2021 158
• Focus on Behavior of the System
rather than tests.
• Collaboration between Business
Stake holders, Analysts,
Developers, QA.
• Ubiquitous Language
• Driven By Business Value
• Extends Test Driven Development
Source: https://cucumber.io/
Cucumber merges specification and
test documentation into one cohesive
whole.

Testing Strategy Summary
1/11/2021 159
1. Unit Testing
A unit test exercises the smallest piece of testable software.
2. Component Testing
A component test limits the scope of the exercised software to a portion
of the system under test.
3. Contract Testing
It is a test at the boundary of an external service verifying that it meets the
contract expected by a consuming service
4. Integration Testing
It verifies the communication paths and interactions between components
to detect interface defects.

1/11/2021 160
Security Best Practices
• DOCKER
• KUBERNETES

1/11/2021 161
Build Small Container Images
• Simple Java Web Apps with Ubuntu & Tomcat can have a size of
700 MB
• Use Alpine Image as your base Linux OS
• Alpine images are 10x smaller than base Ubuntu images
• Smaller Image size reduce the Container vulnerabilities.
• Ensure that only Runtime Environments are there in your
container. For Example your Alpine + Java + Tomcat image
should contain only the JRE and NOT JDK.
• Log the App output to Container Std out and Std error.
1

1/11/2021 162
Docker: To Root or Not to Root!
• Create Multiple layers of Images
• Create a User account
• Add Runtime software’s based on the User
Account.
• Run the App under the user account
• This gives added security to the container.
• Add Security module SELinux or AppArmour
to increase the security,
Alpine
JRE 8
Tomcat 8
My App 1
2

1/11/2021 163
Docker: Container Security
1. Secure your HOST OS! Containers runs on Host Kernel.
2. No Runtime software downloads inside the container.
Declare the software requirements at the build time itself.
3. Download Docker base images from Authentic site.
4. Limit the resource utilization using Container orchestrators
like Kubernetes.
5. Don’t run anything on Super privileged mode.
3

1/11/2021 164
Kubernetes: Naked Pods
• Never use a Naked Pod, that is Pod without any
ReplicaSet or Deployments. Naked pods will never
get re-scheduled if the Pod goes down.
• Never access a Pod directly from another Pod.
Always use a Service to access a Pod.
• User labels to select the pods { app: myapp, tier:
frontend, phase: test, deployment: v3 }.
• Never use :latest tag in the image in the
production scenario.
4

1/11/2021 165
Kubernetes: Namespace
default
Kube system
Kube public
Kubernetes Cluster• Group your Services / Pods / Traffic Rules based on
Specific Namespace.
• This helps you apply specific Network Policies for
that Namespace with increase in Security and
Performance.
• Handle specific Resource Allocations for a
Namespace.
• If you have more than a dozen Microservices then
it’s time to bring in Namespaces.
Service-Name.Namespace.svc.cluster.local
$ kubectl config set-context $(kubectl config current-context) --namespace=your-ns
The above command will let you switch the namespace to your namespace (your-ns).
5

1/11/2021 166
Kubernetes: Pod Health Check
• Pod Health check is critical to increase the overall
resiliency of the network.
• Readiness
• Liveness
• Ensure that all your Pods have Readiness and
Liveness Probes.
• Choose the Protocol wisely (HTTP, Command &
TCP)
6

1/11/2021 167
Kubernetes: Resource Utilization
• For the Best Quality define the requests and limits
for your Pods.
• You can set specific resource requests for a Dev
Namespace to ensure that developers don’t create
pods with a very large resource or a very small
resource.
• Limit Range can be set to ensure that containers
were create with too low resource or too large
resource.
7

1/11/2021 168
Kubernetes: Pod Termination Lifecycle
• Make sure that the Application to Handle SIGTERM
message.
• You can use preStop Hook
• Set the terminationGracePeriodSeconds: 60
• Ensure that you clean up the connections or any other
artefacts and ready for clean shutdown of the App
(Microservice).
• If the Container is still running after the grace period,
Kubernetes sends a SIGKILL event to shutdown the Pod.
8

1/11/2021 169
Kubernetes: External Services
• There are systems that can be outside the Kubernetes
cluster like
• Databases or
• external services in the cloud.
• You can create an Endpoint with Specific IP Address and
Port with the same name as Service.
• You can create a Service with an External Name (URL)
which does a CNAME redirection at the Kernel level.
9

1/11/2021 170
Kubernetes: Upgrade Cluster
• Make sure that the Master behind a Load Balancer.
• Upgrade Master
• Scale up the Node with an extra Node
• Drain the Node and
• Upgrade Node
• Cluster will be running even if the master is not working.
Only Kubectl and any master specific functions will be
down until the master is up.
10

171
OPS
• AGILE: KANBAN
• ITSM / DEVOPS
• SRE
4

1/11/2021 172
Kanban
• BOARDS AND CARDS
• KANBAN VS SCRUM
• BENEFITS OF KANBAN

1/11/2021 173
What is Kanban
Kanban is a method for managing the creation of
products with an emphasis on
• continual delivery while
• not overburdening the development team.
Like Scrum, Kanban is a process designed to help
teams work together more effectively.
Kanban is a visual management method that was developed by Hirotaka Takeuchi and Ikujiro
Nonaka

Microservices Architecture - Cloud Native Apps

Microservices Architecture - Cloud Native Apps

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Microservices Architecture - Cloud Native Apps

Similaire à Microservices Architecture - Cloud Native Apps (20)

Plus de Araf Karsh Hamid

Plus de Araf Karsh Hamid (19)

Dernier

Dernier (20)

Microservices Architecture - Cloud Native Apps

Notes de l'éditeur