Direct CPU access and a private network: the architecture behind HasData's move off virtual machines

Each HasData request is a client asking for structured data from a webpage. Behind its APIs, HasData runs thousands of real Chrome instances. They render JavaScript-heavy pages while proxies rotate and parsers turn HTML into JSON. Parsing is CPU-bound, so when a noisy neighbor virtual machine takes processor time, HasData's customers see it as a slower response.

"With our Servers.com infrastructure all worker nodes now connect to each other through a private network, allowing us to get rid of our old setup that used a VPN over the public internet."

Roman Milyushkevich

Co-founder and CTO, HasData

HasData originally ran that workload on a cloud provider's Virtual Machines, using a Kubernetes cluster it operated itself. The search for a better provider led to a foundational question. Does a team already running its own cluster need to pay a hyperscaler to run one?

If not, what does that team need to deliver reliability at scale? They need hardware that doesn't share cycles and a network that lets the cluster's nodes talk privately without relying on the public internet.

The workload

There are two ways to scrape a page: "The first way is to send a simple HTTP request and get back HTML," Roman says. "It's very simple, very fast, and it doesn't consume a lot of resources." The second method uses a browser to render pages that require JavaScript. Chrome is very resource intensive, especially with CPU and RAM. Running enough browsers to render hundreds of thousands of pages a day requires substantial compute capacity.

HasData runs real Chrome behind a virtual display, so each browser instance has the CPU and RAM demands of a full desktop browser.

The parsing step is where being on dedicated bare metal hardware creates big performance wins. HasData was experiencing latency spikes it couldn’t explain. Roman had a hypothesis, "In the cloud environments your virtual machine can be on the same server with virtual machines from other customers, and they can sometimes steal your CPU resources. For our use case CPU is very important, because we are parsing data. Parsing HTML into JSON requires a lot of CPU resources." Moving to bare metal confirmed it. "On the bare metal with direct access to CPU we don’t face this issue anymore, and our latency on parsing since migration to bare metal dropped maybe 30 percent."

Roman is direct about the tradeoffs. "For us it was a decision between paying more on AWS, where Kubernetes is built in and updates without our participation, or paying less but setting up everything ourselves and maintaining it ourselves," he says. His verdict after nearly a year is clear. "It requires some more effort in the beginning, but it pays off later."

The architecture

The cluster is operated by HasData's team. Every worker node is Servers.com bare metal, and the nodes communicate over the global private network rather than a VPN overlay on the public internet.

The one real effort in the migration was standing the cluster up. "On AWS you just write these Kubernetes manifests and deploy the app," Roman says. "When you're on bare metal, you have to set up Kubernetes first." HasData chose Rancher to manage the Kubernetes cluster running on Servers.com bare metal. "It is pretty straightforward to set up. It's scary when you do it the first time." The team hired a DevOps engineer to build and maintain the cluster on bare metal, but the day-to-day doesn't require him. "There are a lot of ready-made scripts on GitHub, and nowadays with the help of AI coding tools our developers don't bother our DevOps engineer to deploy something new," Roman says. "He just reviews stuff from us."

The result is self-managed Kubernetes on bare metal. HasData kept the same cluster and deployment model, but moved from shared virtual machines to dedicated hardware with private networking between nodes. The worker nodes run on single-socket AMD EPYC servers, and the databases run on separate blade servers with NVMe storage. Two load balancers spread traffic across the nodes, and everything sits in Servers.com's Dallas-Fort Worth data center.

The results

The proof

Before committing to bare metal, HasData bought two servers as a test. The deciding question was how the global private network would perform. "In the very beginning we did not understand how the Servers.com global private network works," Roman says. "So we had to order two servers. We did a small test, tried this global private network between them, and we were happy with the results." The test is the reason the cluster's nodes run without a VPN overlay today. After the test, the team spent about two weeks settling on the server configurations it wanted.

The future

HasData's fastest-growing customers did not exist a year ago. "We have a growing segment of different AI visibility trackers," Roman says. "A lot of products for tracking AI visibility were created in recent months, and some of them are using our APIs to actually get this visibility data." Sales software and AI agents that need web access are still HasData's main customer segment. And HasData expects request volume to keep climbing from them as well.

To support the company’s growth, the cluster grows with request volume. "We're updating, adding new servers, adding new nodes to our cluster," Roman says. HasData has added a server about every two months since the migration and recently upgraded one server to 10G network cards. When the team needs more capacity, it tells its account executive what the servers are for. He finds the hardware and moves it to Dallas-Fort Worth. Then he sends an order link, and the team brings new servers online on its own schedule.

For the business story behind this architecture, read the HasData case study. To talk through a CPU-bound workload that shared virtual machines keep slowing down, contact the team.

Thanks to Roman Milyushkevich for sharing the HasData x Servers.com story.