Download to read offline
Uploaded byAhmed Misbah
Istio as an Enabler for Migrating Monolithic Applications to Microservices v1.3
The document discusses migrating legacy monolithic applications to microservices, emphasizing the architectural transformation facilitated by Istio and Kubernetes. It outlines the challenges, advantages, and a step-by-step approach for effective migration, including the 'strangler fig' pattern for gradual extraction of services. The conclusion highlights Istio's role as a powerful tool for enabling service mesh architecture and improving application resilience and scalability.
In this document
Powered by AI
Introduction by Ahmed Misbah on Istio for migrating applications to microservices.
Ahmed Misbah’s background as a software architect and interests in DevOps, Agile, and Java.
Overview of IT transformation areas including development process, architecture, and deployment.
Definitions and benefits of microservice architecture, including challenges like developer experience and testing.
Key technologies for microservices: containers, orchestration tools, service mesh, and their benefits.
Two approaches to migration: Big Bang and Gradual, emphasizing the use of the Strangler Fig pattern.
Description of the Strangler Fig pattern for gradually migrating from monolithic to microservices.
Benefits of using Istio for service mesh including traffic management and security measures for microservices.
Detailed steps in migrating a monolithic application to microservices using Kubernetes and Istio.
Strategies for database migration alongside applications, from shared DBs to per microservice models.
Enhanced features in microservices migration such as load balancing, canary releases, and monitoring tools.
Conclusion on the significance of migrating to microservices and the enabling role of Istio.
References for further reading and acknowledgement of the presenter’s social media and contact information.
More Related Content
![[Retail & CPG Day 2019] AWS기반의 Data 분석 플랫폼 구축, 고객사례 (GS SHOP) -김형일, AWS 솔루션즈 ...](https://cdn.slidesharecdn.com/ss_thumbnails/gsshop-191024042351-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Istio as an Enabler for Migrating Monolithic Applications to Microservices v1.3
![[WSO2Con Asia 2018] Adaptive and Iterative Integration for Microservices and ...](https://cdn.slidesharecdn.com/ss_thumbnails/adaptiveanditerativeintegrationformicroservicesandcloudnativearchitectures-wso2conasia2018-chanakaf-180810102245-thumbnail.jpg?width=640&height=640&fit=bounds)
Istio as an Enabler for Migrating Monolithic Applications to Microservices v1.3
- 1. Ahmed MISBAH -04/04/2021 Istio as an Enabler for Migrating Monolithic Applications to Microservices V1.3
- 2. 2 A little aboutme Areas of Transformation in the IT World Migrating Legacy Monolithic Applications to Microservices Theory Design Implementation using Istio Conclusions Agenda
- 3. 3 A little aboutme 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 ofinterest: • DevOps • Agile and Lean • Software Architecture • Java A little about me
- 6. 6 A little aboutme Areas of Transformation in the IT World Migrating Legacy Monolithic Applications to Microservices Theory Design Implementation using Istio Conclusions Agenda
- 7. Areas of Transformationin 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 aboutme Areas of Transformation in the IT World Migrating Legacy Monolithic Applications to Microservices Theory Design Implementation using Istio Conclusions Agenda
- 10. Microservices - alsoknown 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 PainPoints 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 DesignPatterns
- 14. Microservice Architecture EnablingTechnology • 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 Tosum 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 aboutme Areas of Transformation in the IT World Migrating Legacy Monolithic Applications to Microservices Theory Design Implementation using Istio Conclusions Agenda
- 18. Migration Approaches Big BangApproach Gradual Approach
- 19. Problems with BigBang 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 functionalitiescan 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 acertain 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 Inthe 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 StranglerFig 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 aboutme Areas of Transformation in the IT World Migrating Legacy Monolithic Applications to Microservices Theory Design Implementation using Istio Conclusions Agenda
- 25. Why Istio? (1) Offerseverything 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) K8snative (i.e. extensibility and all other K8s goodies) (3) FOSS (4) Relies on other FOSS (Envoy, Jaeger, Prometheus, Grafana, Kiali, etc.)
- 27. Migrating to Microservicesusing 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.
- 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 CloudLoad 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 theDB? • 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 andDB 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 andDBs 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 MonolithicApplications to Microservices Other goodies • Load Balancing • Canary Releases • Fault Injection • Circuit Breaking • Mutual TLS
- 45. Migrating Legacy MonolithicApplications to Microservices Kiali
- 46. Migrating Legacy MonolithicApplications to Microservices Grafana
- 47. Migrating Legacy MonolithicApplications to Microservices Prometheus
- 48. Migrating Legacy MonolithicApplications to Microservices Jaeger
- 49. 49 A little aboutme Areas of Transformation in the IT World Migrating Legacy Monolithic Applications to Microservices Theory Design Implementation using Istio Conclusions Agenda
- 50. Conclusions • Migrating toMicroservices 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.
- 52.