Ajitem Sahasrabuddhe
Staff DevOps Engineer, Automattic
Nagpur, India
Actions
Ajitem Sahasrabuddhe is a Staff DevOps Engineer at Automattic, working on the platform infrastructure behind WordPress.com and its ecosystem. He has been building software since 2011: container runtimes from scratch, distributed systems at scale, and CI/CD pipelines that hold up under pressure.
His career spans engineering leadership roles at Engineering.com, where he led the creation of a self-serve platform and transitioned hybrid apps to native experiences, and Perennial Systems, where he introduced Go to the team and guided migrations from monoliths to microservices.
Ajitem is an active open-source contributor. His work includes contributions to urfave/cli (24K+ stars), Amazon's aws-lambda-container-image-converter, and uilive. He writes code that he expects others to maintain.
He speaks at international conferences on container networking internals, Go performance profiling, and cloud architecture. He mentors engineers across teams and believes that platform complexity should be invisible to the people building on top of it.
Area of Expertise
Topics
The Life of a Go Binary
You run go build, deploy the binary, and everything just works.
But what actually happens between compilation and process exit? What runs before main()? How does the runtime initialize scheduling, memory management, and garbage collection? What happens when your service receives SIGTERM?
In this talk, we will follow a Go binary through its entire lifecycle — from compilation to shutdown. We will examine the compilation and linking model, runtime bootstrap, scheduler initialization, garbage collector setup, and graceful termination. Along the way, we will connect these internals to real-world concerns such as container deployment, cross-compilation, long-running services, and production observability.
Understanding this lifecycle reveals why Go binaries behave so predictably in modern infrastructure environments. It also explains why Go has become a dominant language for cloud and systems software.
By the end of this session, you will have a clearer mental model of what happens before main(), during execution, and at shutdown. You will leave better equipped to design services that cooperate with the runtime, diagnose startup and shutdown issues, and reason about performance from first principles.
Every Go program has a life story.
This talk tells it.
The Life of a Go Binary: From go build to Running Process Description
Running go build produces a single binary that “just works.” But under the hood a fascinating chain of compilation, linking, and runtime initialization takes place before your main() function ever runs.
In this talk we will dissect the lifecycle of a Go program — from source code to running process.
We will explore:
* How the Go compiler transforms Go code into machine code
* The role of the Go linker
* What actually lives inside a Go binary
* How the Go runtime initializes memory, goroutines, and the scheduler
* What happens before main() runs
* How Go binaries interact with the operating system
Using tools like:
* go tool compile
* go tool objdump
* go tool nm
* strace
* runtime traces
we will peek inside Go binaries and understand how Go programs start and execute.
By the end of the talk, attendees will have a clear mental model of what actually happens when a Go program starts — knowledge that helps with debugging, performance tuning, and systems programming.
The Hidden Cost of Isolation: Measuring Container Performance
Containers are powerful because they isolate workloads, but isolation isn’t free. Every namespace, cgroup, and security mechanism introduces overhead — sometimes negligible, sometimes significant enough to cause production headaches.
In this talk, we’ll explore the performance costs of container isolation. Using Go benchmarks, we’ll measure how syscalls are slowed down by seccomp, how overlayfs adds filesystem overhead, and how virtual networking introduces latency. We’ll then connect these findings to Kubernetes: why some workloads see performance cliffs when containerised, and how to mitigate them through tuning, resource allocation, or runtime choices.
Attendees will leave with a realistic picture of the trade-offs between isolation and performance, and practical strategies to balance them in production systems.
Learning Outcomes
* Understand the sources of container performance overhead.
* Measure filesystem, networking, and syscall costs in Go.
* Recognise workloads sensitive to container isolation.
* Learn mitigation strategies (tuning, runtime choices, limits).
* Make informed trade-offs in Kubernetes deployments.
Target Audience
* Developers optimising performance-critical workloads.
* Kubernetes practitioners running mixed workloads (CPU/memory heavy).
* Engineers curious about syscalls, filesystems, and Linux isolation.
The Cost of a Goroutine: What Really Happens When You Write go
Goroutines are one of Go’s most celebrated features. They make concurrency feel effortless — just add the go keyword and suddenly your program runs concurrently.
But what really happens after that single keyword?
In this talk we will explore the internals of Go’s concurrency runtime and uncover the real cost of goroutines. We will follow the journey of a goroutine from creation to execution and examine how the Go scheduler multiplexes thousands of goroutines onto a small number of OS threads.
Topics covered include:
* The G-M-P scheduler model
* Stack growth and stack shrinking
* Work stealing and scheduling queues
* Syscalls and scheduler parking
* Preemption and cooperative scheduling
* Debugging goroutine leaks
* Real production pitfalls with goroutines
Using real examples and runtime tracing tools, we will visualise how goroutines move through the scheduler and learn how design decisions in Go affect performance and scalability.
Attendees will leave with a deeper mental model of Go’s concurrency runtime and practical techniques for building high-performance concurrent systems.
The Cost of a Goroutine
Goroutines feel free.
We create them without hesitation. We use them to parallelize work, reduce latency, and simplify complex logic. But what does a goroutine actually cost? What happens when you create thousands? Or millions?
In this talk, we will explore the real cost of Go’s most beloved abstraction. We will examine how goroutine stacks are allocated and grown, how the scheduler distributes work, how preemption works, and how memory pressure affects runtime behavior. We will also investigate subtle production issues such as runaway concurrency, goroutine leaks, scheduler contention, and unexpected memory growth.
This session is not a warning against concurrency. It is a deeper understanding of it.
By building a concrete mental model of how goroutines behave at scale, you will learn how to reason about concurrency in high-throughput systems. You will leave with practical techniques for bounding parallelism, avoiding leaks, and designing systems that cooperate with the runtime instead of overwhelming it.
Goroutines are cheap.
They are not free.
Rootless and Ruthless: Securing Containers without Root
Running containers as root has long been a security concern. Rootless containers promise a safer alternative, but how do they actually work? And what trade-offs do they introduce for developers and operators?
This talk dives into the mechanics of rootless containers, exploring user namespaces, filesystem mappings, and unprivileged mounts. We’ll compare runtimes like runc, crun, and gVisor to see how each approaches rootless execution. Then we’ll move to Kubernetes: how rootless pods integrate with clusters, what security guarantees they provide, and what performance costs they bring in networking, storage, and CPU scheduling.
By the end, you’ll know when rootless workloads are the right choice, how to debug them, and how to balance security with performance in production clusters.
Learning Outcomes
* Understand how user namespaces enable rootless execution.
* Compare rootless runtimes (runc, crun, gVisor).
* See how Kubernetes supports rootless pods.
* Evaluate performance vs security trade-offs.
* Gain strategies for adopting rootless workloads safely.
Target Audience
* Security-minded developers and DevOps engineers.
* Kubernetes practitioners adopting rootless workloads.
* Engineers curious about Linux namespaces and isolation.
Rootless and Ruthless: Securing Containers without Root
Running containers as root has long been a security concern. Rootless containers promise a safer alternative, but how do they actually work? And what trade-offs do they introduce for developers and operators?
This talk dives into the mechanics of rootless containers, exploring user namespaces, filesystem mappings, and unprivileged mounts. We’ll compare runtimes like runc, crun, and gVisor to see how each approaches rootless execution. Then we’ll move to Kubernetes: how rootless pods integrate with clusters, what security guarantees they provide, and what performance costs they bring in networking, storage, and CPU scheduling.
By the end, you’ll know when rootless workloads are the right choice, how to debug them, and how to balance security with performance in production clusters.
One Billion Rows and a Profiler: A Go Developer's Guide to Code Performance
What does it take to process one billion rows in Go? Not just fast
code — code you understand deeply enough to optimise, explain, and maintain in production.
In this hands-on tutorial, we use the 1 Billion Row Challenge (1BRC) as a performance playground. You'll instrument, profile, and optimise a real Go program — with guidance at every step.
You'll work through three iterations:
1. Naive implementation — correct, but slow
2. Optimised — fast, but can you prove why?
3. Observable — fast, instrumented, and fully explainable
Tools and techniques we'll cover:
- pprof: CPU, memory, goroutine, and block profiling
- go tool trace: concurrency and execution visibility
- go test -bench: disciplined benchmarking from the ground up
- Flamegraphs: visualise exactly where your CPU time goes
- OpenTelemetry Go SDK: custom spans to trace hot code paths
You'll leave with:
✓ A profiling-first performance mindset
✓ Hands-on experience with pprof, go tool trace, and OTel
✓ A reusable optimisation and benchmarking workflow
✓ Intuition for spotting bottlenecks before they hit production
Prerequisites: Basic Go knowledge.
Laptop with Go 1.22+ installed.
From Node to Pod to Service: Inside Kubernetes IP Allocation
When you run kubectl apply, your pod gets an IP. Simple.
But where does that IP actually come from? Who assigns it? What
happens when you scale to 500 pods? Why does IP allocation behave differently on EKS versus bare metal versus GKE?
Most engineers treat Kubernetes networking as a black box and that's fine, until it isn't. Until pods can't talk to each other. Until a Service ClusterIP stops routing. Until you exhaust your IP space and have no idea why.
In this talk, we will open the black box.
We'll walk the full IP allocation stack, three types of IPs, one
cluster:
- Node IP: How kubelet registers node addresses and what it means for routing
- Pod IP: How CNI plugins perform IPAM, what the plugin call
sequence actually looks like
- Service IP: How ClusterIPs are allocated, why they're virtual,
and what kube-proxy is actually doing
We'll also cover:
- The ServiceCIDR API — Kubernetes' newer mechanism for managing Service IP ranges
- CNI model divergence — why AWS VPC CNI, Calico, and Cilium
make fundamentally different architectural choices
You'll leave with a complete mental model of Kubernetes networking that makes debugging feel obvious rather than mysterious.
From Node to Pod to Service: Inside Kubernetes IP Allocation
Every Pod, every Service, every Node in your cluster has an IP address. Three different components assigned them, using three different mechanisms — and here's the part that should worry you more than it does: nothing in Kubernetes checks those three address spaces against each other. Three allocators, zero cross-checking, and somehow it (mostly) works. This talk is about why, and about the day it doesn't.
I'll trace an IP address through all three domains, from first principles down to the etcd object:
Pod IPs — hierarchical, two-stage, bitmap-based. How NodeIpamController carves --cluster-cidr into one per-node block via --node-cidr-mask-size, writes it to spec.podCIDR, and hands off to the CNI's own IPAM. Then the fork that trips people up: overlay/bridge CNIs respect spec.podCIDR, while VPC-native plugins like AWS VPC CNI and Azure CNI bypass cluster IPAM entirely and pull straight from VPC subnets. I'll also flag where this is heading with the MultiCIDRRangeAllocator and ClusterCIDR API.
Service IPs — the part that just changed. The old in-memory bitmap allocator with its repair loop is gone; ClusterIPs are now backed by real ServiceCIDR and IPAddress API objects in etcd. The conflict-avoidance primitive is genuinely elegant — uniqueness enforced by etcd's atomic create on an object named after the IP itself, so two API servers physically cannot mint the same address. Plus the live demo everyone remembers: adding capacity with a kubectl apply, no restart.
Node IPs — the trick question. Kubernetes performs no allocation here at all. The address comes from your infrastructure; kubelet auto-detects or is told, and cloud-controller-manager reports it back. This is the one most talks get wrong.
We'll finish on the gap that bites in production: nobody validates these three domains for overlap. I'll show where that surfaces, why kubeadm's preflight check won't catch it, and how to reason about it before it pages you.
You'll leave able to answer "who assigned this IP, from what range, and how do I know it won't collide?" for every address in your cluster. Entirely open-source, vendor-neutral, straight to the source.
Flame Graphs to Fixes: Debugging Go in Production
Go makes it deceptively easy to build scalable services — until production traffic exposes hidden bottlenecks. Latency spikes. Memory grows. Goroutines leak. CPU usage climbs. What is the runtime actually doing?
In this talk, we’ll walk through a realistic production incident and debug it using Go’s built-in tooling. We’ll explore Go’s memory model (stack vs heap, escape analysis), understand how the garbage collector behaves under load, and use pprof, flame graphs, and execution traces to identify CPU hotspots, memory pressure, and blocking patterns.
Beyond theory, we’ll apply fixes and measure their impact.
You’ll leave with a practical framework for diagnosing performance issues, tuning Go services confidently, and turning runtime insight into production-grade improvements.
Demystifying Containers: Building a Container Runtime from Scratch
In an era where containers power modern software deployment, understanding their inner workings is more valuable than ever. This session takes you on an exciting journey into the heart of container technology, breaking down what containers truly are and how they compare to virtual machines.
We’ll dive deep into the magic of container runtimes—the software that makes containers tick—and explore the core concepts of namespaces and cgroups that enable isolation and resource control. Through a hands-on demo, we’ll go step-by-step to create a basic container runtime from scratch, offering you an unparalleled understanding of the building blocks behind tools like Docker.
Whether you’re an engineer curious about how containers work or a professional seeking to deepen your technical expertise, this session will equip you with the knowledge to innovate with confidence in the containerised world.
Creating a Container Runtime from Scratch (Workshop)
Containers power modern infrastructure, yet very few developers understand how they actually work. Tools like Docker and Kubernetes hide a fascinating set of Linux primitives beneath a polished interface.
In this hands-on workshop we will build a minimal container runtime in Go from scratch. Participants will implement the core building blocks that make containers possible using Linux namespaces, cgroups, filesystem isolation, and process control.
Starting from a simple Go program that spawns a process, we will gradually evolve it into a lightweight container runtime capable of launching isolated workloads.
* Along the way we will explore:
* Process isolation using Linux namespaces
* Resource limits with cgroups
* Filesystem isolation using pivot_root
* Building a minimal container image
* Networking with veth pairs and bridges
* Debugging containers with standard Linux tools
By the end of the workshop participants will have a working container runtime written in Go and a much deeper understanding of how Docker and Kubernetes work under the hood.
Cloud-Native Starts at main()
We often define cloud-native in terms of Kubernetes, service meshes, and orchestration platforms. But cloud-native software does not begin with a cluster.
It begins at main().
In this talk, we will build a production-grade Go service from scratch and examine what truly makes it cloud-native. No frameworks. No YAML. Just deliberate design decisions made in application code.
We will explore graceful shutdown, signal handling, structured logging, health endpoints, context propagation, timeouts, concurrency boundaries, and observability — all implemented directly using Go’s standard library. Along the way, we will uncover a deeper idea: cloud-native is not a platform feature. It is an architectural mindset.
Go’s philosophy — explicit error handling, lightweight concurrency, context-driven cancellation, and static binaries — naturally encourages resilient, restartable, observable systems. These traits are what allow software to thrive in distributed, failure-prone environments.
By the end of this session, you will understand how to design services that behave predictably under orchestration without depending on orchestration. You will leave with concrete patterns you can apply immediately, whether your service runs in Kubernetes, on a VM, or as a single binary on a small device.
Cloud-native does not start in YAML.
It starts in main().
Beyond Containers — Writing an Orchestrator from Scratch
Kubernetes has become the gold standard in container orchestration, but its complexity can make it feel like magic. What if we stripped things back to the basics and built a tiny orchestrator from scratch?
In this talk, we’ll do exactly that. Starting with Go code that runs isolated processes using namespaces and cgroups, we’ll layer on scheduling, reconciliation, and health checks. Step by step, we’ll uncover how orchestrators manage workloads, and why Kubernetes makes the design choices it does.
The goal isn’t to reinvent Kubernetes, but to demystify it. By building a minimal orchestrator together, attendees will leave with sharper intuition about what happens when you run kubectl apply, how controllers reconcile desired vs. actual state, and how orchestration primitives tie back to Linux capabilities.
This talk is ideal for developers and platform engineers who want to understand the “why” behind Kubernetes, not just the “how.”
Beyond Containers: Building a Minimal Orchestrator in Go
Kubernetes is the gold standard in container orchestration, but what if we stripped it down to the basics? Could we build a “mini-Kubernetes” from scratch — and learn something about distributed systems along the way?
In this live-coding session, we’ll do just that. Starting with Go code that runs isolated processes using namespaces and cgroups, we’ll add a simple API server, scheduling logic, and health checking. Piece by piece, we’ll see how orchestrators manage workloads, and why Kubernetes makes the design choices it does.
The goal isn’t to replace Kubernetes, but to demystify it. By understanding how a minimal orchestrator works, you’ll walk away with sharper intuition about scheduling, reconciliation loops, and what really happens when you run kubectl apply.
Learning Outcomes
* Learn how orchestrators build on container runtimes.
* Understand the basics of scheduling, reconciliation, and health checks.
* See how Kubernetes concepts map to simpler building blocks.
* Gain intuition for debugging orchestration issues.
* Inspire your own experiments with systems programming in Go.
Target Audience
* Go developers curious about Kubernetes internals.
* Platform engineers who want a deeper understanding of orchestration.
* Anyone who learns best by seeing systems built from first principles.
Container Days London Sessionize Event
ContainerDays Conference 2025 Sessionize Event
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top