Ahmed MISBAH - January 2023
Migrating to Microservices:
Patterns and Technologies
2023 edition
About the speaker
Role and previous talks
• Chief Software Engineer
• Independent Consultant and Coach
• Speaker at:
‣ DevOpsDays Cairo
‣ AMECSE
‣ Orange DevTest Days
‣ GDG
‣ Delta Technopreneurs
‣ JDC
About the speaker
Topics of interest
• Cloud-Native Apps and beyond
• Software Architecture
• DevOps
• Agile and Lean
• Java
• FOSS
• Arti
fi
cial Intelligence and ML
About the speaker
Experience
• 9 years at Orange Innovation Egypt
• Delivered two award winning innovative
solutions
• Worked at two startups
• Helped many others!
• Winner of Dell Hacktrick 2022 UI/UX track
• MSc. degree in ML and many other
professional certi
fi
cations
Nile University
J;.lll ~l:J.. Qtertifirate
(3/'~
This is to certify that
Ahmed Mahmoud Amir Misbah
••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••
Has successfully completed the program of study
and fulfilled the requirements for
BigData & Data Science Diploma
for the period from October 2015 to July 2016
...f:.!.l...~'!!~~!.tf....El..#.!(!.~.1..
INF Program Director
~~.__QI II
C.a.::::a..;r:q;;; AU J M
IW fl ,
: ~t '-M4'
October 2016 ·
····························••-
•··············
Date
Migrating to Microservices: Patterns and Technologies
Agenda
• Why migrate?
• The migration
• After the migration
Migrating to Microservices: Patterns and Technologies
Agenda
➡ Why migrate?
• The migration
• After the migration
Why migrate?
The future is Cloud-native!
Development Process Application Architecture Deployment and Packaging Application Infrastructure
Waterfall
Agile
DevOps
Monolithic
N-Tier | SOA
Microservices
Physical Servers
Virtual Server
Containers
Datacenter
Hosted
Cloud
Why migrate?
Why Microservices?
Microservices enable organizations to evolve their structure and technology
stack through structuring their application(s) as a collection of services that are:
• Organized around business capabilities
• Owned by a small team
• Independently deployable
• Loosely coupled
• Highly maintainable and testable
Why migrate?
Why Microservices?
• Microservices enable teams to work independently and in parallel, on
delivering capabilities that are functionally distinct.
• Reduced dependency among teams enables higher velocity in rolling out
features, thereby leading to faster time-to-market.
• Each team makes technology choices based on what suits them depending
upon factors like
fi
tment for the purpose, the team’s skill set, and several
others.
Why migrate?
Why Microservices?
• Technology Heterogeneity
• Ease of Deployment
• Scaling
• Robustness
• Composability
Why migrate?
More?
Migrating to Microservices: Patterns and Technologies
Agenda
• Why migrate?
➡ The migration
• After the migration
The migration
Microservice Architecture Challenges
1. Learning Curve
2. Monitoring
3. Troubleshooting and debugging
4. Handling failures
5. Security
6. Testing
7. Latency
8. Data Consistency
9. Infrastructure provisioning
10. Deployment
The migration
Non-functional requirements (NFRs)
Challenge Solution Technology
Monitoring, Troubleshooting,
Debugging
Observability ?
Handling failures
Design Patterns: Retry pattern, circuit
breaker pattern
?
Security Mutual TLS ?
Testing Chaos Engineering ?
Deployment Deployment Strategies ?
Scaling, Load Balancing Advanced Tra
ffi
c Management ?
The migration
Enter Service Mesh
• A Service Mesh is a dedicated communication layer for
facilitating service-to-service communications
between Microservices using a proxy (often as a Sidecar
or Ambassador).
• Having such a dedicated communication layer can provide
a number of bene
fi
ts, such as:
• Providing observability into communications,
• Providing secure connections,
• Automating retries and backo
ff
for failed requests,
• Tra
ffi
c management (e.g., Load Balancing),
• Many deployment strategies (Canary, blue-green, etc.),
• Separating the business logic of the application from
the previous points
The migration
Enter Istio
• Istio is an open source Service Mesh that helps
organizations run distributed, Microservices-
based apps anywhere.
• It enables organizations to secure, connect, and
monitor Microservices, so they can modernize
their enterprise applications more swiftly and
securely.
The migration
Why Istio?
• Tra
ffi
c Management
‣ Virtual Services
‣ Destination Rules
‣ Gateways
‣ Service enteries
‣ Sidecars
• Security (ICM, Authentication and Authorization)
• Observability (Metrics, Distributed Tracing,
Access Logs)
The migration
Why Istio?
• K8s native (i.e., extensibility and all other K8s
goodies)
• Free and Open Source (FOSS)
• Relies on other FOSS (Envoy, Jaeger,
Prometheus, Grafana, Kiali, etc.)
The migration
Migration Approaches
1. Big Bang Approach: Creating a new application from scratch
2. Incremental Approach: Gradually migrate to Microservice Architecture
Big Bang Approach Gradual Approach
The migration
Incremental Approach
• Monolithic functionalities can be extracted gradually to be implemented in
Microservices by splitting the monolithic application based on business
capabilities, teams, or sub-domain (DDD).
• Such Microservices include business functionalities exposed as API calls.
They can also access the monolithic database or have their own autonomous
database.
• Many patterns exist for splitting monolithic application. One of the most
useful and commonly used techniques is the Strangler Fig Application.
The migration
Strangler Fig Application Pattern
• The idea of Strangler Fig Application
Pattern is to have the new system
initially supported by the existing
system.
• The old and the new systems can
coexist, giving the new system time
to grow and potentially entirely
replace the old system.
The migration
Bene
fi
ts of Incremental Approach and Strangler Fig
• Allows new evolutions to be delivered during the migration phase.
• The new system will always be up-to-date.
• Zero Downtime Deployments (ZDD).
The migration
Stages of Strangler Fig Application Pattern
1. Identify: identify parts of the legacy
application that will be migrated. DDD can be
used to identify various bounded contexts
2. Transform: implement this functionality in a
new Microservice
3. Co-exist: leave the existing module in the
legacy application as is. Incrementally re-route
calls from the Monolith to the new Microservice
4. Eliminate: once the tra
ffi
c is completely
redirected to the microservice, eliminate the
legacy module
Sample Application
Sample Application
Sample Application
Assumptions
• Legacy application is a layered monolith
• Deployment will be on a public cloud
• K8s cluster is installed with Istio
• Legacy monolithic application does not run in a
container
• Complete DB decomposition will not be covered
+
Sample Application
What if it is not a Modulith?
Sample Application
Stage 1 - Identify
Sample Application
Stage 2 - Transform & Co-exist
• CI pipeline of application should be modi
fi
ed so
as to package monolithic application as a
container image and upload it to an artifact
repository or container registry
• CD pipeline should be con
fi
gured so as to
trigger the deployment of the application to K8s
• An Istio Ingress Gateway should be deployed
and con
fi
gured to route all tra
ffi
c to the
monolithic application
• DNS should be con
fi
gured so as to map your
domains to the new K8s cluster
K8s Node
K8s Pod
Envoy Proxy
Monolith
Cloud Load Balancer /
Istio Ingress Gateway
Clients
K8s Node
K8s Pod
Envoy Proxy
Monolith
Cloud Load Balancer /
Istio Ingress Gateway
Clients
K8s Node
K8s Pod
Envoy Proxy
Monolith
Cloud Load Balancer /
Istio Ingress Gateway
Clients
K8s Pod
Envoy Proxy
Microservice 1
Sample Application
Stage 4- Eliminate
K8s Node
K8s Pod
Envoy Proxy
Monolith
Cloud Load Balancer /
Istio Ingress Gateway
Clients
K8s Pod
Envoy Proxy
Microservice 1
No traf
fi
c to service 1
Sample Application
Let’s split another service!
• Legacy monolith now has only 3
services
• Service 2 will now be split into a
separate Microservice
• Service 2 business layer needs data
from business layer of Service 4
Sample Application
Branch by Abstraction pattern
Monolith Monolith
Service 4
business layer
functionality
abstraction
Monolith
Service 2
business
layer
functionality
abstraction
Service 2
business
layer
functionality
web service
client
Service 4
business
layer
functionality
web service
Microservice 2
Service 2
business
layer
functionality
abstraction
Service 2
business
layer
functionality
web service
client
Service 4
business
layer
functionality
web service
Envoy
Proxy
Envoy
Proxy
Monolith
K8s Node
K8s Pod
Envoy Proxy
Monolith
Cloud Load Balancer /
Istio Ingress Gateway
Clients
K8s Pod
Envoy Proxy
Microservice 2
K8s Pod
Envoy Proxy
Microservice 1
Microservice 2
Service 2
business
layer
functionality
abstraction
Service 2
business
layer
functionality
web service
client
Service 4
business
layer
functionality
web service
Envoy
Proxy
Envoy
Proxy
Envoy
Proxy
Monolith
Microservice 4
K8s Node
Cloud Load Balancer /
Istio Ingress Gateway
Clients
K8s Pod
Envoy Proxy
Microservice 2
K8s Pod
Envoy Proxy
Microservice 4
K8s Pod
Envoy Proxy
Microservice 3
K8s Pod
Envoy Proxy
Microservice 1
K8s Pod
Envoy Proxy
Monolith
K8s Node
Cloud Load Balancer /
Istio Ingress Gateway
Clients
K8s Pod
Envoy Proxy
Microservice 2
K8s Pod
Envoy Proxy
Microservice 4
K8s Pod
Envoy Proxy
Microservice 3
K8s Pod
Envoy Proxy
Microservice 1
Sample Application
DB Migration
• You can start with a shared DB,
• Then start decomposing the DB using a
pattern,
• Finally, you should end up with one DB per
Microservice.
• Istio Egress controller can be used to
control tra
ffi
c to the DB if it will be used as a
service and not deployed within the K8s
cluster
Cloud Load Balancer /
Istio Ingress Gateway
Clients
K8s Pod
Envoy Proxy
Microservice 2
K8s Pod
Envoy Proxy
Microservice 4
K8s Pod
Envoy Proxy
Microservice 3
K8s Pod
Envoy Proxy
Microservice 1
K8s Node
Istio Egress Gateway
Shared DB
Cloud Load Balancer /
Istio Ingress Gateway
Clients
K8s Pod
Envoy Proxy
Microservice 2
K8s Pod
Envoy Proxy
Microservice 4
K8s Pod
Envoy Proxy
Microservice 3
K8s Pod
Envoy Proxy
Microservice 1
K8s Node
Istio Egress Gateway
DB 1 DB 2 DB 3 DB 4
Sample Application
More on DB migration
Migrating to Microservices: Patterns and Technologies
Agenda
• Why migrate?
• The migration
➡ After the migration
Traffic Management
Traffic Management
Load Balancing
Traffic Management
Releases - Canary Releases
Traffic Management
Header-based Routing
Traffic Management
Rate Limiting
• Global Rate Limit
• Local Rate Limit
Chaos Engineering
Chaos Engineering
Fault Injection
• HTTP delay fault
• HTTP abort fault
Failure Handling
Failure Handling
Circuit Breaker
Security
Security
Features
• Certi
fi
cate Management
• Authentication
• Authorization
• TLS con
fi
guration
Observability
Observability
Kiali
Observability
Grafana
Observability
Prometheus
Observability
Jaeger
One last thing…….
It’s not all sunshine and roses!
Istio drawbacks and challenges
• Latency from adding sidecar proxies (solved by eBPF)
• Multi-cluster, multi-cloud, and multi-tenant support (solved by Tetrate)
• Con
fi
guring Control Plane components
• Sidecar proxy have many disadvantages (solved by Ambient Mesh)
• K8s lock-in
• Using only one of its features
Thank you!
References
References
My website
Scan QR to access my
website
Book a free call to arrange a workshop
• Microservice Architecture workshop
• Practical Microservices session
• Serverless Architectures workshop
• DevOps Maturity Assessment workshop
• DevOps for Enterprises workshop
• CI/CD workshop
• Hands-on DevOps mentorship
Scan to book a free call

Migrating to Microservices Patterns and Technologies (edition 2023)

  • 1.
    Ahmed MISBAH -January 2023 Migrating to Microservices: Patterns and Technologies 2023 edition
  • 2.
    About the speaker Roleand previous talks • Chief Software Engineer • Independent Consultant and Coach • Speaker at: ‣ DevOpsDays Cairo ‣ AMECSE ‣ Orange DevTest Days ‣ GDG ‣ Delta Technopreneurs ‣ JDC
  • 3.
    About the speaker Topicsof interest • Cloud-Native Apps and beyond • Software Architecture • DevOps • Agile and Lean • Java • FOSS • Arti fi cial Intelligence and ML
  • 4.
    About the speaker Experience •9 years at Orange Innovation Egypt • Delivered two award winning innovative solutions • Worked at two startups • Helped many others! • Winner of Dell Hacktrick 2022 UI/UX track • MSc. degree in ML and many other professional certi fi cations Nile University J;.lll ~l:J.. Qtertifirate (3/'~ This is to certify that Ahmed Mahmoud Amir Misbah •••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• Has successfully completed the program of study and fulfilled the requirements for BigData & Data Science Diploma for the period from October 2015 to July 2016 ...f:.!.l...~'!!~~!.tf....El..#.!(!.~.1.. INF Program Director ~~.__QI II C.a.::::a..;r:q;;; AU J M IW fl , : ~t '-M4' October 2016 · ····························••- •·············· Date
  • 5.
    Migrating to Microservices:Patterns and Technologies Agenda • Why migrate? • The migration • After the migration
  • 6.
    Migrating to Microservices:Patterns and Technologies Agenda ➡ Why migrate? • The migration • After the migration
  • 7.
    Why migrate? The futureis Cloud-native! Development Process Application Architecture Deployment and Packaging Application Infrastructure Waterfall Agile DevOps Monolithic N-Tier | SOA Microservices Physical Servers Virtual Server Containers Datacenter Hosted Cloud
  • 8.
    Why migrate? Why Microservices? Microservicesenable organizations to evolve their structure and technology stack through structuring their application(s) as a collection of services that are: • Organized around business capabilities • Owned by a small team • Independently deployable • Loosely coupled • Highly maintainable and testable
  • 9.
    Why migrate? Why Microservices? •Microservices enable teams to work independently and in parallel, on delivering capabilities that are functionally distinct. • Reduced dependency among teams enables higher velocity in rolling out features, thereby leading to faster time-to-market. • Each team makes technology choices based on what suits them depending upon factors like fi tment for the purpose, the team’s skill set, and several others.
  • 10.
    Why migrate? Why Microservices? •Technology Heterogeneity • Ease of Deployment • Scaling • Robustness • Composability
  • 11.
  • 12.
    Migrating to Microservices:Patterns and Technologies Agenda • Why migrate? ➡ The migration • After the migration
  • 13.
    The migration Microservice ArchitectureChallenges 1. Learning Curve 2. Monitoring 3. Troubleshooting and debugging 4. Handling failures 5. Security 6. Testing 7. Latency 8. Data Consistency 9. Infrastructure provisioning 10. Deployment
  • 14.
    The migration Non-functional requirements(NFRs) Challenge Solution Technology Monitoring, Troubleshooting, Debugging Observability ? Handling failures Design Patterns: Retry pattern, circuit breaker pattern ? Security Mutual TLS ? Testing Chaos Engineering ? Deployment Deployment Strategies ? Scaling, Load Balancing Advanced Tra ffi c Management ?
  • 15.
    The migration Enter ServiceMesh • A Service Mesh is a dedicated communication layer for facilitating service-to-service communications between Microservices using a proxy (often as a Sidecar or Ambassador). • Having such a dedicated communication layer can provide a number of bene fi ts, such as: • Providing observability into communications, • Providing secure connections, • Automating retries and backo ff for failed requests, • Tra ffi c management (e.g., Load Balancing), • Many deployment strategies (Canary, blue-green, etc.), • Separating the business logic of the application from the previous points
  • 16.
    The migration Enter Istio •Istio is an open source Service Mesh that helps organizations run distributed, Microservices- based apps anywhere. • It enables organizations to secure, connect, and monitor Microservices, so they can modernize their enterprise applications more swiftly and securely.
  • 17.
    The migration Why Istio? •Tra ffi c Management ‣ Virtual Services ‣ Destination Rules ‣ Gateways ‣ Service enteries ‣ Sidecars • Security (ICM, Authentication and Authorization) • Observability (Metrics, Distributed Tracing, Access Logs)
  • 18.
    The migration Why Istio? •K8s native (i.e., extensibility and all other K8s goodies) • Free and Open Source (FOSS) • Relies on other FOSS (Envoy, Jaeger, Prometheus, Grafana, Kiali, etc.)
  • 19.
    The migration Migration Approaches 1.Big Bang Approach: Creating a new application from scratch 2. Incremental Approach: Gradually migrate to Microservice Architecture Big Bang Approach Gradual Approach
  • 20.
    The migration Incremental Approach •Monolithic functionalities can be extracted gradually to be implemented in Microservices by splitting the monolithic application based on business capabilities, teams, or sub-domain (DDD). • Such Microservices include business functionalities exposed as API calls. They can also access the monolithic database or have their own autonomous database. • Many patterns exist for splitting monolithic application. One of the most useful and commonly used techniques is the Strangler Fig Application.
  • 21.
    The migration Strangler FigApplication Pattern • The idea of Strangler Fig Application Pattern is to have the new system initially supported by the existing system. • The old and the new systems can coexist, giving the new system time to grow and potentially entirely replace the old system.
  • 22.
    The migration Bene fi ts ofIncremental Approach and Strangler Fig • Allows new evolutions to be delivered during the migration phase. • The new system will always be up-to-date. • Zero Downtime Deployments (ZDD).
  • 23.
    The migration Stages ofStrangler Fig Application Pattern 1. Identify: identify parts of the legacy application that will be migrated. DDD can be used to identify various bounded contexts 2. Transform: implement this functionality in a new Microservice 3. Co-exist: leave the existing module in the legacy application as is. Incrementally re-route calls from the Monolith to the new Microservice 4. Eliminate: once the tra ffi c is completely redirected to the microservice, eliminate the legacy module
  • 24.
  • 25.
  • 26.
    Sample Application Assumptions • Legacyapplication is a layered monolith • Deployment will be on a public cloud • K8s cluster is installed with Istio • Legacy monolithic application does not run in a container • Complete DB decomposition will not be covered +
  • 27.
    Sample Application What ifit is not a Modulith?
  • 28.
  • 29.
    Sample Application Stage 2- Transform & Co-exist • CI pipeline of application should be modi fi ed so as to package monolithic application as a container image and upload it to an artifact repository or container registry • CD pipeline should be con fi gured so as to trigger the deployment of the application to K8s • An Istio Ingress Gateway should be deployed and con fi gured to route all tra ffi c to the monolithic application • DNS should be con fi gured so as to map your domains to the new K8s cluster K8s Node K8s Pod Envoy Proxy Monolith Cloud Load Balancer / Istio Ingress Gateway Clients
  • 30.
    K8s Node K8s Pod EnvoyProxy Monolith Cloud Load Balancer / Istio Ingress Gateway Clients
  • 31.
    K8s Node K8s Pod EnvoyProxy Monolith Cloud Load Balancer / Istio Ingress Gateway Clients K8s Pod Envoy Proxy Microservice 1
  • 33.
    Sample Application Stage 4-Eliminate K8s Node K8s Pod Envoy Proxy Monolith Cloud Load Balancer / Istio Ingress Gateway Clients K8s Pod Envoy Proxy Microservice 1 No traf fi c to service 1
  • 34.
    Sample Application Let’s splitanother service! • Legacy monolith now has only 3 services • Service 2 will now be split into a separate Microservice • Service 2 business layer needs data from business layer of Service 4
  • 35.
    Sample Application Branch byAbstraction pattern Monolith Monolith Service 4 business layer functionality abstraction Monolith Service 2 business layer functionality abstraction Service 2 business layer functionality web service client Service 4 business layer functionality web service
  • 36.
    Microservice 2 Service 2 business layer functionality abstraction Service2 business layer functionality web service client Service 4 business layer functionality web service Envoy Proxy Envoy Proxy Monolith
  • 37.
    K8s Node K8s Pod EnvoyProxy Monolith Cloud Load Balancer / Istio Ingress Gateway Clients K8s Pod Envoy Proxy Microservice 2 K8s Pod Envoy Proxy Microservice 1
  • 38.
    Microservice 2 Service 2 business layer functionality abstraction Service2 business layer functionality web service client Service 4 business layer functionality web service Envoy Proxy Envoy Proxy Envoy Proxy Monolith Microservice 4
  • 39.
    K8s Node Cloud LoadBalancer / Istio Ingress Gateway Clients K8s Pod Envoy Proxy Microservice 2 K8s Pod Envoy Proxy Microservice 4 K8s Pod Envoy Proxy Microservice 3 K8s Pod Envoy Proxy Microservice 1 K8s Pod Envoy Proxy Monolith
  • 40.
    K8s Node Cloud LoadBalancer / Istio Ingress Gateway Clients K8s Pod Envoy Proxy Microservice 2 K8s Pod Envoy Proxy Microservice 4 K8s Pod Envoy Proxy Microservice 3 K8s Pod Envoy Proxy Microservice 1
  • 41.
    Sample Application DB Migration •You can start with a shared DB, • Then start decomposing the DB using a pattern, • Finally, you should end up with one DB per Microservice. • Istio Egress controller can be used to control tra ffi c to the DB if it will be used as a service and not deployed within the K8s cluster
  • 42.
    Cloud Load Balancer/ Istio Ingress Gateway Clients K8s Pod Envoy Proxy Microservice 2 K8s Pod Envoy Proxy Microservice 4 K8s Pod Envoy Proxy Microservice 3 K8s Pod Envoy Proxy Microservice 1 K8s Node Istio Egress Gateway Shared DB
  • 43.
    Cloud Load Balancer/ Istio Ingress Gateway Clients K8s Pod Envoy Proxy Microservice 2 K8s Pod Envoy Proxy Microservice 4 K8s Pod Envoy Proxy Microservice 3 K8s Pod Envoy Proxy Microservice 1 K8s Node Istio Egress Gateway DB 1 DB 2 DB 3 DB 4
  • 44.
  • 45.
    Migrating to Microservices:Patterns and Technologies Agenda • Why migrate? • The migration ➡ After the migration
  • 46.
  • 47.
  • 48.
  • 49.
  • 50.
    Traffic Management Rate Limiting •Global Rate Limit • Local Rate Limit
  • 51.
  • 52.
    Chaos Engineering Fault Injection •HTTP delay fault • HTTP abort fault
  • 53.
  • 54.
  • 55.
  • 56.
    Security Features • Certi fi cate Management •Authentication • Authorization • TLS con fi guration
  • 57.
  • 58.
  • 59.
  • 60.
  • 61.
  • 62.
  • 63.
    It’s not allsunshine and roses! Istio drawbacks and challenges • Latency from adding sidecar proxies (solved by eBPF) • Multi-cluster, multi-cloud, and multi-tenant support (solved by Tetrate) • Con fi guring Control Plane components • Sidecar proxy have many disadvantages (solved by Ambient Mesh) • K8s lock-in • Using only one of its features
  • 64.
  • 65.
  • 66.
  • 67.
    My website Scan QRto access my website
  • 68.
    Book a freecall to arrange a workshop • Microservice Architecture workshop • Practical Microservices session • Serverless Architectures workshop • DevOps Maturity Assessment workshop • DevOps for Enterprises workshop • CI/CD workshop • Hands-on DevOps mentorship Scan to book a free call