How Modern Distributed Apps Evolve on Kubernetes: From Monoliths to Serverless

1 Modern Distributed Applications

I refer to a distributed system as a collection of potentially hundreds of components that may be stateful, stateless, or serverless, written in various languages, running in hybrid environments, and built with open‑source or proprietary technologies. This talk focuses on the Kubernetes ecosystem and how to build such systems on the platform.

Key requirements start with lifecycle management: stable packaging, deployment, rollback, health checks, placement on different nodes, resource isolation, scaling, and configuration management. These are the most basic needs for building distributed applications.

Network capabilities are the next foundation: service discovery, load balancing, traffic shifting, resilience (retry, timeout, circuit breaker), security, monitoring, tracing, and observability.

Resource binding involves talking to different APIs and data formats, possibly converting between formats, and light filtering of events when subscribing to topics.

State abstractions are not about low‑level state stores but about developer primitives such as workflow management, long‑running processes, scheduling, cron jobs, distributed caching, idempotency, and rollback. These primitives enable robust distributed systems.

We will use this primitive framework to evaluate how these concepts evolve on Kubernetes and related projects.

2 Monolithic Architecture: Traditional Middleware Capabilities

Starting from a monolithic perspective, I think of an ESB (Enterprise Service Bus). ESB provides strong support for all stateful abstractions.

With ESB we can orchestrate long‑running processes, implement distributed transactions, rollback, idempotency, and benefit from extensive resource‑binding connectors that support transformation, orchestration, and networking, including service discovery and load balancing.

ESB offers all network‑reliability features such as retries, but it lacks advanced lifecycle management, declarative deployment, and multi‑language runtimes. Deployment is heavyweight and scaling is limited; a single component cannot be scaled independently.

Isolation—both resource and fault isolation—is also missing, making ESB unsuitable for modern distributed needs.

3 Cloud‑Native Architecture: Microservices and Kubernetes

Cloud‑native began with the microservices movement. Microservices split a monolith by business domain, and containers plus Kubernetes provide an excellent platform for managing them.

Kubernetes popularized health probing. Pods expose readiness and liveness checks so the platform knows when a container can receive traffic and can continuously verify health.

Kubernetes also handles application lifecycle: starting, stopping, and moving workloads across nodes based on events.

Declarative deployment lets the platform create, update, and roll back workloads automatically according to the chosen strategy.

Resource declarations (CPU, memory) enable the scheduler to place workloads on the most suitable nodes, replacing manual placement.

Configuration management maps config maps or secrets to volumes or environment variables, making them available to the workload.

All these capabilities are interrelated; for example, automatic placement requires resource requests, which in turn require health checks to be implemented.

Workloads include stateless microservices (Twelve‑Factor apps), stateful sets, singleton apps (single instance per cluster), jobs, and cron jobs.

Kubernetes satisfies lifecycle, configuration, resource isolation, fault isolation, and supports multiple workload types (except pure serverless).

4 Out‑of‑Process Extension Mechanisms

A pod is an abstraction for deploying containers on a node, guaranteeing two things:

All containers in a pod are co‑located on the same node, allowing localhost or filesystem‑based IPC.

Pod containers have distinct lifecycle roles; init containers run sequentially, while application containers run in parallel (sidecar pattern).

Kubernetes operates on a reconciliation loop: the desired state is continuously compared to the actual state, and controllers act to converge them (e.g., ensuring two pod replicas).

Custom controllers can watch ConfigMap changes and restart pods to apply new configurations.

Custom Resource Definitions (CRDs) let us model our own APIs; operators are controllers paired with CRDs that implement domain‑specific logic. Operators can be written in any language, such as a Java ConfigWatcher.

Operators constitute the second major way to extend Kubernetes beyond its built‑in resources.

5 What Is a Service Mesh?

A service mesh injects a sidecar proxy alongside each service instance. The proxy transparently intercepts all inbound and outbound traffic, acting as a data‑plane firewall.

The data plane consists of lightweight, stateless proxies; the control plane stores configuration, collects metrics, makes decisions, and interacts with the data plane.

API gateways abstract service implementations, while service meshes enhance visibility and reliability. Together they satisfy network‑related requirements.

6 What Is Knative?

Knative is a Kubernetes‑based layer that provides serverless capabilities, consisting of two main modules:

Knative Serving – focuses on request‑response interactions.

Knative Eventing – enables event‑driven communication.

Knative Serving lets you define a Knative Service, which creates a deployment that can scale to zero and back up on demand, providing rapid, elastic scaling without managing instances.

Knative Eventing offers a declarative event system: brokers can route events to various back‑ends (Kafka, in‑memory, cloud services). Importers can pull external events into the broker, and containers receive events via simple HTTP POSTs, eliminating the need for client libraries.

Knative satisfies lifecycle (zero‑scale), networking (traffic shifting), and binding (event imports) requirements for certain workloads.

7 What Is Dapr?

Dapr is a sidecar‑based distributed‑system toolkit offering building blocks such as:

Network primitives: service discovery, tracing, reliable communication, retries, and recovery.

Resource binding: many cloud APIs and connectors, pub/sub messaging.

It also introduces state management abstractions, exposing key‑value stores and allowing developers to interact with state via the sidecar.

Unlike a transparent proxy, the Dapr sidecar is an explicit component that applications call via HTTP or gRPC.

Dapr runs as a sidecar on Kubernetes (or elsewhere) and provides an operator for lifecycle management, along with additional components for certificates, actors, and sidecar injection.

8 Future Cloud‑Native Trends: Lifecycle

Complex lifecycle needs go beyond vanilla Kubernetes. Operators enable custom deployment, upgrades, backups (e.g., to S3), and smarter health checks.

Operators also allow advanced auto‑scaling and tuning. The Operator SDK, Operator Lifecycle Manager, and OperatorHub form an ecosystem for building and distributing operators.

9 Network New Trends: Envoy

Service‑mesh interfaces make it easier to switch implementations. Envoy’s data plane now supports many L7 protocols (MongoDB, ZooKeeper, MySQL, Redis, Kafka) and offers bridging capabilities.

Envoy adds HTTP caching, tap filters for traffic inspection, and WebAssembly‑based custom filters, enabling lightweight extensions without C++.

10 Binding New Trends: Apache Camel

Camel provides hundreds of connectors for enterprise integration and is deeply integrated with Kubernetes via a Camel operator that builds containers from custom resources.

11 State New Trends: Cloudstate

Cloudstate (Lightbend) focuses on serverless, function‑driven development, using sidecars and operators on Kubernetes to provide stateful abstractions such as event sourcing, CQRS, and key‑value storage.

12 Multi‑Runtime Microservices Have Appeared

Modern microservices on Kubernetes often combine platform features (lifecycle, service mesh, Dapr/Knative) with multiple runtimes, resulting in multi‑container services where some containers are transparent sidecars and others are explicit.

13 Intelligent Sidecar and Dumb Pipeline

Business logic can be written in any language; all external interactions go through a sidecar that provides networking, binding, and state abstractions without requiring developers to modify the application code.

14 What Comes After Microservices?

Architecture evolves from monoliths to microservices, then to serverless/FaaS, and finally to operation‑centric designs (Mecha architecture) where multiple runtimes coexist, offering better scalability and separation of concerns.