How Alibaba Unified T4 and Docker into AliDocker for Double‑11 Scale

1. Introduction

In the infrastructure side, the biggest change for this year's Double‑11 was that all core transaction applications ran inside Docker containers, with hundreds of thousands of containers handling a peak of 175,000 orders per second. Although Docker has become popular, moving Alibaba's massive and diverse application portfolio to Docker could not be done overnight.

2. Integration of T4 and Docker

In July of the previous year, Alibaba introduced its internal container technology T4, built on Linux Containers (LXC) since 2011. Over three years, T4 covered most e‑commerce applications. Compared with Docker, T4 was tailored to Alibaba’s internal operations, providing fine‑grained resource isolation, disk quota, and monitoring that made migration from physical machines, KVM, or Xen to T4 seamless.

When the maintenance team took over T4, they found it lacked an image mechanism, leading to inconsistencies and migration difficulties. Starting in June, they explored combining T4 with Docker, creating a hybrid product called AliDocker that added Docker‑style images to T4 while preserving T4’s operational friendliness. The integration also solved Docker’s early daemon‑restart issue by decoupling the daemon from containers.

AliDocker ensured compatibility with existing T4 features and added extensive tooling for image building, distribution, scaling, and migration, allowing mixed‑run of T4 and AliDocker containers on the same physical host.

3. Core Application Imaging

AliDocker’s true value lies in its image mechanism. Instead of merely packaging the environment, Alibaba adopted a full‑image approach where the application and all its dependencies are baked into the image. Deployments now consist of destroying the old container and launching a new one from the updated image, guaranteeing environment consistency.

To handle the large image sizes (several gigabytes), Alibaba stored images in OSS, used regional mirrors, and employed a BitTorrent‑like P2P distribution with super‑caches. Release pipelines were optimized with pre‑warming, asynchronous regional distribution, and intelligent rolling batches, reducing the longest deployment time to one‑fifth of the original and dramatically improving success rates.

4. Customization and Optimization of Swarm

AliDocker unified cloud‑on (ECS) and cloud‑off (physical machines) deployments under the same container runtime. Alibaba introduced a customized Swarm (AliSwarm) that supports bulk container creation, integrates with its own resource scheduler, and assigns independent IPs to containers.

AliSwarm addressed scalability issues of the upstream Swarm, handling clusters of over 30,000 nodes, reducing CPU load, and adding a TLS‑based SwarmProxy for multi‑cluster management with hot‑standby failover, enabling seamless upgrades without service interruption.

5. Dockerization of Alibaba Middleware (Aliware)

Beyond transaction services, Alibaba Dockerized its middleware suite (Aliware). By separating data, configuration, and runtime state, using volumes for persistence, and standardizing images, they kept performance loss within 3‑5%.

Extensive performance testing across physical, VM, and container environments confirmed that Dockerized middleware met stringent latency and throughput requirements. Resource scheduling was tuned to balance diverse demands (network‑heavy messaging, memory‑heavy caching, CPU‑intensive databases), and dynamic adjustments were made during Double‑11 peaks.

The Dockerization effort culminated in all core applications processing 12.07 billion RMB of transactions during Double‑11, proving AliDocker’s suitability for large‑scale e‑commerce workloads.