Cloud native applications of the future will consist of hybrid workloads: stateful applications, batch jobs, stateless microservices, functions, (and maybe something else too) wrapped as Linux containers and deployed via Kubernetes on any cloud. Functions and the so-called serverless computing model is the latest evolution of what started as SOA years ago. But is it the last step of the application architecture evolution and is it here to stay? During this talk, we 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
The Evolution of
Distributed Systems on
Kubernetes
1

2. @bibryam
Bilgin Ibryam
2
● Product Manager at Red Hat
● Former Architect/Consultant
● Committer at Apache Camel
● Author of “Camel Design Patterns” and
“Kubernetes Patterns” books
● Latest interest: cloud native data
@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
● Based on 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,
serverless, etc)

9. @bibryam
9
Distributed application needs
Advanced networking
● Service discovery and failover
● Dynamic traffic routing
● Retry, timeout, circuit breaking
● Security, rate limiting, encryption
● Observability and tracing

10. @bibryam
10
Distributed application needs
Resource bindings
● Connectors for APIs
● Protocol conversion
● Message transformation
● Filtering, light message routing
● Point-to-point, pub/sub interactions

11. @bibryam
11
Distributed application needs
Stateful abstractions
● Workflow management
● Temporal scheduling
● Distributed caching
● Idempotency
● Transactionality (SAGA)
● Application state

12. Monolithic architectures
12

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

14. @bibryam
14
Traditional middleware limitations
● Lifecycle management
○ Single, shared language runtime
○ Manual deployment/rollback
○ Manual placement
○ Manual scaling
○ No resource/failure isolation

15. Cloud-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
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 capabilities
More Kubernetes Patterns
● Foundational patterns
● Structural patterns
● Configuration patterns
● Behavioural patterns
(For more Kubernetes Patterns,
check out the link at the end of the slides)

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

25. @bibryam
25
Lifecycle capabilities
● Deployment/rollback
● Placement/scheduling
● Configuration management
● Resource/failure isolation
● Auto/manual scaling
● Hybrid workloads: stateless, stateful,
batch jobs, serverless

26. How do we extend
Kubernetes?
26

27. @bibryam
27
Out-of-process extension mechanism
Deployment guarantees Lifecycle guarantees

28. @bibryam
Sidecar
28

29. @bibryam
Controller Pattern
29
Default schema
● ReplicaSet
● StatefulSet
● Job, CronJob
Default controllers
● replicaset
● statefulset
● job, cronjob
Managed resources
state
● Pod
● PVC...
Custom controller -> Custom behaviour

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 + Controller = Operator

31. Kubernetes based
platforms
31

32. @bibryam
32
What is Service Mesh?

33. @bibryam
33
What is Service Mesh?

34. @bibryam
34
What is Service Mesh?

35. @bibryam
35
What is Service Mesh?

36. @bibryam
36
Networking capabilities
API Gateway Service Mesh
Abstract away details and decouple
consumers from implementations
● Controls what’s allowed in/out
● Bridging security domains
● Request / response transformation
● Protocol, data format transformation
● API composition
● Rate limiting
Enhances the reliability and the visibility of the
networking interactions
● Telemetry, tracing collection
● Service discovery, load balancing
● TLS termination/origination
● Request routing, traffic splitting
● Traffic shadowing
● Rate limiting

37. @bibryam
37
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.

38. @bibryam
38
Knative Serving concepts
● Scale-to-zero & activation
● Rapid autoscaling
● Traffic splitting
● Callable by Knative eventing
● Simplified deployment model
○ Single Port
○ No PersistentVolumes
○ Single Container
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

39. @bibryam
39
Knative Eventing concepts
● Sources (Kafka, CronJob, Apache Camel 200+, etc)
● Broker implementations (In-memory, Kafka, etc)
● CloudEvents data format
● Trigger with filters
● Sequence: chaining multiple steps composed of
containers

40. @bibryam
40
Lifecycle, networking, binding capabilities
● Knative Serving
○ Simplified deployment for stateless workloads
○ Traffic based autoscaling including Scale-to-Zero
○ Traffic splitting for custom rollout / rollback scenarios
● Knative Eventing
○ External triggers for feeding Knative Services
○ Based on CloudEvents
○ Backed by proven messaging systems
○ Declarative messaging infrastructure

41. @bibryam
41
What is Dapr?
Sidecar architecture
Developer first, standard APIs
used from any programming
language or framework.
Building blocks
Make it easy for developers to
create microservice without
being an expert in distributed
systems.
A portable runtime for building distributed
applications.

42. @bibryam
42
Dapr building blocks
Distributed Tracing
See and measure the message
calls across components and
networked services
Service Invocation
Act as a reverse proxy with
built-in service discovery,
tracing and error handling
Publish & Subscribe
Secure, scalable messaging
between services
Resource Bindings
Trigger code through events
from input and output bindings
to external resources.
Actors
Encapsulate code and data in
reusable actor objects as a
common microservices
State Management
Provides a key/value-based
state API with pluggable state
stores for persistence

43. @bibryam
43
Dapr architecture
Source:https://github.com/dapr/docs

44. @bibryam
44
Dapr on Kubernetes
Source:https://github.com/dapr/docs

45. @bibryam
45
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

46. Future cloud native trends
46

47. @bibryam
47
Lifecycle trends
Source:https://operatorhub.io

48. @bibryam
● Introduction of Service Mesh Interface specification
● Architecture consolidation of Istio with istiod
● More L7 protocols: MongoDB, DynamoDB, ZooKeeper, MySQL, Redis, Kafka(8188)
○ KIP-559 can enable bridging, validation, encryption, filtering, transformation
● HTTP Cache filter (eCache)
● HTTP tap filter (with matcher)
● WebAssembly (wasm) filters with dynamic loading (C++ -> Rust, Go, etc)
48
Networking trends

49. @bibryam
49
Binding trends
Dev Environment Cloud
kamel CLI
Camel K
Operator
Custom
Resource
Running Pod
Fast redeploy!
Less than 1 second!
- from:
uri: "direct:route"
steps:
- split:
tokenize: ","
- to: "mock:split"
Camel-K Operator:
1. Choose a runtime
2. Scaffold a project
3. Add boilerplate
4. Add dependencies
5. Create container image
6. Create Kubernetes
resources for deployment
Source:https://github.com/apache/camel-k
Live
updates!

50. @bibryam
50
State trends
Source:https://github.com/cloudstateio/cloudstate

51. What does all this mean?
51

52. @bibryam
52
Multi-runtime microservices are here

53. @bibryam
53
Smart sidecars and dumb pipes

54. @bibryam
54
What comes after Microservices?

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