I think it's fair to point you at my thing: https://platform.sh has been doing something similar since 2015. Based on containers (although that is not the abstraction we expose, in that sense we are more similar to Heroku). Production represents the master branch. Every other branch gets an automatically generated ephemeral staging with a full clone of all the data (and no specific configuration required). With support for microservices and multiple data backends. The whole operation takes about a minute. But this is not something you can run on your own tenant. To get production cloning (for what should be obvious reasons) we need to actually run production.
Launch HN: Release (YC W20) – Staging environments made easy
31–40 of 66 posts
Re: Launch HN: Release (YC W20) – Staging environments made easy
#32It just seems to be a docker host hooked up pull requests. Unless I am missing something there doesn't seem to be anything fancy or new. 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?
These are really good observations and probably points to us needing to add some clarity. 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…
So how is this different from https://github.com/kubernetes/kompose ? What is the value add here?
Re: Launch HN: Release (YC W20) – Staging environments made easy
#33Earlier quoted context omitted.
Did you ask me that question? There's a big difference between Show HN and Launch HN, so if I left you thinking this, it was a bad answer.
I did not. Didn't want to call anyone specifically here. Should have gone to you but didn't really pursue the question any further.
Ah, ok! It's just that HN runs pretty separately from YC's core business, since we're all busy focusing on different things. Best way to get answers to HN questions is to email hn@ycombinator.com - same for everybody.
Re: Launch HN: Release (YC W20) – Staging environments made easy
#34A deployment that is deployed differently from prod is not staging. It's test.
Can releaseapp.io work for prod?
Re: Launch HN: Release (YC W20) – Staging environments made easy
#35A deployment that is deployed differently from prod is not staging. It's test. Can releaseapp.io work for prod?
Yes, we have support for ephemeral environments, permanent staging environments and production environments. Release is currently running on Release in all three of those states. We've decided to focus on staging because that's where our customers are having issues today. Our longer term plan includes a lot of things in all three categories.
Re: Launch HN: Release (YC W20) – Staging environments made easy
#36I think it's fair to point you at my thing: https://platform.sh has been doing something similar since 2015. Based on containers (although that is not the abstraction we expose, in that sense we are more similar to Heroku). Production represents the master branch. Every other branch gets an automatically generated ephemeral staging with a full clone of all the data (and no specific configuration required). With suppo…
Love seeing companies in this space. Thanks for posting.
Re: Launch HN: Release (YC W20) – Staging environments made easy
#37Earlier quoted context omitted.
These are really good observations and probably points to us needing to add some clarity. 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…
So how is this different from https://github.com/kubernetes/kompose ? What is the value add here?
Kompose is a really great tool in converting docker-compose to K8's yaml. But from there you are on your own. We've worked with a few companies that started down this path, realized how difficult K8's was and gave up. We handle everything in the K8's world so customers can just focus on their apps and simple environment definitions.
Re: Launch HN: Release (YC W20) – Staging environments made easy
#38Been there done that. I would take a different route. I will start with one application and make it easy for a developer to install and run it on their computer, ideally with some dummy data. Price it as free to use, you will get tones of users. These users will need a way to get these local applications to a staging and to a production servers. Thats where you charge money and you control the entire cycle. Pulling a…
I like this idea a lot. Thank you for suggesting it.
Re: Launch HN: Release (YC W20) – Staging environments made easy
#39Finally! We've been wanting something like this for a long time.
Re: Launch HN: Release (YC W20) – Staging environments made easy
#40Earlier quoted context omitted.
We originally started with the CPU+memory concept but as we explained it to customers it was confusing. They kept asking why we cared about CPU/memory. We're trying to proxy application complexity and our thinking was containers was an easy way to approximate that. Great feedback, we'll keep iterating and thinking about it.
I would rather have the CPU+memory concept as well. But I think you’re running the applications on the customers’ cloud accounts, right? In that case, if you want to stick to value-based-pricing, I would look at the amount of users the customer has rather than amount of containers. The latter depends upon the complexity of software and the choices of architecture, rather than “value” gained from your product. Having…
Yeah, we're running in the customers cloud account so charging based on compute was a really awkward conversation when we had those initial conversations. (Different if we're hosting it). Charging based on the number of environments feels right to us and our customers because that's when they derive value. The number of containers is just a proxy for the amount of complexity we are orchestrating for them. I'm 100% certain we don't have pricing figured out and I really appreciate the discussion.