Large container images were causing slow cold starts and poor auto-scaling for Grab's data platforms. This post explores how we implemented Docker image lazy loading with Seekable OCI (SOCI) technology, to achieve faster image pulls and startup times. The blog discusses how lazy loading works, the technology behind SOCI and eStargz, and finally how this configuration delivered a 60% improvement in download times.

Grab is a leading technology company in Southeast Asia, offering a wide range of services, including ride-hailing, food delivery, and digital payments. Through its platform, Grab provides convenience, accessibility, and reliability to millions of users across the region. From their blog developers can learn from Grab's innovative approach to technology and business, gaining insights into building scalable, customer-centric platforms that address real-world challenges and improve people's lives.

Grab Tech Blog

Grab implemented Docker image lazy loading using SOCI (Seekable OCI) technology to solve slow container startup times caused by large images. The solution achieved 4x faster image pull times on fresh nodes, 30-40% faster P95 startup times in production, and 60% improvement in download times after configuration tuning. Unlike traditional image pulls that download all layers before starting, lazy loading uses remote snapshotters to fetch data on-demand via FUSE filesystems. Grab chose SOCI over eStargz because it's natively supported on Bottlerocket OS, doesn't require image conversion, and maintains the same application startup time as standard images while dramatically reducing image pull time.

Docker lazy loading at Grab: Accelerating container startup times

Results: The numbers speak for themselves

Technical background: How Docker lazy loading works

Building and deploying lazy-loaded images

Great technical depth, while also taking the time to explain the core concepts behind lazy image loading!

<blockquote>
image download time on a fresh node was reduced from 60 seconds to 24 seconds, representing a 60% improvement.
</blockquote>
Talking about reducing seconds in terms of seconds for pulling images, worth it?
To me is like “let’s explain it in % because it sounds better”
How optimized are the Dockerfile’s ?
I remember there was a tool called “docker slim” for reducing docker image size based on some techniques.