This session is targeted towards teams and organizations considering to migrate their applications from Monolithic to Microservice architecture. Migrating application architectures to Microservices is considered a key area of transformation in the IT world. Modernizing legacy applications to Kubernetes-based Microservices can prove to be very challenging if not planned correctly, taking into consideration the right technologies and enablers. The session proposes Istio as an enabler for migrating to Microservices. Istio is an implementation of service mesh, a technology useful for migrating to Microservices iteratively and safely. We explain how Istio can be used as a bridge and enabler for modernizing legacy Monolithic applications to Microservices.

1. Ahmed MISBAH - January 2023
Migrating to Microservices:
Patterns and Technologies
2023 edition

2. 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

3. 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

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 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

8. 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

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. Why migrate?
More?

12. Migrating to Microservices: Patterns and Technologies
Agenda
• Why migrate?
➡ The migration
• After the migration

13. 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

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 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

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 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.

22. 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).

23. 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

24. Sample Application

25. Sample Application

26. 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
+

27. Sample Application
What if it is not a Modulith?

28. Sample Application
Stage 1 - Identify

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
Envoy Proxy
Monolith
Cloud Load Balancer /
Istio Ingress Gateway
Clients

31. K8s Node
K8s Pod
Envoy Proxy
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 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

35. 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

36. 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

37. 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

38. 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

39. 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

40. 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

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. Sample Application
More on DB migration

45. Migrating to Microservices: Patterns and Technologies
Agenda
• Why migrate?
• The migration
➡ After the migration

46. Traffic Management

47. Traffic Management
Load Balancing

48. Traffic Management
Releases - Canary Releases

49. Traffic Management
Header-based Routing

50. Traffic Management
Rate Limiting
• Global Rate Limit
• Local Rate Limit

51. Chaos Engineering

52. Chaos Engineering
Fault Injection
• HTTP delay fault
• HTTP abort fault

53. Failure Handling

54. Failure Handling
Circuit Breaker

55. Security

56. Security
Features
• Certi
fi
cate Management
• Authentication
• Authorization
• TLS con
fi
guration

57. Observability

58. Observability
Kiali

59. Observability
Grafana

60. Observability
Prometheus

61. Observability
Jaeger

62. One last thing…….

63. 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

64. Thank you!

65. References

66. References

67. My website
Scan QR to access my
website

68. 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