Live data from Hacker News

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

news.ycombinator.com

11–20 of 66 posts

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

#11
post #9

Earlier quoted context omitted.

Show HN: community members showing HN what they've built 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)

Excuse the pedanticism but I assume what you meant was "YC portfolio companies showing HN what they have built"

Not pedantic at all! Very confusing typo. I've fixed it.

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

#14

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 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.

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

#15

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?

IMO there isn't a distinction between Launch/Show, or at least one that's well understood. When we were going through our launch we asked what the difference was and didn't get a clear answer.

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

#16
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…

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 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!

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

#17
We had something like this built at my previous org using nothing but Jenkins API and plain docker with a few bare metals for persistent stuff (RDBMs, Solr, Redis etc.). It was created circa 2014 so no fancy stuff like K8s.

I miss it a lot at my new org. Will definitely look at this and suggest to leadership if it aligns.

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

#19
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.

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

#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

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.

Post reply on HN