Hey everyone, we’re Tommy, David and Erik, co-founders of Release. (
https://www.releaseapp.io). Release makes staging environments easy by automatically generating an ephemeral environment for every Pull Request.
David, Erik and I have worked together for almost 20 years starting with Erik and I meeting each other at an Internship right out of college. We met David in about 2003 when we were all working for RLX Technologies, which was one of the original blade server companies. Our early days were focused on systems management problems before VM’s were widely used. Interestingly enough a lot of the systems problems we are facing today are similar to the problems faced back then, just abstracted a few levels. Staging environments were hard then and they are hard now.
Since then, we’ve all pretty much stuck together, including co-founding IMSafer (detection of inappropriate conversations online for parents) together in 2006. David did take a break from us along the way as he became one of the early engineers at Etsy where he got a new perspective on systems challenges while Erik and I founded CarWoo! (YCS09 - online car buying made easy). David eventually made his way to CarWoo! and rejoined Erik and I after 4 years at Etsy where he was responsible for their search infrastructure and was involved in their DevOps systems. CarWoo! eventually was acqui-hired by TrueCar in 2014. We stayed on as the technology leadership team there for 5 years and led a major replatforming project that solved environments and enabled developers to iterate quickly.
Throughout our careers in doing systems engineering, starting companies, and being in and around technology there has been a universal difficulty in building environments that represent production and actually aid in getting work done vs being a bottleneck. As we’ve explored this problem with early customers, we’re getting similar feedback that’s reinforced our excitement to solve this problem.
We’re hearing some common themes as we talk with customers. Teams with just one or few staging environments have a big bottleneck in their process and can’t get product delivered as quickly as they’d like. The drift between production and the few staging environments a team may have is a problem. A lack of environments causes stakeholders to be out of the loop until really late in the development cycle and rework costs are high.
Engineering leaders are telling us how expensive in time, money and distraction away from core company objectives it will be to focus on this effort. Many times this is the reason this project (building a more flexible staging environment solutions) sits in the backlog and teams are just living with suboptimal velocity. Leaders that have invested in building an in-house solution have told us how complicated building it has been and aren’t happy that they’ve had to dedicate resources to this versus solving customer problems directly.
It’s not all bad though, as companies who have actually built and are maintaining adequate environment infrastructure have a distinct advantage in speed of delivery of complex applications. They are moving faster and that speed is a distinct advantage over companies without this capability. However, the cost of building this infrastructure is generally prohibitively high unless you’ve raised a lot of money or your application is extremely simple.
We’ve solved staging environments at every company we’ve started or been a part of throughout our careers and it’s always been the key to enabling us to move fast. We’ve learned that if developers have their own staging environment automatically created on every Pull Request, they can move incredibly fast. They are free to experiment, they can share work-in-progress changes with stakeholders early and they aren’t waiting for resources to free up to get their work done. We’ve seen ideas come alive while they were being built which has allowed them to iterate faster with more feedback and less rework.
We decided to build Release after spending countless hours talking about our experiences in our careers and when we’ve been the happiest at work. We’ve seen how powerful technology teams can be when they have enabling platforms at their disposal and how hard it can be when they don’t. We’ve always taken pride in making developers happy and more efficient. Release is the perfect avenue to solve a really big problem AND do work we love, that makes us happy.
As we started thinking about building Release, we leaned into the technology we were already familiar with, Docker, docker-compose, AWS and used that as our starting point. We felt that adding Kubernetes to the equation gave us a way to create these environments in a generic way where almost any application would run. We’ve tackled some complex environments for our early customers with lots of services and the interdependencies between them, including cloud native dependencies. Our ability to tackle complex environments has given us hope that the right technologies have emerged that make this possible now.
As we started exploring the idea, we knew Docker and containers were the baseline and we liked the starting point that docker-compose offered for running applications and defining environments. If you have a docker-compose we can run environments for you. We take that docker-compose and compile it into an application/environment definition (release.yml) that we automatically generate. Think of this as an abstraction that sits in between docker-compose and Kubernetes that gives you flexibility to define environments and resources that meet your needs.
From the application definition in the release.yml and your docker-compose we automatically generate all of the Kubernetes yaml files to run your environments. As a customer, you don’t need to know anything about K8’s. Whenever you do a PR we automatically generate all that’s needed to deploy and run your environment in K8’s. We’re interested to hear how much access customers would want to the raw K8’s ecosystem. To date we’ve had the opinion that customers shouldn’t have to deal with it, but would love to hear HN’s opinions on this.
If you’d like to give it a shot, request access at https://www.releaseapp.io We’d love to have you! We’ve tried to keep the model simple and just charge a fee for the number environments created each month by our users.
We’d love to hear your feedback. We’d also love to hear about how companies are handling this problem today. Your feedback is incredibly important to us, we know the HN community has a really unique perspective and appreciate you reading our launch post and making it this far in our launch story!
Staging is where the software is tested as a whole before the production and in many cases it's more than a few containers. I'd not pay $500 for "Up to 5 containers/env" to set up a staging environment for my app that consists of many microservices deployed on Kubernetes. My two cents; change the pricing model. It's not only expensive but also container count is not that helpful. Number of environments is a good proxy for the value I get but I don't want to be punished just because of my number of containers; cpu + memory could be more acceptable.