Istio as an enabler for migrating to microservices (edition 2022)

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

About the speaker
Role and previous talks
• Chief Software Engineer

• Speaker at:

‣ DevOpsDays Cairo

‣ AMECSE

‣ Orange DevTest Days

‣ GDG

‣ Delta Technopreneurs

‣ JDC

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

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

Istio as an enabler for migrating to Microservices
Agenda
• Why migrate?

• The migration

• After the migration

Agenda
➡ Why migrate?

• The migration


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

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?
• Technology Heterogeneity

• Ease of Deployment

• Scaling

• Robustness

• Composability

Agenda
• Why migrate?

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

• 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. Istio 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 micro service

4. Eliminate: once the tra
ffi
c is completely
redirected to the micro service, eliminate the
legacy module

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
+

Sample Application
Stage 1 - Identify

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

K8s Node
K8s Pod
Envoy Proxy
Monolith

Clients

K8s Node
K8s Pod
Envoy Proxy
Monolith

Clients
K8s Pod
Envoy Proxy
Microservice 1

K8s Node
K8s Pod
Envoy Proxy
Monolith

Clients
K8s Pod
Envoy Proxy
Microservice 2
K8s Pod
Envoy Proxy
Microservice 1

K8s Node

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

Sample Application
Stage 4 - Eliminate
K8s Node

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


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


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

Agenda
• Why migrate?

• The migration

➡ After the migration

Traffic Management
Load Balancing

Traffic Management
Releases - Canary Releases

Traffic Management
Rate Limiting
• Global Rate Limit

• Local Rate Limit

Chaos Engineering
Fault Injection
• HTTP delay fault

• HTTP abort fault

Failure Handling
Circuit Breaker

Security
Features
• Certi
fi
cate Management

• Authentication

• Authorization

• TLS con
fi
guration

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

Istio as an enabler for migrating to microservices (edition 2022)

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

Istio as an enabler for migrating to microservices (edition 2022)

Recommended

More Related Content

Similar to Istio as an enabler for migrating to microservices (edition 2022) (20)

More from Ahmed Misbah (20)

Recently uploaded (20)

Istio as an enabler for migrating to microservices (edition 2022)