Service mesh in Microservice World to Manage end to end service communications
- 1. Microservices Architecture S e r v i c e M e s h M a n a g i n g S e r v i c e - t o - S e r v i c e c o m m u n i c a t i o n s i n M i c r o s e r v i c e s w o r l d “Microservices architecture describes a way to design software applications as suites of independently deployable services.” - Martin Fowler Satya SYAM
- 2. AGENDA S E R V I C E M E S H Revisit the Microservice architecture M I C R O S E R V I C E S A R C H I T E C T U R E What problems Service Mesh solves? S E R V I C E M E S H What are the challenges of Microservice architecture M I C R O S E R V I C E S C O N C E R N S What are service mesh implementations? 30000 FT view of ISTIO S E R V I C E M E S H I M P L E M E N T A T I O N S Decision Tree & Key Takeaway C O N C L U S I O N
- 3. M I C R O S E R V I C E S A R C H I T E C T U R E Business Logic Monolithic Architecture User Interface Data Interface User Interface Microservice Microservice Microservice Microservice Microservices Architecture Database per service
- 4. M I C R O S E R V I C E S C O N C E R N S Microservice Operations Code Business Logic • These are cross cutting concerns applications to microservices and are necessary to implement microservices. • These operations code could be common to most of the microservices • Business functionality implemented as part of the services • The actual implementation of what service is all about • Developers should focus on this area Operations Code Business Logic R O U T I N G A B • Traffic Control • Resilience • Discovery S E C U R I T Y A B • Policy • Certificates • Authentication and Authorization O B S E R V A B I L I T Y A B 1 B 2 B 3 • Metrics • Logs • Monitoring • Tracing O P E R A T I O N S C O D E Source: solo.io Source: Alibabacloud.com Complexity with multiple tech stacks
- 5. S E R V I C E M E S H The service mesh pattern is focusing on managing all service- to-service communication (East to West) within a distributed software system C o n t e x t The context for the pattern is twofold: • Adaption of microservice architecture pattern building applications by composing multiple services that can be independently deployable. • Organization embracing cloud native platform technologies such as containers, orchestrators, and proxies/gateways I n t e n t • Eliminating the need to compile into individual services a language- specific communication library to handle service discovery, routings, and application-level (Layer 7) non-functional communication requirements. • Externalizing service communication configuration, including network locations of external services, security credentials, and quality of service target • Decentralizing the enforcement of policy throughout a distributed system. • Providing observability defaults and standardizing the collection of associated data and manage monitoring (Providing passive and active monitoring of other services) Source: infoq.com
- 6. S E R V I C E M E S H - B E F O R E A N D A F T E R Operations Code Business Logic Microservice Operations Code Business Logic Microservice Operations Code Business Logic Microservice B E F O R E Operations Code Business Logic Microservice A F T E R Operations Code Business Logic Operations Code Business Logic Microservice Source: solo.io Microservice
- 7. S E R V I C E M E S H - D E S I G N P A T T E R N S S I D E C A R P A T T E R N Deploy components of an application into a separate process or container to provide isolation and encapsulation. This pattern can also enable applications to be composed of heterogeneous components and technologies. Primary App Core Function Side Car Peripheral Tasks Logging Configuration Proxy Platform Abstraction H O S T A M B A S S A D O R P A T T E R N This pattern can be useful for offloading common client connectivity tasks such as monitoring, logging, routing, security (such as TLS), and manage resiliency patterns in a language agnostic way. It is often used with legacy applications, or other applications that are difficult to modify, in order to extend their networking capabilities. It can also enable a specialized team to implement those features. Primary App Core Function Ambassador Peripheral Tasks Retry Circuit Breaking Monitoring Security H O S T Remote Service Deployed as a side car Source: Microsoft
- 8. S E R V I C E M E S H - I M P L E M E N T A T I O N S E R V I C E M E S H I N T E R F A C E • Standard interface for service mesh, it’s a specification allows the implementation-agnostic development of tools based on service mesh features. • Service Mesh users can change their service mesh implementation with out need to change configuration. • Built by Microsoft, Buoyant, Hashicorp to built common standard.
- 9. S E R V I C E M E S H - I M P L E M E N T A T I O N O R C H E S T R A T I O N - S I M P L I F I E D Traffic Control Enforce routing rules & policies Resiliency - Circuit Breaker, Retries Monitoring - Record metrics Observability - Record traces Security - Mutual TLS! Encryption 1 2 3 4 5 P R O X Y Service A wants to call Service B Service Mesh Intercepts request transparently forwards to local Proxy Proxy has destinations defined to load balance request to destination proxy If allowed, destination proxy forwards request to Service B Service B response to the caller
- 10. S E R V I C E M E S H - I M P L E M E N T A T I O N I S T I O – 3 0 0 0 0 F T V I E W D A T A P L A N E Data plane is the delivery system of service mesh. It is made of proxies responsible for forwarding requests. All necessary configuration to forward requests are received from control plane (Service registrations, intentions, config entries etc.) Requests get routed to services within the mesh. Information of availability, health of the services of each node is sent back to control plane. C O N T R O L P L A N E Control plane is central hub of activity for the mesh. Security policies (policies for traffic flow) resides in control plane. It manages resiliency to remove unhealthy services are removed from the mesh. I S T I O D A T A P L A N E Envoy I S T I O C O N T R O L P L A N E Pilot Citadel Gallery Data Plane Control Plane
- 11. S E R V I C E M E S H - I M P L E M E N T A T I O N I S T I O - F E A T U R E S S e c u r e C o m m u n i c a t i o n • mTLS • Certificate Management • Authentication • Authorization C o m m u n i c a t i o n P r o t o c o l s • TCP • HTTP/1.X • HTTP/2 • gRPC R e s i l i e n c e • Circuit Breaking • Retry and time out • Fault Injection • Rate Limiting C h a o s M o n k e y T e s t i n g • Testing O b s e r v a b i l i t y • Monitoring • Distributed Tracing Multi Cluster Supported Supported in both Kubernetes + VM + Cloud T r a f f i c M a n a g e m e n t • Blue/Green Deployment • Load Balancing • Percentage based traffic splits / Canary Deployment M o n i t o r i n g F e a t u r e s • Access Logs • Metrics Generation • Integrated • Prometheus • Graphana • Dashboards • Compatible tracing backends S M I C o m p a t i b i l i t y • Traffic Access Control • Traffic Specs • Traffic Split • Traffic Metrics P l a t f o r m & E x t e n s i b i l i t y • Cloud integrations • Mesh Expansion • Multi Cluster Mesh
- 12. C O N C L U S I O N - D E C I S I O N T R E E & T A K E A W A Y ▪ Service Mesh is clearly in early adaption phase with organizations exploring opportunities to explore. ▪ It has lot of benefits, taking out all necessary cross cutting concerns out and abstracting from the micro service itself ▪ Its code is independent. Irrespective of any programming language cross cutting concerns are the same and implemented. ▪ Configuration process and parameterization are the same in all the services. ▪ Service Mesh pattern aligns itself closely to DEVOPS principles D r i v i n g F a c t o r s Service landscape and requirements Running in multiple clusters Policies and restrictions Robust rollout strategies T a k e A w a y
- 13. R E F E R E N C E S https://istio.io/latest/docs/setup/getting-started/ https://docs.microsoft.com/en-us/dotnet/architecture/cloud-native/service-mesh-communication-infrastructure https://www.solo.io/ https://cloud.google.com/learn/what-is-istio