Hive On Demand

Problem

By 2020 I’d spent four years running load tests for other teams and teaching them to run their own on Hive. Hive was powerful, and it was too hard to use. When I started the project, I wrote down why. Hive:

• forced engineers to learn Scala and Gatling;
• was painful to wire into Jenkins and CI/CD;
• made every team fork and maintain its own copy of our sample load-test repository;
• gave little visibility into the health of the load generators;
• made errors hard to troubleshoot and the right logs hard to find.

Approach

• A guided way to build a test. Pick and validate a load generator and a target, model the simulation, and see its predicted outcome before running it. An importer reads a team’s existing simulation repository, so nobody starts from scratch. Scenario chaining, response validation, and custom load injectors let teams model real user journeys, not single endpoints.
• The same engine, without the plumbing. The containerized Hive CLI teams already trusted runs as an ECS task, orchestrated by a Lambda controller, with each run’s workspace and report in S3. Hive On Demand’s own infrastructure is in CloudFormation.
• Who it was for. Hive itself runs daily in several teams’ CI/CD pipelines, where microservice tests find bottlenecks, expose architectures that don’t scale, and give each team upper and lower bounds for its system. Hive On Demand served everyone else: teams that needed an ad hoc or experimental test without hand-writing a Gatling simulation, wiring it to their APIs, and running it through a Jenkins job another team managed. Its heaviest users included teams behind Nike’s high-demand launch platform, and I supported them directly, often by building the features they asked for.
• Owned, not just shipped. Launched in 2021 and kept current for five years: an AWS account migration, an AWS SDK v3 upgrade, redesigned connection testing and load injectors, and in 2026 an AI-planned hardening pass and routing to next-generation load generators. It’s still in use.