Amar Kapadia and the Work Between the Machines

Amar Kapadia once flew to Southern California with a co-founder, walked into QLogic’s headquarters without an appointment and waited a day and a half to meet the chief executive. Aarohi Communications was considering acquisition possibilities. The meeting eventually happened. In Kapadia’s telling, the wait was the memorable part. There are more comfortable ways to do business development. Most involve a calendar.

The episode belongs to his hardware years. His subsequent work has dealt with another kind of waiting: the distance between possessing complicated technology and being able to use it. A chip needs a system. A system needs software. A service needs someone to make all the separate pieces cooperate. Kapadia has worked at each of those boundaries, moving from processor design through storage and networking into the software around GPU clouds.

His résumé contains the customary milestones: companies founded, an acquisition, another company, another acquisition. The more revealing thread runs through the less ceremonial work. Writing the explanation. Integrating the components. Giving an operator a way to make a customer’s request happen. These jobs lack the visual appeal of a gleaming rack of hardware. They do, however, give the rack a reason to exist.

A chip designer learns to look outside the chip

Kapadia began by designing CPUs for HP’s PA-RISC computers. He subsequently moved into product management. The attraction was breadth. He liked understanding several subjects rather than spending his entire working life inside a narrow specialty. His formal training was in electrical engineering, including a master’s degree at the University of California, Berkeley.

In the 2000s, he and Sriram Rupanagunta co-founded Aarohi Communications, a company working on 10-gigabit Ethernet Smart NIC technology. Aarohi became part of Emulex. Rupanagunta would later join him in founding Aarna. The partnership connects two periods of infrastructure building: first the networking hardware, then the software responsible for coordinating increasingly distributed systems.

Kapadia’s career also took him through leadership work at Philips and Emulex, then into cloud storage at EVault and network functions virtualization at Mirantis. At EVault, he helped define and launch a public cloud storage service built on OpenStack Swift. These moves brought him closer to a commercial question that keeps returning in his work: how does an underlying technical capability become a service someone else can adopt?

“I liked to know a little bit about a lot of things”

Amar Kapadia, on moving into product management

The engineer who likes a human explanation

Kapadia’s bibliography makes a useful companion to his employment history. There is OpenStack Object Storage (Swift) Essentials, then Understanding OPNFV and ONAP Demystified. The subjects belong to different layers of infrastructure, but the act of writing them is consistent: take a technical system that can intimidate a newcomer and offer a route through it.

He is also listed as an instructor for Linux Foundation courses covering ONAP and Anuket. Teaching sits beside the company building, rather than arriving as a retirement project. The books and courses put his product interests into another form. A buyer needs to understand the proposed system; an engineer needs enough understanding to operate it after the presentation is over.

There is a personal clue in his 2018 writing about training. Kapadia said he learns well when another person starts with the basics and explains things without rushing. For someone working in a field so fond of abbreviations, that is a considerate preference. An acronym can save a writer three seconds while costing a reader the afternoon.

His discussion of hands-on training distinguished between learning what a project does and actually deploying it. The longer courses moved from explanation into labs. That distinction helps explain the practical emphasis in his writing. Understanding a diagram is useful. Getting the software running exposes a different set of questions, usually just as the diagram begins to look reassuring.

An open door is also a business model

By 2020, Aarna’s work centered on orchestration, lifecycle management and automation for cloud-native 5G services and edge applications. Its platform drew on ONAP, the Open Network Automation Platform. Kapadia described open source as a way to provide vendor neutrality and avoid binding a customer’s operating future to one supplier.

The community work was concrete. Aarna participated in documentation, the ONAP Kubernetes plugin and other parts of the networking ecosystem. Kapadia also saw commercial benefits in that participation: contact with potential partners, influence over technical direction and credibility with customers. Community and business occupied the same working day.

He had already written about the organizational side of network transformation in 2017. His advice included clear goals, developing skills, dedicated teams and an executive sponsor. The list gave process and people a place alongside architecture. Buying software could begin a transformation; the organization still had to learn how to work with it.

His explanation of OPNFV emphasized integration and testing across other projects. In that view, useful engineering includes finding out whether separate pieces behave properly together. It is a modest-sounding task until the pieces belong to different communities, move on different schedules and must eventually support a service with paying customers.

A 2020 demonstration offered a visible example of the approach. Aarna helped with an OPNFV project that orchestrated a 5G core onto Red Hat OpenShift using a subset of ONAP. The demonstration became a Leading Lights Awards finalist. Kapadia stressed another feature too: people could join the work and learn to reproduce it themselves. An open invitation accompanied the technical result.

When the workload moves, the problem follows

Aarna’s response to a federal 5G inquiry in 2021 contained an unusually compact description of its problem. Management strain grew with three things: the number of sites, the number of application instances and how often those applications changed. More locations meant more places to deploy. More instances meant more things to track. Faster change meant less time to recover from doing it all by hand.

That framing makes the move toward GPU cloud management easier to follow. The technical setting changed, but coordination remained central. Compute capacity sitting in several places still requires deployment, oversight and a way to decide which work belongs where. A customer requesting a service generally has little interest in how many administrative systems must agree before it starts.

Kapadia was discussing GPU-based edge clouds in a telecom setting by August 2023. His presentation at the IEEE SA Second Open RAN Summit addressed using them for O-RAN, with cost and power as the stated concerns. The talk places GPUs within his earlier networking work, before treating them as an entirely separate chapter would make sense.

▶ WATCH THE TALK

Give the GPUs something useful to do

In his public comments on the GPU market, Kapadia has concentrated on what operators can do with the equipment they own. He argued that H100 and H200 capacity could serve inference, fine-tuning, computer vision and other workloads as demand for newer hardware changed the market. His response was to examine different ways of offering the existing machines to customers.

He also advocated on-demand access. In one post, he suggested that an operator could begin with as little as one HGX server. The proposition was practical and incremental: establish a usable service on a small amount of hardware, then see how it works. It is a different scale of conversation from announcing a data center full of equipment.

In November 2024, he appeared on Humans in AI to discuss his route from engineering to entrepreneurship and the competitive GPU cloud management market. The episode’s stated themes included understanding customer needs and identifying real pain points before developing a product. After several technical markets and more than one founding experience, the discussion still returned to the buyer’s problem.

A new badge, a familiar question

In November 2025, investor 3Lines announced Armada’s acquisition of Aarna Networks. It described interest from Armada after Aarna gained traction in GPU cloud orchestration. By May 2026, Kapadia was publishing at Armada with the title Product Fellow. The founder’s next chapter had a new company name attached.

Their proposed operating model reached beyond assigning a GPU. It covered CPUs, memory, networking and storage, with separation between tenants extending through those layers. It also included billing and user management. These details explain what the orchestration work had grown to encompass: a provider needed to know who could use the infrastructure, what they could access and how their use would be accounted for.

His work with Rupanagunta continued in public technical writing about Bridge and distributed AI. Their discussion considered applications that need computation closer to where data originates. The practical issues included placing workloads, managing remote sites, keeping tenants separate and making expensive capacity useful. Distance adds another set of decisions to the familiar problem of sharing a machine.

Kapadia’s May 2026 Bridge Marketplace announcement moved up another layer, toward validated software that operators could offer alongside GPU infrastructure. The purpose was to reduce the setup and integration work between available compute and a usable AI service. The article addressed operators and builders who otherwise had to assemble those pieces themselves.

The Marketplace launch brought together software categories including model optimization, computer vision, agentic platforms, security and data management. That spread of concerns gives the latest chapter some texture. A useful AI service may need several kinds of software before a customer ever reaches the model. Kapadia was once again describing how separate capabilities could be assembled into something an operator could offer.

It is a fitting continuation for an engineer who became interested in what surrounds the engineering. The processor matters. So does the explanation, the integration and the moment someone can finally get to work. Kapadia’s career has repeatedly taken him toward that moment. There is still plenty to arrange before the meeting can begin.