StreamElements uses Velocity for one of their YouTube VOD products, where both backend and frontend developers need to collaborate on the same features.
StreamElements is the leading streaming platform that works with content creators on Twitch, YouTube, Facebook. The R&D team develops tools for audience engagement and also monetization, and has recently started to run campaigns with brands such as Coca-Cola, to connect streamers and brands to collaborate together.
At the early stage of the company, there were very few services, and all the developers were running them locally or on their laptops. With only about five services, it was pretty manageable to run, but as the team and product grew, those five services turned into hundreds, and running everything manually and locally was not an option anymore.
“The local development flow was mostly to spin up all the databases and all the core services manually by the developer, which was three of our databases and a few tens of services, which had to be run manually,” says Nils Vollenbruch, who works on the DevOps team at StreamElements. “It's really quite annoying to run those locally and also time-consuming and hard to debug.”
A big part of his work is to focus on developer productivity and developer experience. “I handle all the deployment of services and making sure all the infrastructure works, and a big part of that role is to make sure the developers have a good experience working locally, developing the services, and making sure they have a good development environment.”
That’s when they realized they needed a solution to ease this experience.
“We were very lucky,” says Nils. “When we first started having this issue, we got introduced to Velocity, and jumped straight on it.” He was impressed by the simplicity of Velocity’s stack, and the use of very standard technologies such as Kubernetes and Docker. “It made sense to me and I was able to understand how it works and how to debug it, and it was not very complicated to understand how it works.”
Nils was also impressed by the Velocity team, and its technical CEO and CTO, who were able to explain everything in great detail during the onboarding process, as an early design partner. “We had lots of feature requests that were solved very quickly with great turnaround time,” says Nils. The team started onboarding some services at the start, and are now currently onboarding the rest of their services and more users, with the goal to work with Velocity and make it easier for developers to work locally and get their environments spun up in one command.
With StreamElement’s hiring push and new team members, having a solution that is easy to get developers onboarded was key. Currently, three teams have been onboarded, with plans to onboard more in the coming months. “The teams that have been onboarded are using the tool well and happy doing so,” says Nils.
“It's a lot easier to get the environment up and running, especially with databases and database migrations, and especially when onboarding new developers, which is getting quite frequent now. There are not many other tools that can achieve this with the simplicity and ease of debugging as Velocity.”
StreamElements are using Velocity for one of their YouTube VOD product, where both backend and frontend developers need to collaborate on the same features. The backend team had tens of services, which the frontend team had issues running locally and keeping up with the latest releases. “They ended up developing against production environment, which is obviously not ideal,” says Nils.“Velocity allowed them to get that production-like environment up easily, without needing a lot of help from the backend team.” He recommends that fast-growing teams and teams where the local development environment requires more than say five services, use a tool like Velocity.
Also, teams don’t have to wait for deploying to a shared environment, as they can work on each component separately in an isolated setting, with all the dependencies they need in a click.
“These developers that have been onboarded to Velocity, don't need to really think about it. They just copy-paste the command to spin up the environment and it just works,” remarked Nils.
In addition to reducing the pain of developers running services locally, there have been fewer debugging calls to Nils and the rest of the DevOps team to debug the developers’ local environment. This has freed up the time and maintenance to focus on business-critical needs instead.
“In the future, I would like every developer, no matter from what team, to use Velocity as their standard development flow, where they just pick one service that they want to work on and run all the other services and databases inside Velocity.”