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

1. Bilgin Ibryam
Product Manager @RedHat
@bibryam
What Next After Microservices?
1

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. What comes after
Microservices?
3

4. @bibryam
Agenda
4
● Distributed system needs
● Monolithic architectures
● Cloud-native technologies
○ Kubernetes, Istio, Knative, Dapr
● Future architecture trends

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. What are the needs of
distributed applications?
6

7. @bibryam
7
Distributed application needs

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. @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. @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. @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. Monolithic architectures
12

13. @bibryam
13
Traditional middleware capabilities
● Stateful primitives
● Resource bindings
● Networking
● Lifecycle ?

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. Kubernetes native
architectures
15

16. @bibryam
16
Microservices and Kubernetes

17. @bibryam
17
Microservices and Kubernetes

18. @bibryam
Health probes
18

19. @bibryam
Managed start/stop
19

20. @bibryam
Declarative deployment
20

21. @bibryam
21
Resource demands & placement
Predictable resource demand Automated placement

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. @bibryam
23
Foundational Kubernetes patterns

24. @bibryam
Batch/Periodic Job
24
Hybrid workloads
Global SingletonStateful Service
Stateless Service

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. How to extend Kubernetes?
26

27. @bibryam
27
Out-of-process architecture
Deployment guarantees Lifecycle guarantees

28. @bibryam
Sidecar
28

29. @bibryam
Controller Pattern
29
Schemas
● ReplicaSet
● StatefulSet
Controllers
● replicaset
● statefulset
Resources
● Pod
● PVC...

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. @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. Post-Kubernetes platforms
32

33. @bibryam
33
What is Service Mesh?

34. @bibryam
34
What is Service Mesh?

35. @bibryam
35
What is Service Mesh?

36. @bibryam
36
What is Service Mesh?

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. @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. @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. @bibryam
40
Knative Eventing

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. @bibryam
42
Knative capabilities
● Serving
○ Autoscaling, scale-to-zero
○ Traffic splitting
● Eventing
○ Messaging infrastructure
○ Source importers

43. @bibryam
43
What is Dapr?
A portable runtime for building distributed
applications.
Source:https://github.com/dapr/docs

44. @bibryam
44
Building blocks

45. @bibryam
45
Dapr architecture

46. @bibryam
46
Dapr capabilities
● Stateful primitives
● Resource bindings
● Advanced networking

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. @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. What comes next?
49

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. @bibryam
51
Multi-runtime services ecosystem

52. @bibryam
52
Out-of-process distributed primitives

53. @bibryam
53
What comes after Microservices?

54. Thank You
54
@bibryam
https://k8spatterns.io