From Functions to Serverless: Tracing the Evolution of Cloud‑Native Architecture

From Functions to Services

The author begins with personal experience in the early 1990s, programming in assembly, C, and DBaseIII, where functions were distinguished only by naming and file organization, with little attention to exception handling or logging.

Transitioning to object‑oriented development using Object Pascal and later Delphi, the author notes the emergence of classes, private versus public methods, and the initial lack of inheritance, leading to parallel class structures linked by public functions.

With Delphi’s separation of interface declarations from implementations, the author adopts interface‑oriented design to avoid empty placeholder functions, allowing compilation without concrete implementations.

Moving into component‑oriented development, the author describes experience with CORBA, COM/DCOM/COM+, and the evolution from single‑machine applications to client‑server (C/S) and three‑tier architectures, emphasizing the need for component containers to manage lifecycle, concurrency, and memory.

Rise of WebServices and Microservices

The proliferation of web technologies (HTML, CSS, JavaScript) led to XML as a data container and the birth of WebService families, enabling HTTP‑based communication and later REST/JSON transformations.

Amazon’s six architectural principles (exposing all functionality via WebService interfaces, restricting inter‑module communication to these interfaces, mandating external openness, penalizing non‑compliance, assigning small teams ownership, and using a reverse‑working method) are listed to illustrate how microservice thinking was institutionalized.

All modules must expose functionality via WebService interfaces.

Inter‑module communication is limited to these interfaces.

Services must be designed for external consumption.

Non‑compliance leads to dismissal.

Small, cross‑functional teams own end‑to‑end services.

Define future vision, announce it, then implement.

The author argues that true microservices emerge only when small, autonomous teams adopt these principles, rather than merely using microservice‑style technology.

Mobile Era and Cloud Era

The mobile boom in China (circa 2011) forced UI simplification due to limited screen size and input methods, pushing business logic to become leaner and accelerating microservice adoption.

Simultaneously, the shift to cloud computing introduced distributed object systems, databases, big‑data platforms, and message queues, with Spring Cloud becoming the de‑facto microservice middleware.

However, distributed deployments introduced operational complexity, necessitating DevOps practices, containerization (Docker), and orchestration (Kubernetes) to manage scaling, rolling updates, and high‑availability.

Path to Cloud‑Native Applications

Step 1: Move source code to a cloud‑based Git platform, leveraging the provider’s security and backup capabilities.

Step 2: Use a cloud development environment (e.g., AWS Cloud9) that eliminates local dependency installation and offers in‑browser coding, compilation, debugging, and execution.

Step 3: Consume cloud provider OpenAPIs directly from the cloud IDE, offloading service provisioning, scaling, and monitoring to the provider.

Serverless as the Ultimate Goal

Serverless abstracts away packaging, deployment, and scaling entirely; developers write functions that invoke OpenAPIs, while the underlying platform automatically handles containerization, resource allocation, and pay‑per‑use billing.

The author warns that without embracing this model, development efficiency stalls and cloud vendors cannot fully monetize their distributed middleware services.