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 an enabler for modernizing legacy monolithic applications to microservices. Topics covered in the presentation 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

1. Ahmed MISBAH - 04/04/2021
Istio as an Enabler for Migrating
Monolithic Applications to
Microservices
V1.3

2. 2
A little about me
Areas of Transformation in the IT World
Migrating Legacy Monolithic Applications to Microservices
Theory
Design
Implementation using Istio
Conclusions
Agenda

3. 3
A little about me
Areas of Transformation in the IT World
Migrating Legacy Monolithic Applications to Microservices
Theory
Design
Implementation using Istio
Conclusions
Agenda

4. • Software Architect
• Speaker at:
• DevOpsDays Cairo
• Africa and Middle East Conference
on Software Engineering
• Orange DevTest Days
• Java Developer Conference
• Google Developer Group
A little about me

5. • Topics of interest:
• DevOps
• Agile and Lean
• Software Architecture
• Java
A little about me

6. 6
A little about me
Areas of Transformation in the IT World
Migrating Legacy Monolithic Applications to Microservices
Theory
Design
Implementation using Istio
Conclusions
Agenda

7. Areas of Transformation in the IT World
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

9. 9
A little about me
Areas of Transformation in the IT World
Migrating Legacy Monolithic Applications to Microservices
Theory
Design
Implementation using Istio
Conclusions
Agenda

10. Microservices - also known as Microservice Architecture - is an architectural
style that structures an application as a collection of services that are:
• Highly maintainable and testable
• Loosely coupled
• Independently deployable
• Organized around business capabilities or bounded context
• Owned by a small teams
What is Microservice Architecture?

11. Why Microservice Architecture?
• Technology Heterogeneity
• Robustness
• Scaling
• Ease of Deployment
• Organizational Alignment
• Composability

12. Microservice Architecture Pain Points
1. Developer Experience
2. Technology Overload (i.e. Complexity)
3. Monitoring and Troubleshooting
4. Handling failure
5. Security
6. Testing
7. Latency
8. Data Consistency

13. Microservice Architecture Design Patterns

14. Microservice Architecture Enabling Technology
• Containers (e.g. Docker)
• Container Orchestration (e.g. Kubernetes)
• Service Mesh (e.g. Istio)
• Message Broker and Streaming (e.g. Kafka)
• Public Cloud (e.g. AWS)

15. Enter Service Mesh
• A Service Mesh is a dedicated infrastructure /
communication layer for facilitating service-to-
service communications
between services or microservices, using
a proxy (often as a sidecar).
• Having such a dedicated communication layer
can provide a number of benefits, such as:
• Providing observability into communications,
• Providing secure connections,
• Automating retries and backoff for failed
requests,
• Traffic management,
• Separating the business logic of the application
from the previous points

16. Enter Service Mesh
To sum up, a Service Mesh offers the ability to:
• Connect: The ability for services to discover and talk
to each other. It enables intelligent routing to control
the flow of traffic and API calls between services/
endpoints. These also enable advanced deployment
strategies such as blue/green, canaries or rolling
upgrades, and more.
• Secure: The ability to secure communication
between services. It can enforce policies to allow or
deny communication.
• Monitor: Enables observability of your distributed
microservices system. Service Mesh often integrates
out-of-the-box with monitoring and tracing tools
(such as Prometheus and Jaeger in the case of K8s/
Istio) to allow you to discover and visualize
dependencies between services, traffic flow, API
latencies, and tracing.

17. 17
A little about me
Areas of Transformation in the IT World
Migrating Legacy Monolithic Applications to Microservices
Theory
Design
Implementation using Istio
Conclusions
Agenda

18. Migration Approaches
Big Bang Approach Gradual Approach

19. Problems with Big Bang Approach
1.Probably a lot of time has been spent and a lot of work has been done so that
the monolithic application could meet the business needs to date. Therefore,
considerable effort is also required for it to be developed in the new
architecture.
2.It will be almost impossible to make the current monolithic application stop
evolving to wait for the new microservice based application to be ready for use.
3.Furthermore, it is very likely that at the end of the development process the
new application is out of date with the current business needs due to the time
spent.

20. Gradual Approach
Monolithic functionalities can be extracted gradually to be implemented in
microservices by splitting the monolithic application into layers. 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. Strangler Fig
Is a certain type of fig that seeds itself in the upper branches of trees. The
fig then descends toward the ground to take root, gradually enveloping the
original tree. The existing tree becomes initially a support structure for the
new fig, and if taken to the final stages, you may see the original tree die
and rot away, leaving only the new, now self-supporting fig in its place.

22. Strangler Fig Application
In the context of software, the parallel here is to have our new system
initially be supported by, and wrapping, the existing system. The idea is
that the old and the new can coexist, giving the new system time to
grow and potentially entirely replace the old system.

23. 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 traffic is completely
redirected to the micro service, eliminate the
legacy module

24. 24
A little about me
Areas of Transformation in the IT World
Migrating Legacy Monolithic Applications to Microservices
Theory
Design
Implementation using Istio
Conclusions
Agenda

25. Why Istio?
(1) Offers everything you need from a service mesh:
• Traffic Management
• Virtual Services
• Destination Rules
• Gateways
• Service enteries
• Sidecars
• Security (ICM, Authentication and Authorization)
• Observability (Metrics, Distributed Tracing, Access
Logs)

26. Why Istio?
(2) K8s native (i.e. extensibility and all other K8s goodies)
(3) FOSS
(4) Relies on other FOSS (Envoy, Jaeger, Prometheus,
Grafana, Kiali, etc.)

27. Migrating to Microservices using K8s + Istio
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
• Strangler Fig Application Pattern will be used for
splitting the monolithic application
• Complete DB decomposition will not be covered
+

28. The sample application

29. Step 1 - Deploy monolithic application to K8s
• CI pipeline of application should be modified so
as to package monolithic application as a
container image and upload it to an artifact
repository or container registry
• CD pipeline should be configured so as to
trigger the deployment of the application to K8s
• An Istio Ingress Gateway should be deployed
and configured to route all traffic to the
monolithic application
• DNS should be configured 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. Step 1 - Deploy monolithic application to K8s
K8s Node
K8s Pod
Envoy Proxy
Monolith
Cloud Load Balancer /
Istio Ingress Gateway
Clients

31. Step 2 - Split Service 1
• Sample applications consists of 4 services
• Service 1 will be split from the monolith
• Istio Ingress Gateway will be configured to
route traffic from legacy Service 1
endpoints to new Microservice 1

32. Step 2 - Split Service 1
K8s Node
K8s Pod
Envoy Proxy
Monolith
Cloud Load Balancer /
Istio Ingress Gateway
Clients
K8s Pod
Envoy Proxy
Microservice 1

33. Step 3 - Split Service 2
• 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. Here, we will have one of the following cases:
(1) Presentation layer exposes business layer
functionalities as web services
(2) Business layer functionalities exposed as web services
(3) Presentation layer does not expose business layer
functionalities as web services
(4) Business layer functionalities are not exposed as web
services and are called as functions/methods

34. Step 3 - Split Service 2 - Cases 1 and 2
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

35. Step 3 - Split Service 2 - Cases 3 and 4
• “Branch by Abstraction” pattern will be
used
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. Step 3 - Split Service 2 - Cases 3 and 4
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. Step 4 - Split Service 4
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

38. Step 4 - Split Service 4
Microservice 2
Envoy
Proxy
Envoy
Proxy
Envoy
Proxy
Monolith
Microservice 4
Envoy
Proxy
Microservice 1

39. Step 5 - Split Service 3
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. Hurray !!
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. What about the DB?
• 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 traffic to the DB if it will be used as
a service and not deployed within the K8s
cluster

42. K8s cluster and DB on the same VPC
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. K8s cluster and DBs on the same VPC
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. Migrating Legacy Monolithic Applications to Microservices
Other goodies
• Load Balancing
• Canary Releases
• Fault Injection
• Circuit Breaking
• Mutual TLS

45. Migrating Legacy Monolithic Applications to Microservices
Kiali

46. Migrating Legacy Monolithic Applications to Microservices
Grafana

47. Migrating Legacy Monolithic Applications to Microservices
Prometheus

48. Migrating Legacy Monolithic Applications to Microservices
Jaeger

49. 49
A little about me
Areas of Transformation in the IT World
Migrating Legacy Monolithic Applications to Microservices
Theory
Design
Implementation using Istio
Conclusions
Agenda

50. Conclusions
• Migrating to Microservices is a hot area in Application Architecture
transformation
• Migration to Microservices requires lots of enablers, such as containerization
and container orchestration on the cloud
• Service mesh adds a lot of benefits to your software architecture
• Istio is a wonderful enabler for migrating to microservices and service mesh
architecture; offering the capability to implement a lot of patterns easily

51. References

52. Thank You!
https://twitter.com/AhmedMisbahTech https://www.linkedin.com/in/ahmed-
misbah-msc-251a3a32/
https://www.youtube.com/channel/UCZxEB
qvA1fGKLusLwoadf_w