Launch HN: Release (YC W20) – Staging environments made easy
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 ...
65 comments
[ 4.1 ms ] story [ 121 ms ] threadUsing release at my company now and I wish they existed 5 years ago
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.
Having said all this, you have a great product and something like this has always been on my “dream list”, which tops my wish list. It always struck me as the ultimate form of immutable, throwaway infrastructure but I never had a proper excuse to build the necessary tooling to do this. Seems like you guys did, and I’ll be keen to give it a try!
Runnable has the same offering, now bought out by mulesoft.
They charged per user.
Launch HN: YC portfolio companies showing HN what they've built, often within their batch (but can sometimes be years after they went through YC)
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
It looks like Launch HN has been a thing for at least three years: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Anyone can post a Show HN, which is for sharing something you've been working on. The rules for those posts are here: https://news.ycombinator.com/showhn.html
Launch HN is a one-time thing for YC startups. We work with them to edit their text, in the hope of presenting things the way that HN prefers—for example we coach them to take out sales and marketing language. You can see the previous submissions here: https://news.ycombinator.com/launches.
These posts are treated like YC-startup job ads in that they get an automatic placement on HN's front page. Other than that, they are like regular submissions in that users can vote and comment on them, and they rise or fall on the page like the way that submissions do.
This is one of three formal ways that HN gives back to YC in exchange for funding it. The other two are job ads and displaying YC alumni usernames in orange to other alumni. I need to add this to https://news.ycombinator.com/newsfaq.html.
Incidentally, we're happy to help non-YC startups with their launches or Show HNs too. The only bottleneck is time; my time lemons are starting to be squeezed dry. But we can at least send the same list of tips we give to YC startups, and sometimes more direct feedback as well. Email a draft to hn@ycombinator.com.
Main things I see missing
- Ability to clone live database
- Ability to run any sort of tests
- Yet another yaml file with docker configuration in it, slightly different then every other docker configuration system.
Also seems to be twice the size of docker compose?
I think the thing we could explain better is we take the docker-compose and use that as a starting point to define how an application will run in Kubernetes. We aren't just running Docker when environments deploy, we're running applications in K8's. We've debated long and hard about how much K8's we expose to customers. We tend to think it's complex and if we can abstract the complexity so our customers don't have to worry about it, that would be better. Interested to know what people think about how much K8's we should expose.
The reason we choose to create a new YAML file was we needed a way to define environments. docker-compose does have some stanzas for environments but they were meant for Swarm and the older versions of compose didn't map well to K8's. This file is automatically generated and attached to an application so you don't have to write it by hand, just update pieces that apply to environments. There is definitely duplication with docker-compose in this file, we may end up migrating towards just using docker-compose with the Swarm environments definitions but we haven't seen anyone using those yet.
We're working on a few solutions to seed data and database cloning. It's a really big request and will be added very soon. We do have a few ways to do it now, but they are more one-off solutions than products at the moment. Same goes for testing. We've purposefully not tried to be a CI/CD replacement at the moment. Most of our customers are already using Jenkins or Circle so we decided to integrate for now. We are going to add simple test running soon.
I find docker compose simple, and k8s quite complex. So if I can deploy a docker compose kind of project into it that would be nice.
And then on top of that it would handle or greatly assist with fault diagnosis, making sure the thing is highly available etc. There seems to be a lot of weird mistakes you can make with k8s which result in downtime of the app. If you have a full time dev ops person they can train and learn all those corner cases, but for a busy team that uses it and is doing other stuff it is too hard to stay on top of it. I have probably spent 8 hours in total seriously learning k8s! The rest is hacking.
I miss it a lot at my new org. Will definitely look at this and suggest to leadership if it aligns.
We tried dockup but things like DBs, authorizing Facebook and google oauth, subdomains, Stripe webhooks etc became tricky quickly. We ended up doing our own thing with docker compose and some deploy scripts. It’s a bit hairy but dockup wasn’t much cleaner either and it’s one less thing to trust (and a bit of NIH I admit)
Edit: one particular limitation of dockup that probably pushed us was the time limit on the environment. Our use case required longer running environments in some/most cases.
[0] https://getdockup.com/
From our basic understanding of Dockup that primarily is a result of reading their documentation, it appears that the customer has to do a lot of the DevOps/AWS/Kubernetes work on their own to get things going. A big point of differentiation for us is we’re trying to automate as much of that as possible and make it accessible to developers without having to get DevOps involved (or get them involved as little as possible).
We have a solution for database and seed data that we are currently testing with customers. As far as auth'ing with 3rd parties we’ve had to solve this problem for ourselves (our integrations with Github/Bitbucket present this issue with ephemeral environments) and our approach is to take those learnings and create simple generic solutions for them. Right now we would solve that with any customer as part of our onboarding.
I’m not quite sure what challenges you had with subdomains while using Dockup. We auto-create subdomains for all your staging environments including managing dns, either in our cloud or in your AWS account. We have some documentation on how you design your architecture/app for staging environments here: https://docs.releaseapp.io/multiple-environments.
Dealing with subdomains ends up being part design issue (not hardcoding IP/host names, etc) and part using a system that can handle all the complexities around dns, and networking of your services.
We don’t have time limits on the environments. We will be adding administrative settings to allow customers to control the life-cycle of their staging environments. At this moment, they can be created manually or through a pull request. If they are created through a pull request, they are automatically removed when the pull request is merged or removed. But, this is how Release works at the moment based on customer feedback and can be adapted to your use case.
We have worked on this problem all through our careers. We are encouraged by all the companies trying to solve this issue. We feel our approach is unique in its simplicity for the end-user, but we are aware of the complexities inherent in generalizing an approach for other people. It’s hard.
I really appreciate your feedback and would love a chance to show you what we are doing and hopefully we are different and useful enough for a system as complex as yours. If you want please reach out at founders @ releaseapp .io
We have this at work. Every PR provisions a new app with your code deployed on it. Since we use a mono-repo, we built a small Github bot that depending on Github labels sets up the right app.
[1] https://devcenter.heroku.com/articles/github-integration-rev...
After visiting Release's site, I clicked pricing and saw $500/month for what I'd consider playground environment and my instant thought was "nope, another tool I won't use, no chance I'm paying $500 only to speak to sales later in order to agree about more money".
However, if I were charged when trying to make production work - that's something I'd pay for, if it's an application that helps with that process.
Can releaseapp.io work for prod?
At this point, one-click (or one command or one PR open) pre-production environments are almost table stakes for PaaS offerings. This kind of functionality was the primary reason we moved from self-hosted to PaaS (Pantheon) back in 2012/13 at a prior gig. Heroku (as mentioned in other comments) offers similar functionality these days.
Given you probably won't have much traction with teams who are happy on PaaS offerings like the aforementioned, am I right in thinking your market is either people doing completely bespoke docker stuff (how many of those are there), or people whose apps don't neatly fit (either due to size or complexity) into an existing PaaS offering?
If that's the case, I wonder if docker is the wrong abstraction-point. Perhaps it'd be better to be a glue layer between a VCS and something like a Terraform configuration or a Pulumi project.
I also wonder an open source model could be a winner here, too.
As for Docker, we choose that because it's kind of table stakes now. We didn't initially start here, we were thinking more inline with what you were saying initially about Glue between VCS and Terraform. But as we started engaging with users, it was clear that Docker, and more specifically docker-compose was the starting point because what we lacked was a good definition of the services people wanted to run and we didn't want to invent something new for this. We do see a place for Terraform in the near future in our offering.
We also had the good fortune of running into Ben Firshman (founder of Fig/docker-compose) recently and he told us what we're building is what they had envisioned in the early days building Fig. We just brought Ben on as an advisor to help us think through that vision and to also help us with our open source strategy. Because, as you mentioned, we believe that open source is going to play a critical role in how we evolve this business.
My gut take on docker vs. config management came from the trend of IaaS providers moving higher up the chain in the services they offer (it ain't just compute anymore). So spinning up an ephemeral environment that also, for example, had its own SQS instance, or an Aurora DB, or (across clouds) had a Firebase DB or Cloud Scheduler configuration, seems like a very common use-case.
Gotta start somewhere though, and docker's probably a good place to do so.
Looking forward to trying it out!
I'm not too sure about the name of the company though "Release", kind of an un-searchable name. Nobody will be able to find you in Google without significant SEO against business/tech blogs. Try searching "release app" or "release company" it's just too generic.
Sorry to be critical of the name, but I think it's much more important than people realise. I genuinely like product though!
Thank you for the kind words about what we're building.
Docker Swarm was intended as the target of Compose deployments, but that never materialized because Swarm didn't catch on. I'm very glad to see someone carrying the torch in a Kubernetes world. :)
"People who are brutally honest generally enjoy the brutality more than the honesty."
- Richard Needham
On one hand, what you want is as much prod/stage parity as possible, however there are often various side concerns that go against the ideal of "isolated, but equal".
Just from the past few years, I can remember dozens of instances where "easy" staging wasn't an option. Staging services actually needing access to various levels of (partly anonymized) prod data, partly read-only, partly local. Deactivating caching on stage for better testing. Separating or smartly accessing cookie domains from others. Databases that are far too heavy to keep a second set of (especially data warehouses).
In the end, "staging" for me is a problem class that I don't see anyone "solving" in the way "dependencies" won't ever be solved, but I'd be super happy to be proven wrong.
They advocated for and implemented a strikingly similar product within the organization, and it was used for all deployments: development, test, staging, production, etc. The system was a crucial aspect of everyday development and extraordinarily helpful for working with cross-functional partners.