Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

What next after microservices

During this talk, Bilgin will take you on a journey exploring distributed application needs and how they evolved with Kubernetes, Istio, Knative, Dapr, and other projects. By the end of the session, you will know what is coming after microservices

  • Login to see the comments

What next after microservices

  1. 1. Bilgin Ibryam Product Manager @RedHat @bibryam What Next After Microservices? 1
  2. 2. @bibryam Bilgin Ibryam 2 ● Product Manager at Red Hat ● Former Architect/Consultant ● Committer at Apache Camel ● Author and blogger ○ Camel Design Patterns ○ Kubernetes Patterns @bibryam
  3. 3. What comes after Microservices? 3
  4. 4. @bibryam Agenda 4 ● Distributed system needs ● Monolithic architectures ● Cloud-native technologies ○ Kubernetes, Istio, Knative, Dapr ● Future architecture trends
  5. 5. @bibryam 5 Modern distributed applications ● 100s of components and 1000s of instances ● Polyglot, independent, and automatable components ● Hybrid workloads on hybrid environments ● Open source, open standards, and interoperable ● Build on the Kubernetes ecosystem
  6. 6. What are the needs of distributed applications? 6
  7. 7. @bibryam 7 Distributed application needs
  8. 8. @bibryam 8 Distributed application needs Lifecycle management ● Deployment/rollback ● Placement/scheduling ● Configuration management ● Resource/failure isolation ● Auto/manual scaling ● Hybrid workloads ○ stateless, stateful, tasks, serverless
  9. 9. @bibryam 9 Distributed application needs Advanced networking ● Service discovery and failover ● Dynamic traffic routing ● Resilience ○ Retry, timeout, circuit breaking ● Security, encryption, rate limiting ● Observability and tracing
  10. 10. @bibryam 10 Distributed application needs Resource bindings ● Connectors for APIs ● Polling and event-driven integrations ● Point-to-point, pub/sub interactions ● Protocol conversion ● Message transformation ● Filtering, light message routing
  11. 11. @bibryam 11 Distributed application needs Stateful abstractions ● Workflow management ○ Long-running transactions (SAGA) ● Temporal scheduling i.e. timers ● Distributed caching ● Idempotency ● Application storage abstraction
  12. 12. Monolithic architectures 12
  13. 13. @bibryam 13 Traditional middleware capabilities ● Stateful primitives ● Resource bindings ● Networking ● Lifecycle ?
  14. 14. @bibryam 14 Traditional middleware limitations ● Lifecycle management ○ A single language, shared runtime ○ Manual deployment/rollback ○ Manual placement ○ Scaling is difficult ○ No resource/failure isolation
  15. 15. Kubernetes native architectures 15
  16. 16. @bibryam 16 Microservices and Kubernetes
  17. 17. @bibryam 17 Microservices and Kubernetes
  18. 18. @bibryam Health probes 18
  19. 19. @bibryam Managed start/stop 19
  20. 20. @bibryam Declarative deployment 20
  21. 21. @bibryam 21 Resource demands & placement Predictable resource demand Automated placement
  22. 22. @bibryam 22 Configuration management ● ConfigMaps used in Pods as: ○ environment variables ○ volumes ● Secrets: ○ Minimal Node spread ○ Only stored in memory in a tmpfs ○ Encrypted in the backend store (etcd) ○ Access can be restricted with RBAC
  23. 23. @bibryam 23 Foundational Kubernetes patterns
  24. 24. @bibryam Batch/Periodic Job 24 Hybrid workloads Global SingletonStateful Service Stateless Service
  25. 25. @bibryam 25 Kubernetes capabilities ● Deployment/rollback ● Automated placement ● Configuration management ● Resource isolation, recovery ● Auto/manual scaling ● Hybrid workloads: stateless, stateful, batch jobs, serverless
  26. 26. How to extend Kubernetes? 26
  27. 27. @bibryam 27 Out-of-process architecture Deployment guarantees Lifecycle guarantees
  28. 28. @bibryam Sidecar 28
  29. 29. @bibryam Controller Pattern 29 Schemas ● ReplicaSet ● StatefulSet Controllers ● replicaset ● statefulset Resources ● Pod ● PVC...
  30. 30. @bibryam Operator Pattern 30 kind: ConfigWatcher apiVersion: k8spatterns.io/v1 metadata: name: webapp-config-watcher spec: configMap: webapp-config podSelector: app: webapp Custom operator ● Go ● Helm ● Ansible ● Java ● Python Custom application ● AI/ML ● Big Data ● Storage ● Streaming ● Monitoring CustomResourceDefinition + CustomController = Operator
  31. 31. @bibryam 31 How to extend Kubernetes? Sidecar Operator Out-of-process composition mechanism for orthogonal capabilities. Define domain-specific knowledge in executable Kubernetes primitives. Data plane Control plane
  32. 32. Post-Kubernetes platforms 32
  33. 33. @bibryam 33 What is Service Mesh?
  34. 34. @bibryam 34 What is Service Mesh?
  35. 35. @bibryam 35 What is Service Mesh?
  36. 36. @bibryam 36 What is Service Mesh?
  37. 37. @bibryam 37 Service Mesh & API Gateway capabilities Advanced networking ● Service discovery and failover ● Dynamic traffic routing ● Retry, timeout, circuit breaking ● Security, rate limiting, encryption ● Observability and tracing
  38. 38. @bibryam 38 What is Knative? Serving Common infrastructure for request-driven interactions that can "scale to zero". Eventing Common infrastructure for consuming and producing events declaratively. Kubernetes-based platform to deploy, and manage serverless workloads.
  39. 39. @bibryam 39 Knative Serving ● Scale-to-zero & activation ● Rapid autoscaling ● Traffic splitting ● Callable by Knative eventing ● Simplified deployment model apiVersion: serving.knative.dev/v1alpha1 kind: Service metadata: name: lotto spec: replicas: 1 selector: matchLabels: app: lotto template: metadata: labels: app: lotto spec: containers: - image: cds19/lotto
  40. 40. @bibryam 40 Knative Eventing
  41. 41. @bibryam 41 Knative Eventing ● Source Importers (Kafka, Apache Camel 200+) ● Broker implementations (In-memory, Kafka, etc) ● Triggers and filters ● CloudEvents as the data format
  42. 42. @bibryam 42 Knative capabilities ● Serving ○ Autoscaling, scale-to-zero ○ Traffic splitting ● Eventing ○ Messaging infrastructure ○ Source importers
  43. 43. @bibryam 43 What is Dapr? A portable runtime for building distributed applications. Source:https://github.com/dapr/docs
  44. 44. @bibryam 44 Building blocks
  45. 45. @bibryam 45 Dapr architecture
  46. 46. @bibryam 46 Dapr capabilities ● Stateful primitives ● Resource bindings ● Advanced networking
  47. 47. @bibryam 47 The list goes on... Hybrid cloud, and edge-to-edge application networking Stateful abstractions for serverless applications Camel K - Kubernetes native integration framework Louketo Proxy - an OpenID Connect (OIDC) proxy
  48. 48. @bibryam 48 Full circle ● Centralized control plane ● Centralized data plane ● Centralized control plane ● Decentralized, highly-scalable data plane Service discovery Dynamic routing Resiliency Observability Deployment Placement Config mgmt Scaling Bindings State abstraction Pub/Sub Observability Connectors Eventing Filtering Serverless
  49. 49. What comes next? 49
  50. 50. @bibryam 50 Recent developments Lifecycle ● Better sidecars kubernetes/753 ● More operators, better operators operatorhub.io Networking ● Data Plane Development Kit (DPDK) ● Envoy: More L7 protocols, Wasm Bindings ● Bindings move out of the application ● More resource bindings for Dapr, Knative State ● More work is needed! ● There are no pluggable, polyglot stateful abstractions for federation, CDC, caching, idempotency, etc.
  51. 51. @bibryam 51 Multi-runtime services ecosystem
  52. 52. @bibryam 52 Out-of-process distributed primitives
  53. 53. @bibryam 53 What comes after Microservices?
  54. 54. Thank You 54 @bibryam https://k8spatterns.io

×