This session is targeted towards teams and organizations considering to migrate their applications from monolithic to Microservice architecture by proposing Istio as an enabler. Istio is an implementation of service mesh, a technology useful for migrating to Microservices iteratively and safely. 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. This session explains how Istio can be used as a bridge and enabler for modernizing legacy monolithic applications to Microservices. Topics covered in the session will include: 1- Advantages of migrating to Microservices and service mesh . 2- Designing a Microservice application based on splitting an existing monolithic application. 3- Implementing Microservices iteratively as a strangler fig application with Istio. 4- Features Istio provides as a service mesh platform.

1. Ahmed MISBAH - 22/09/2022
Istio as an enabler for migrating
to Microservices
2022 edition

2. About the speaker
Role and previous talks
• Chief Software Engineer
• Speaker at:
‣ DevOpsDays Cairo
‣ AMECSE
‣ Orange DevTest Days
‣ GDG
‣ Delta Technopreneurs
‣ JDC

3. About the speaker
Topics of interest
• DevOps
• Agile and Lean
• Cloud-Native Apps and beyond
• Software Architecture
• 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. Istio as an enabler for migrating to Microservices
Agenda
• Why migrate?
• The migration
• After the migration

6. Istio as an enabler for migrating to Microservices
Agenda
➡ Why migrate?
• The migration
• After the migration

7. Why migrate?
Digital Transformation - Past and Present
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?
• Technology Heterogeneity
• Ease of Deployment
• Scaling
• Robustness
• Composability

10. Istio as an enabler for migrating to Microservices
Agenda
• Why migrate?
➡ The migration
• After the migration

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

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

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

14. The migration
Enter Istio
Istio is an open source Service Mesh that helps organizations run distributed,
Microservices-based apps anywhere. Istio enables organizations to secure,
connect, and monitor Microservices, so they can modernize their enterprise
applications more swiftly and securely.

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

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

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

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

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

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

21. 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 micro service
4. Eliminate: once the tra
ffi
c is completely
redirected to the micro service, eliminate the
legacy module

22. Sample Application

23. Sample Application

24. Sample Application
Assumptions
• Legacy application is a modular 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
+

25. Sample Application
Stage 1 - Identify

26. Sample Application
Stage 2 & 3 - 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

27. K8s Node
K8s Pod
Envoy Proxy
Monolith
Cloud Load Balancer /
Istio Ingress Gateway
Clients

28. K8s Node
K8s Pod
Envoy Proxy
Monolith
Cloud Load Balancer /
Istio Ingress Gateway
Clients
K8s Pod
Envoy Proxy
Microservice 1

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

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

31. Sample Application
Stage 4 - Eliminate
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

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

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

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

35. Istio as an enabler for migrating to Microservices
Agenda
• Why migrate?
• The migration
➡ After the migration

36. Traffic Management

37. Traffic Management
Load Balancing

38. Traffic Management
Releases - Canary Releases

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

40. Chaos Engineering

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

42. Failure Handling

43. Failure Handling
Circuit Breaker

44. Security

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

46. Observability

47. Observability
Kiali

48. Observability
Grafana

49. Observability
Prometheus

50. Observability
Jaeger

51. One last thing…….

52. 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
• K8s lock-in
• Using only one of its features

53. Thank you!

54. References

56. Book a free call to arrange a workshop
• DevOps Maturity Assessment workshop
• DevOps for Enterprises workshop
• Microservice Architecture workshop
• Serverless Architectures workshop
• CI/CD workshop
• Hands-on DevOps mentorship
Scan to book a free call