Uploaded byAhmed Misbah
Migrating to Microservices Patterns and Technologies (edition 2023)
The document outlines a presentation by Ahmed Misbah on migrating to microservices, emphasizing the benefits, challenges, and various migration strategies like the incremental approach and strangler fig pattern. It covers the advantages of microservices such as independent deployability and reduced team dependencies, as well as the technologies involved, particularly Istio for service mesh management. The presentation also addresses potential challenges and the solutions for successful migration, including observability and security aspects.
More Related Content
![[Konveyor] migrate and modernize your application portfolio to kubernetes wit...](https://cdn.slidesharecdn.com/ss_thumbnails/konveyormigrateandmodernizeyourapplicationportfoliotokuberneteswithtackle-210728162324-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Migrating to Microservices Patterns and Technologies (edition 2023)
Migrating to Microservices Patterns and Technologies (edition 2023)
- 1. Ahmed MISBAH -January 2023 Migrating to Microservices: Patterns and Technologies 2023 edition
- 2. About the speaker Roleand 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 Topicsof 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 futureis 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? Microservicesenable 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.
- 12. Migrating to Microservices:Patterns and Technologies Agenda • Why migrate? ➡ The migration • After the migration
- 13. The migration Microservice ArchitectureChallenges 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 ServiceMesh • 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 FigApplication 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 ofIncremental 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 ofStrangler 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.
- 25.
- 26. Sample Application Assumptions • Legacyapplication 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 ifit 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 EnvoyProxy Monolith Cloud Load Balancer / Istio Ingress Gateway Clients
- 31. K8s Node K8s Pod EnvoyProxy 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 splitanother 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 byAbstraction 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 Service2 business layer functionality web service client Service 4 business layer functionality web service Envoy Proxy Envoy Proxy Monolith
- 37. K8s Node K8s Pod EnvoyProxy 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 Service2 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 LoadBalancer / 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 LoadBalancer / 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 onDB migration
- 45. Migrating to Microservices:Patterns and Technologies Agenda • Why migrate? • The migration ➡ After the migration
- 46.
- 47.
- 48. Traffic Management Releases -Canary Releases
- 49.
- 50. Traffic Management Rate Limiting •Global Rate Limit • Local Rate Limit
- 51.
- 52. Chaos Engineering Fault Injection •HTTP delay fault • HTTP abort fault
- 53.
- 54.
- 55.
- 56. Security Features • Certi fi cate Management •Authentication • Authorization • TLS con fi guration
- 57.
- 58.
- 59.
- 60.
- 61.
- 62.
- 63. It’s not allsunshine 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.
- 65.
- 66.
- 67. My website Scan QRto access my website
- 68. Book a freecall 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