Posted on September 11, 2026 by Abhi Kulkarni and Shishir Jindal, Atlassian AI workloads are changing what platform teams need from infrastructure. Provisioning GPUs and standing up a cluster no longer makes a platform “AI-ready. ” Once training spans more than one node, the bottlenecks show up in places application platforms rarely treat as first-class concerns: inter-node communication, shared storage, placement, topology, and validation . Our internal ML platform supports training and inference workloads behind product experiences such as search and ranking.
As these workloads grew, some training jobs outgrew the practical limits of a single machine. Models moved into the tens of billions of parameters, and a single node stopped being able to hold the model, its optimizer state, and a workable batch size at the same time. Atlassian therefore needed a platform that could make distributed training reliable and repeatable, without exposing ML teams to the underlying infrastructure complexity. For distributed AI, performance is not just optimization. It is part of correctness. Adding GPUs was the easy part.
The platform had to make three things predictable: ML teams should not have to manage either one. That is the platform's job. Why this matters beyond one company: None of this is specific to us. As AI adoption grows, platform teams keep hitting the same wall: distributed systems, accelerators, storage and scheduling have to behave as one platform, not four separate layers. Before RDMA and Lustre, distributed jobs ran. How fast they ran was anyone's guess. Communication and storage delays surfaced as low GPU utilization, uneven step times, and runs that took far longer than they should have.
The worst of it was silent RDMA fallback. A misconfiguration sent collective traffic over sockets, and the job carried on at a fraction of the speed it should have reached. That made the degradation easy to miss, and expensive to ignore. This was not limited to one environment. On our other cloud, the device plugin that advertises the RDMA fabric to Kubernetes has been in CrashLoopBackOff on every fabric-capable production node from the day it was deployed. It was not a regression; it had never worked. We found it 271 days later, by accident, while verifying an unrelated GPU operator upgrade.