Why we built Velocity: Giving developers the freedom to just…develop

Velocity grew up out of my own experience. I was that geeky techie kid; some kids use a paintbrush or Legos to express themselves, I developed software.

I love solving problems, and when I was 14 I started my own company, hosting websites and gaming servers for other people. It was exciting for me to see other people enjoying the service that I gave them, and I never stopped wanting to have an influence on other people’s experiences.

I worked as an engineer for other companies, spent some time doing consulting, and navigating the tech industry to get the right experience, so when the time was right I would be able to start my own company. Finally, in 2019 I read a book called Exponential Organizations, which basically explains how small teams of highly talented people can solve huge problems. At the age of 30, this book brought back the same 14 year old kid in me who was looking to solve big problems. So, I set out to find the biggest problem I could find, and explore what would be the best way to solve it.

Developers need independence

After spending a lot of time on research and thinking about different options, I came back to my own experiences as a developer. The inability to develop and test product components independently has historically been a major pain point for me and my colleagues, as we each relied on common resources. Someone was always using staging, breaking staging, or holding control of components other team members needed. Often, someone made a change and then logged off, leaving everyone else with a broken environment that couldn’t be resolved until that developer returned to work.

While some might think using Infrastructure as Code (IaC) should solve the problem, reality shows that there is a lot of tribal knowledge, and “an environment” includes more than the right application’s version (containers’ images) – it’s also about the data and third-party resources. In some cases, you won't be able to test your code unless the context is exactly right.

One particular example in which I dealt with this issue personally comes to mind. In one of the organizations I worked for, I developed an application that aggregated data and sent it to a processing workflow that had multiple stages. I wanted to check that the data arrived at its final destination in the right format, because every change I made could have multiple effects on the end data, but I couldn’t set up the right environment on my own.

Even after I had that environment, I couldn’t rely on the results as it wasn’t isolated from the rest of my team and couldn’t be “reset.” Perhaps my last test affected the environment, or maybe another engineer was using the same shared environment and their actions affected my work. On top of that, a critical portion of the pipeline was being managed by another team, so I couldn't see how the entire codebase worked together.

Integration testing shouldn’t wait for production

We used to work on monolith applications where each component could complete a full flow on its own and the integration between them came later on in the process, but with the introduction of distributed architecture, and specifically microservices architecture, the integration part of the development process has been pushed left to an earlier stage of the development process. When many developers work on different components of the same product, it’s usually difficult to know if all the components of the product will play well together until they are deployed together – but if you can’t replicate a realistic environment of your product, in most cases that won’t happen until it is being deployed to production.

We at Velocity believe that developers would like to shift-left the process of finding bugs and incompatibilities as early as possible, before even hitting staging. But for most companies, it requires a lot of effort to achieve. This leads most developers to either have an extensive verification process before deploying, or testing only in production and just praying that it works.

Developers should be free to develop

While we as developers love to know how things work under the hood, it doesn’t necessarily mean that we need to build that by ourselves. The increasing use of SaaS and the “build vs. buy” balance show that once developers find a solution that matches their logic, they will prefer to buy these solutions that are not part of their company’s core business, allowing themselves to focus on the core challenges. Developers shouldn’t have to build the chair they sit on, and from Velocity’s point of view, they shouldn’t have to build and maintain the infrastructure that replicates their environments.

Yet our research showed that this is a very common problem. Even the most amazing engineering teams aren’t able to properly test their work, either alone, or together with the rest of the pipeline, and it’s holding them back from full productivity.

We had the pleasure of interviewing great teams that spent time and built their own limited solution for replicating pre-production environments, but it’s soaking up time and energy that should be dedicated to developing.

Currently, developers spend about 20% of their work time just setting up and replicating environments.

The solution: borrow source control concepts

The goal for Velocity’s platform was to find a seamless way to keep parity between a development environment (or “pre-production” environment) and the production environment, building on the same concepts of source control (and specifically, git), so that developers like us could create branches and change only the single aspect they are working on.

We wanted to make it super easy to develop and debug any component, regardless of its dependencies on the rest of the environment, and keep maintenance as low as possible.

Additionally, we searched for a way to define a development environment based on production, without requiring developers or DevOps to maintain yet another definition of an environment. We aimed to offer simple-to-use, replica, production-like environments that would operate on top of the existing set of files that DevOps and developers use to deploy production, instead of another set of files that are not defining reality and yet have to be maintained.

The Velocity way: infinite, on-demand production-like environments

Velocity is changing the paradigm of the developer experience, without requiring companies to change a thing about their existing toolbox or IaC. We offer an infinite number of production-like environments that you can change according to the task you’re working on.

We take a completely new approach to environment creation and management: instead of asking engineering or DevOps teams to maintain both production and multiple definitions of pre-production environments, we view production as the “source of truth,” with configuration files that define deployment.

Most companies have a set of definitions for every environment. When one component is changed, it will (in most cases) lead to drift. Velocity augments the existing deployment files  and aggregates all of them into a single “blueprint” definition which can be used to create environments based on production. Instead of updating each definition whenever there’s a change in production, Velocity defines only the needed changes on top of production, to reflect a development environment that is as realistic as possible.

With Velocity, developers can focus on their core responsibilities and the things that they love to do, enabling them to move faster and be more productive. We empower devs to work at their optimum capacity, test faster, and enjoy greater control over their environments. Velocity allows developers to test everything as often as they like, with the confidence that the environment is clean and the context is accurate.

Environment containerization is ending dependency hell

We’re living in an era of containerization that is transforming the way developers work. Docker led the way, then Kubernetes became the de-facto standard for orchestrating and scaling up applications.

We think it’s time for “environment containerization,” so developers can always access an up-to-date, production-like environment, similar to the way that Docker replicates the same setup for every process.

This latest commoditization of consistency and scale could have a huge impact on developer experiences and productivity. We’re excited to see more and more developers free themselves from dependency hell, shift left, and get empowered to greater productivity.