How Cloud‑Native Technologies Boost Delivery Speed from IaaS to PaaS

IaaS to PaaS transition

Alibaba Cloud first adopted an IaaS‑only model where developers managed only virtual machines or containers. After migrating core e‑commerce services to the cloud, the organization moved to a PaaS‑centric model that consumes managed services such as Redis, RDS, OSS, RabbitMQ, and application‑hosting platforms. In the IaaS stage the application architecture is untouched; in the PaaS stage the chosen cloud services become intrinsic to the architecture and must be considered when designing applications.

What cloud‑native means

Cloud‑native can be described along four vertical dimensions:

Application architecture

Lifecycle management

Traffic management

Infrastructure & dependencies

Horizontal dimensions include microservices, the 12‑Factor App principles, containers, BaaS, GitOps/Infrastructure‑as‑Code (IaC), and Service Mesh.

Three steps to accelerate delivery

1. Standardize the contract between platform/service and application

Define a common protocol (e.g., OS‑level resources such as filesystems, network sockets, or container runtimes) so that applications no longer need to manage physical machines or low‑level failure handling.

2. Decouple business‑agnostic capabilities to the platform

Expose functions such as auto‑scaling, self‑healing, and migration as declarative platform services. Applications delegate these lifecycle concerns to the platform via configuration rather than custom code.

3. Upgrade the application architecture

Refactor the application to consume the standardized contract, allowing it to fully leverage platform capabilities.

Concrete examples

Example 1: Service Mesh removes service discovery and traffic control from business code

By moving registration, discovery, routing, replay, and release‑time traffic control into a sidecar, the application no longer embeds these concerns.

Service registration & discovery

Traffic routing

Traffic replay

Release‑time traffic throttling

Example 2: Lightweight sidecar containers separate log collection

Instead of running a log‑collector process on each VM, containers capture stdout or configured log directories, and a sidecar agent forwards logs to the logging backend. This enables independent upgrades of the collector and isolates logging from business logic.

Resource isolation

Independent upgrade cycles

Example 3: Probes enable platform‑driven lifecycle management

Applications expose health information via HTTP or shell probes. The platform consumes these probes to perform automatic elasticity, migration, and self‑healing without manual intervention.

Automatic scaling

Automatic migration (node‑to‑node relocation)

Automatic restart (self‑healing)

Contract definition (API + Configuration)

The contract consists of two parts:

API layer : open‑source protocols such as Docker/OCI for image delivery, gRPC or Dubbo for RPC, and Redis for caching.

Configuration layer : declarative IaC languages (Terraform, Pulumi) that describe required infrastructure (containers, disks, networks, storage).

Projects like Dapr standardize the API at the HTTP/gRPC level via a sidecar model, while GitOps codifies environment definitions, release processes, and policy enforcement.

Shift in R&D focus

Developers now write code that describes infrastructure, operations, and hosting requirements using a unified declarative language. This abstraction allows the same application to run on private clouds, public clouds, or Alibaba Cloud with minimal changes.

Conclusion

As cloud providers enrich PaaS capabilities, the contract between applications and platforms will evolve into higher‑level SDKs and domain‑specific languages. Cloud‑native practices redefine this contract, enabling more efficient, standardized, and programmable cloud development.