Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

41–50 of 66 posts

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

#41

Post by iamEAP »

I may be at a place where this would be useful, so I signed up! That being said...

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.

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

#43

Post by tommy_mcclung »

dmundhra wrote: post #42

Do you handle setting up cloud specific environment like SNS, SQS, Lambda, etc.. and initiating it with seed data needed to create a complete environment for testing?

We do not manage the setup of cloud native services just yet, but it's on our very near term roadmap. Seed data is something we're currently working on building now with a few of our early customers. We will tackle that first, then the cloud native services.

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

#44

Post by gitgud »

Great idea, and is exactly what I was thinking about a few months ago actually.

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!

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

#45

Post by tommy_mcclung »

gitgud wrote: post #44

Great idea, and is exactly what I was thinking about a few months ago actually. 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…

Don't be sorry! I think we can all agree, picking a company name these days is a massive challenge for lots of reasons, you've pointed out one we didn't index on. We like it because it's a good name for what we're doing. I guess we just have to take on the challenge of becoming relevant and making our product awesome so we become relevant.

Thank you for the kind words about what we're building.

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

#46

Post by tommy_mcclung »

iamEAP wrote: post #41

I may be at a place where this would be useful, so I signed up! That being said... 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.…

Many PaaS offerings do some version of this, but we're targeting companies who aren't using PaaS. Specifically companies that are in AWS natively (other could providers coming soon). The reason for this is they are the ones who tend to need to build this from scratch and the market for companies in the cloud is... well... huge. They tend to want PaaS features but have to build it themselves. That's where we are headed. There is also a market for those that need to move off of PaaS due to complexity or technical needs that those PaaS offerings don't support. We think this is a sweet spot.

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.

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

#47

Post by Ozzie_osman »

photonios wrote: post #26

How is this different from Heroku review apps [1] besides that it's not Heroku? 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...

My team uses Heroku review apps and it's just a click to turn on (plus a config file or two if you want to copy over staging data, etc). But i can see it getting complicated if you have more complex setups.

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

#48

Post by bfirsh »

As the creator of Compose (née Fig), I am very excited to see this. We initially created Compose with the intention of it being used to deploy to staging and production environments.

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

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

#50

Post by tylerrobinson »

OriPekelman wrote: post #31

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.
Post reply on HN