In last week's office hours, Nicole and Paul sat down with engineering manager Marko Pandurovic to discuss the ever-evolving k6 backend.
All systems turn more complex with time, and the k6 backend is no exception:
- More developers have joined the team
- More users are running tests
- Some customers require a particularly robust, reliable application for testing.
Breaking teams into smaller sizes
In the short period when Marko was working elsewhere, the k6 backend team grew. As a team grows, communication becomes harder. So, when Marko returned as an engineering manager, the first move was to split the team into two squads, each with 5-6 members.
Though there's enough work for another developer, Marko says we're going to pause hiring on the backend team for a few months. This will give our new developers time to learn, and allow us to develop some better processes to help onboarding and to standardize workflows.
But, we definitely plan to hire another engineer by the end of the year: Python developers, take note!
Moving from ECS to EKS
Customers expect k6 services to be resilient. Each day, as our customers use k6 to load test, we effectively load test ourselves, too.
As part of larger, ongoing infrastructure improvements, k6 is migrating from AWS Elastic Container Service to AWS Elastic Kubernetes Service. Marko discusses a few reasons why:
- To improve reliability and scalability
- To make it easier to offer an on-premises version of k6 cloud
- For more portability. Though we still use an AWS-managed system, Kubernetes is becoming the de-facto standard for large web infrastructure.
How will the EKS migration affect reliability?
One goal of the migration is to improve our observability with better metrics and alerting. (Not coincidentally, we've started to use the Grafana stack more heavily).
As we improve our processes, we want to decouple builds from deploys. For now, we release to the cloud on Tuesdays, but we want to get to the point where code lands in production as soon as it's merged.
No plans to migrate the entire backend to Go
Paul Balogh, developer advocate and organizer of the St. Louis Go Meetup, tried to troll Marko into rewriting the entire k6 backend in Go. Fortunately, Marko saw through Paul's ruse and said there's no plan to move our backend away from Python.
That said, all core testing functionality of k6 cloud is built on top of k6 OSS, which is written in Go. So, the k6 backend has some critical cloud services that are essentially Go wrappers.
Bigger customers are helping us become more robust
If you use k6 to create a highly resilient system, don't you expect k6 to be resilient too?
As k6 grows, we get customers with increasingly high testing needs and increasingly high expectations of k6 as an application. These expectations only grew after the Grafana acquisition. Some new customers have some serious loads.
This pressure has helped us improve processes, and customer pain points have provided great ideas for new features (private load zones being the best recent example). Though, sometimes we must take one step back to take two steps forward. To meet growing demand, Marko says that in this development phase, the team is focusing on process improvement over feature development.
Having a robuster app will help us develop features faster and more stably.
Features we hope to build
As processes improve, the k6 backend team is getting ready to do more. Marko mentioned a few feature ideas that he's excited to work on soon:
- On-premises installations
- Some of our users would like to (or must) run the application on their own machines
- Teams and IAM capabilities
- Some teams working on k6 cloud have over one hundred members. k6 needs to help admins manage this
- Extension support in the cloud.
- Currently, xk6 extensions work only on the OSS version. Ideally, they should work in the cloud too.