Live data from Hacker News

Launch HN: Release (YC W20) – Staging environments made easy

news.ycombinator.com

51–60 of 66 posts

Re: Launch HN: Release (YC W20) – Staging environments made easy

#51

It 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…

What I’d whip my wallet out for is someone to just take care of a k8s cluster and keep the damn thing healthy. Even on cloud managed their a bit of a pita to manage if you are not a devops.

Re: Launch HN: Release (YC W20) – Staging environments made easy

#52
post #20

What is this with "Launch vs. Show" thing by YC incubatees lately? Is it typical "us vs. them" thinking or does YC also promote these projects on HN over others to let them appear on the frontpage much more easily?

The latter. We started doing this about three years ago: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu... . There's always a rush of these before Demo Day, which is probably why you noticed them lately (the W20 Demo Day is later this month). 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 Laun…

I love the launch HN texts! The clarity, simplicity and humble style is really outstanding and it’s very consistent across launches.

Re: Launch HN: Release (YC W20) – Staging environments made easy

#53

Earlier 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…

What I’d whip my wallet out for is someone to just take care of a k8s cluster and keep the damn thing healthy. Even on cloud managed their a bit of a pita to manage if you are not a devops.

Can you give some examples of what you would want from this tool?

Re: Launch HN: Release (YC W20) – Staging environments made easy

#54
post #3

I think that'll be pretty useful for a lot of companies but I'm not sure whether going with container count as limit will work. 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; chang…

https://runnable.com/preview-environments/ Runnable has the same offering, now bought out by mulesoft. They charged per user.

[deleted]

Re: Launch HN: Release (YC W20) – Staging environments made easy

#55
post #53

Earlier quoted context omitted.

What I’d whip my wallet out for is someone to just take care of a k8s cluster and keep the damn thing healthy. Even on cloud managed their a bit of a pita to manage if you are not a devops.

Can you give some examples of what you would want from this tool?

You mentioned something along the lines of deploying docker compose into kubernetes.

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.

Re: Launch HN: Release (YC W20) – Staging environments made easy

#56
post #28

Been 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…

This is brilliant suggestion.

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.

Re: Launch HN: Release (YC W20) – Staging environments made easy

#57
Nice idea and all the best of luck to the team, but if experience has taught me anything, it's that the staging topic is extremely hard, mostly due to conflicting requirements.

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.

Re: Launch HN: Release (YC W20) – Staging environments made easy

#58

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 suppo…

I’m impressed by what you guys have built at Platform.sh and not surprised to see you chime in here. Incidentally, I applied for your open PM role back in January and was rejected (algorithmically? It was about 8 hours from application to decline...), but would love to connect with you since the posting is still up. Contact info in profile.

Ooh we don't reject anyone algorithmically. So a real trigger happy human was there. And I see no notes left. Which is bad. So I'll review.

Re: Launch HN: Release (YC W20) – Staging environments made easy

#60
"Non-Production Environments Have Diminishing Returns" https://medium.com/@paulosman/production-oriented-developmen... Exactly my insight from years of fighting staging environments and the issues with them. If I'd ever start a company I'd skip a staging environment all together. Instead of focus on staged/gradual rollouts, solid automatic testing before mainline and feature flags.
Post reply on HN