Apstra CloudLabs

Some projects you inherit as a polished handoff. CloudLabs was not that.

When I took ownership of it in 2017–2018, CloudLabs was a collection of Ansible playbooks running on AWS, cobbled together by someone who needed it to exist. It worked, barely, for internal use — a way for people inside Apstra to spin up lab environments. It wasn’t built to scale. It wasn’t built for customers. And it was running on services that have since been shut down.

My job: turn it into something real.

The Starting Point

Apstra built automated datacenter management software — intent-based networking, before that term got overused. The product was technically sophisticated. Selling it required customers to actually use it, which meant hands-on lab environments. Physical hardware was expensive and slow. A cloud-based lab solution was the obvious answer.

The problem was what existed: a handful of Ansible scripts, US-West-2 only, internal-only access, no real web interface, and no path to customer use.

I was less than a year into my first startup job, having come from a midsize bank where I’d spent my post-CCIE career transitioning from network engineer into network automation. I’d barely sat beside a software engineer before, let alone worked in the middle of a fast-moving Silicon Valley engineering organization. I was, by my own honest accounting, in over my head.

CloudLabs is the project that changed that.

The Rebuild

The first order of business was architecture. A handful of Ansible scripts was not a product — it was a prototype that had outgrown itself. The decision was to rebuild the application layer properly — and to bring in the engineers to do it right.

That meant Roman and Tom. Two engineers who built the majority of what became CloudLabs. My job was to own the direction: what we were building, why, and what it needed to become. Their job was to build it well. It worked because we were both doing what we were actually good at.

Compute infrastructure: At peak, CloudLabs was running dozens of bare metal AWS instances spread across multiple global regions. We used bare metal because virtualizing network hardware requires direct hardware access that shared EC2 instances can’t provide. Apstra was always multi-vendor — the platform supported any switch vendor with a virtual image available, and CloudLabs had to match that. At the time that meant Cumulus, Arista, Cisco, and Juniper, all running as virtual instances inside the same infrastructure. Each bare metal host ran a dedicated Ubuntu installation, and we built full automation around provisioning them. Admins had a simple internal menu: deploy a new instance, and it was automatically registered into the CloudLabs backend and available within minutes. No manual configuration.

Backend: The application backend was Flask + Celery + Redis. Flask handled the web layer; Celery with a Redis broker handled all asynchronous operations — lab provisioning jobs, scheduled teardowns, environment lifecycle management. This kept the web layer fast and responsive while long-running infrastructure tasks ran in the background. The database managed user accounts, lab ownership, scheduling, and environment state for every active user.

Authentication: We ran two separate auth paths, each designed to minimize friction for its audience.

Internal users — Apstra employees — authenticated through Google Workspace SSO. Apstra ran on Google, so staff logged in with the credentials they already had. No separate accounts, no password management.

External users — customers and partners — were wired to HubSpot, our CRM. When a customer was added to HubSpot, they automatically got a CloudLabs account provisioned and ready to activate. No manual account creation, no waiting on IT, no back-and-forth after a deal closed. The sales motion and the product access were the same motion.

When Juniper acquired Apstra, getting SSO integrated into Juniper’s systems became an early priority — and delivering it fast became one of the first visible wins the Apstra team had inside the acquisition. In a large company where proving your worth starts on day one, shipping something real quickly matters. CloudLabs did that.

Frontend: The UI was built in React + TypeScript — which sounds unremarkable today, but this was 2019–2020 when TypeScript was still early and widely debated. We made the call to go with it and never regretted it.

The frontend really came into its own when Madhu joined the team. She brought dedicated focus to the UI that it hadn’t had before — taking what had been functional but rough around the edges and giving it the full attention it deserved. The CloudLabs interface became something users actually wanted to use, not just tolerate. That work mattered more than it gets credit for: a lab platform that’s confusing to navigate doesn’t get used, no matter how powerful the infrastructure behind it is.

Development practices: We built everything to run locally first. Full integration tests, unit tests, proper CI/CD validation before anything shipped. Given we were operating infrastructure that enterprise customers depended on for training and POCs, that discipline wasn’t optional.

Multi-repo complexity: CloudLabs wasn’t a single codebase. We coordinated across the platform team’s virtualization repo, our own backend and frontend repos, and various tool integrations that the marketing and customer success teams added over time. Managing dependencies across that surface area — especially keeping in sync with the platform team’s KVM layer — was its own ongoing challenge.

This took CloudLabs from something an individual could spin up manually to a platform that could serve customers worldwide. It’s still running.

The Integration That Made It Matter

The rebuild alone would have been enough. What made CloudLabs genuinely powerful was what happened when I connected it to engineering.

Apstra’s platform team had built something impressive: a KVM-based virtualization layer that could spin up virtual network switches and routers on demand. They’d built it to support their own CI/CD pipeline — engineering could test full Apstra deployments against virtual network topologies automatically. It was sophisticated infrastructure running for internal purposes.

I convinced them to let CloudLabs use it.

That connection turned CloudLabs from a demo tool into a competitive advantage. Because we were integrated into engineering’s Jenkins CI/CD pipeline, CloudLabs could pull a fresh build of Apstra directly from the pipeline the moment it was available. A sales engineer could have a fully functional, up-to-date product environment in front of a customer within hours of a new build coming out of Jenkins.

That’s not a small thing. Enterprise software sales cycles are slow. POCs are expensive. Anything that compresses time-to-hands-on is money. We gave the sales team a superpower.

The Scale

When I took ownership, the monthly AWS spend was a few hundred to a couple thousand dollars — a hobby-project bill.

By the time Juniper acquired Apstra in 2021, that number had grown by orders of magnitude. The majority of the spend was bare metal instances — required for the KVM layer that virtualized network hardware. That cost curve is a reasonable proxy for usage: CloudLabs had grown from an internal curiosity into a platform supporting global sales initiatives.

The Superpower: Hours, Not Weeks

The biggest wins CloudLabs delivered weren’t the planned ones. They were the moments when something larger than expected came in and the answer was: we can have that ready today.

At Juniper scale, enterprise infrastructure requests were measured in weeks. Sometimes months. Procurement, provisioning, coordination across teams — the clock started early and moved slowly. CloudLabs operated on a different clock entirely.

A sales engineer with a customer on-site who needed five dedicated lab environments for a workshop? Two hours. A support team running a proof-of-concept with a large account that suddenly needed to scale? Done before end of day. The only real constraint was boot time — and boot time was measured in minutes, not days.

That speed created trust. When teams inside Juniper realized what was possible, they stopped treating CloudLabs like an IT request and started treating it like a competitive weapon. The expectation shifted from “we’ll need a few weeks” to “can you have it ready by this afternoon?” — and the answer was almost always yes.

The Team

CloudLabs ran on four or five people throughout its life. That was always fewer than we needed, and it was always enough.

Roman and Tom were the engineers who built the majority of CloudLabs. Roman was a classically trained software engineer who was, by any fair standard, better at the craft than I was when we started working together. That’s not false modesty. When I took ownership of CloudLabs I was learning what it meant to think like a software engineer, not just write code. I was moving fast, pushing things out, trying to keep sales moving and internal teams happy. Roman was pumping the brakes — because some of what I was shipping was not good software.

We argued. A lot. He was right about quality. I was right about pace. The startup didn’t have room for perfect, and the customers didn’t have patience for slow.

What the team built together was better than any of us would have built alone. Roman taught me how to actually engineer — what it means to build systems that other people can rely on, what rigor looks like in practice. I helped the team move in environments that don’t wait for perfect. Everyone came out better.

That dynamic — the tension between moving fast and building right — is one I’ve carried into every engineering context since. The answer is never fully one or the other.

The Acquisition

When Juniper acquired Apstra in 2021, I assumed CloudLabs was done. Juniper was a large company with existing training infrastructure. The natural move seemed obvious: absorb the small scrappy tool into something bigger, better-resourced, and already integrated into Juniper’s systems. The small team would go the same way.

The opposite happened.

Rami Rahim, Juniper’s CEO, set a mandate: every sales and customer-facing employee — sales engineers, support, anyone with a customer relationship — would be ramped up on Apstra within the first quarter after closing. It was an aggressive goal for a company of that size, and there was only one platform capable of delivering it at scale. CloudLabs was it.

We made the case to Juniper leadership: give us the budget and we’ll deliver. They agreed. We delivered.

The Fight to Stay Alive

Winning that mandate didn’t end the fight — it started a new one.

Other teams inside Juniper had their own lab and training solutions. The natural question inside a large organization: why maintain a separate platform when alternatives already exist? We had to make the case — repeatedly — that CloudLabs delivered something the alternatives couldn’t match.

We didn’t get shut down. Time and again, we proved that CloudLabs operated at a scale and with a capability the alternatives couldn’t match. We won those fights on the merits.

What makes that more meaningful: we did it with a team of four or five people. I was never given the budget to grow the team to what it actually needed. So we did what any good engineering team does — we innovated around the constraint. Tighter CI/CD pipelines. Better automation. More with less, consistently.

Four people. Global infrastructure. Company-wide onboarding for a Fortune 500 acquisition. Internal competition from teams with bigger headcounts and more resources. We outran all of it.

What It Built in Me

CloudLabs is where I stopped being a network engineer who could write code and became someone who could actually build and operate cloud infrastructure.

Multi-region AWS architecture — real decisions about latency, cost, data residency, and deployment automation at scale
Platform integration — understanding how to connect systems (CI/CD → lab provisioning → customer access) to create compounding value
Flask and Python backend development — beyond scripting, into actual application architecture
KVM virtualization — the mechanics of virtualizing network hardware at the compute layer
Product ownership — requirements, prioritization, roadmap, stakeholder management across sales, engineering, and customers, all without a product manager
Organizational influence — making the case to a CEO and board, surviving an acquisition, defending a product against well-resourced internal competition
Leading under constraint — four people, global infrastructure, no room to grow the team, no room to slow down

The code is private and will stay that way. But the experience is the foundation of everything I’ve built in the cloud since.

Private repository — Juniper Apstra internal product. The Apstra API client built for CloudLabs was extracted and open-sourced as apstra-api-python.

Apstra CloudLabs