Tackling cross-cutting concerns within your architecture

Transcript

1. Tackling cross-cutting concerns within your architecture Daniel Kocot, Senior Solution Architect / Head of API Experience & Operations
2. Name: Daniel Kocot Role: Senior Solution Architect / Head of API Experience & Operations Email: Twitter: @dk_1977 LinkedIn: daniel.kocot@codecentric.de https://www.linkedin.com/in/danielkocot/
3. Cloud Native CNCF Definition, https://github.com/cncf/toc/blob/main/DEFINITION.md "Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach. These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil."
4. Microservices!
5. Microservices small loosely coupled by area of functionality
6. Distributed Systems!
7. OSI Model
8. Cross-cutting concerns?
9. Cross-cutting concerns “Integration of requirements whose implementation is not limited to individual components, but is distributed over many services across the entire system.”
10. (Microservice) Patterns for the rescue
11. Fascade (Gang of Four) “A facade is an object that serves as a front-facing interface masking more complex underlying or structural code.”
12. API Gateway (Chris Richardson) “Implement an API gateway that is the single entry point for all clients. The API gateway handles requests in one of two ways. Some requests are simply proxied/routed to the appropriate service. It handles other requests by fanning out to multiple services.”
13. Infrastructure components
14. Containers
15. Orchestration Provisioning and deployment of containers Resource management Health monitoring Scaling Providing mappings to connect to networkings Load Balancing
17. API Gateway / Ingress Controller
18. API Gateway
19. Ingress
20. Ingress Controller The cluster must run an ingress controller to make the ingress resource work The Kubernetes project supports and maintains: AWS GCE nginx ingress controller based on service proxies like Envoy, OpenResty or HAProxy Early every API Gateway vendor normally has an ingress controller in the portfolio
21. Ingress ./. Egress Ingress gateways deal with traffic entering a system and do tasks like routing or offloading Egress gateways control traffic exiting a system
22. Cross-cutting concerns “Integration of requirements whose implementation is not limited to individual components, but is distributed over many services across the entire system.”
23. Cross-cutting concerns contexts
24. Cross-cutting concerns in detail - Traffic Management Access Control List Rate Limiting
25. Cross-cutting concerns in detail - Security Authorization Authentication
26. Cross-cutting concerns in detail - Resilience Circuit Breaker Timeouts
27. But how to govern cross-cutting concerns?
28. Use of OpenAPI Extensions/X-Objects to handle own or vendor needs x-vendor-…​ x-…​ Supported by: root level info paths operation parameters responses tags security schemes
29. Configuration of cross-cutting concerns with OpenAPI Extensions
30. Establish an cross-cutting concerns Design Library by using references within the OpenAPI Definition with the deployment of the API but please set not everything as global ;)
31. Make the Design Library part of API Guidelines
32. Deploy the API and configured infrastructure
33. Service Mesh
34. API Gateway / Ingress Controller vs. Service Mesh
35. API as a product with/without monetization ⇒ API Gateway / Ingress Controller
36. L7 service communication with security and monitoring across different API products ⇒ API Gateway / Ingress Controller
37. L4/L7 service communication with security and monitoring within the same API product ⇒ Service Mesh
38. Offer developers complete lifecycle management of the API ⇒ API Gateway / Ingress Controller
39. Secure communication between services ⇒ Service Mesh
40. Transformation of communication protocols ⇒ API Gateway / Ingress Controller
41. Combining API Gateway / Ingress Controller and Service Mesh
42. Governing of Service Mesh relies on the team involved must be stated in developer guidelines
43. Event Mesh - next big thing?
44. Soft Facts about Event Mesh idea of asynchronous Service Mesh arising from slow ongoing development of existing Service Meshes heavily marketing driven by RedHat, SAP, Solace
45. Hard facts about Event Mesh cluster of the event brokers diverse deployment environments Protocol compability and translation Multiple client APIs Scalability Reliability Security
46. But…​ Event Meshes are lacking the concept of Sidecars Event Meshes still need Services Meshes to fulfill all needs Service Meshes still need to support asynchronous communication e.g. Envoy filters
47. What about Pulsar? classic event broker usage of multiple protocols also still needs a proxy
48. Wrap Up Posts on codecentric blog: https://blog.codecentric.de/en/author/daniel-kocot/
49. Q&A
50. Thank you
51. References