ReleaseHub Environments as a Service Gets 2.7M Seed from Sequoia | Hacker News Reader

ReleaseHub Environments as a Service Gets 2.7M Seed from Sequoia

releasehub.com

50 pointsAmandaPeer37 comments

If this is what I think it is, I want it. I truly do not like all the tools out there for doing deployment -- CloudFormation, CodeDeploy, Terraform, Ansible, the various container management schemes. If I can just create a little config file, push code, point, click, and deploy, I will be happy. I'm happy to live within a simple, opinionated environment if it strips the complexity out of the process.

> a simple, opinionated environment if it strips the complexity out of the process.

That's exactly what ReleaseHub is :)

Couldn't you just use something like Heroku then?

Too expensive for larger deployments.

Also Heroku deployments are a PITA when you want fully (or partially) isolated environments but also work with a lot of microservices.

and this new thing won't be?

You can use heroku, but as your app grows in complexity, (say static javascript frontend, backend, queue, and maybe a few AWS or GCP native services) you have to stitch something together with heroku + vercel + ?? + can't use RDS, but wish i could. :)

Heroku review apps are analogous to our ephemeral environments, but we can deal with much more complicated environments, which reduces complexity in your CI/CD platform, production deployments or on-premise deployments if needed.

Heroku (and pretty much every PaaS) has features like this built in, and they tend to work really well... assuming you're using Heroku.

If you're using a PaaS that offers this, you (99.9% of the time) shouldn't look elsewhere. Just use their offering.

If you're not using an explicit PaaS, rebuilding this functionality yourself can end up being a never-ending rabbit hole.

I haven't looked into ReleaseHub in great detail, but isn't what you're describing pretty trivial using docker containers?

Do you have an example of what you're describing that can't be easily solved by docker-compose?

> describing pretty trivial using docker containers

It is important to understand trivial doesn't always mean fast and easy. Also "easy" is a matter of perspective.

I found that making the container was trivial, but deploying it using the AWS Container Orchestration Service or Fargate was not. Tons of configuration options, and security never seems to work right out of the box.

We used docker-compose as a starting point because we were thinking along the same lines. In order to orchestrate the deployment of a complicated app, docker-compose became a much smaller part of solution; docker-compose is helpful for getting some partial service definitions created, but there is so much more to deploying environments.

We are a full CI/CD platform with the ability to do static javascript builds, build-x builds, installing in our customers clusters, installing in their customers clusters, dealing with routing for ephemeral environments, creating pools of resources for ephemeral environments to attach to, deploying and monitoring production environments, a workflow engine and we are just getting started!

We do run into objections along the way like, "can't a couple of people do this pretty easily", but depending on what you want to do, it grows in complexity quickly. A lot of time teams don't realize that until they are way down the path of trying to create a system like this.

If you have any specific questions about how ReleaseHub works let me know, happy to answer anything!

> that can't be easily solved by docker-compose?

Docker-compose only runs on my (your) laptop. What if you want to share that with someone else? I have to git stash, checkout a branch, tell someone else to do all that... I think you're on the right idea: it's "easy" to do with existing tooling, but there's a big gap between it's easy to do and then go and spend the time to do it.

Check out https://aws.github.io/copilot-cli/ it’s a few lines of code and a few cli commands to deploy a service. Made my terraform scripts unnecessary and dramatically simplified my setup. It’s cloud formation under the hood tough. But I like the direction.

Hey, Erik (Co-Founder) from ReleaseHub! We are very excited about announcing our Seed Round led by Sequoia, but even more importantly we are excited about delivering on our mission to free engineering teams from bottlenecks created by the lack of environments.

Everywhere we have worked we have had to build some kind of machine to create environments for our development, marketing, sales teams, QA, you name it. Whenever we would talk to other companies they either built something to deployment environments or were having issues because they couldn't. ReleaseHub is the culmination of the learnings over our careers and we are really excited to share it with the world.

Please make your pricing public and a separate 'Contact us' option for enterprises. That way, you will be able to reach out to a wider audience.

No kidding - first thing I look for. It just saves so much time!

We can use this but what's the pricing? I emailed you but instead you should have just put the cost up front save a lot of time.

Co-founder here. The basic premise is we price based on the type of environment, the number of environments and the number of services within the environment. The reason we took pricing off the site was because every company has a unique setup. When we did user research it was confusing presented as a big table with checkboxes. We decided that for now a quick chat to make sure we understand what's needed was the best way to communicate what it costs. But, the starting point is as around $1000/month if you have a modest setup. For most funded startups with a development team this is usually where they start. We're specifically targeting companies at the moment and not individual developers. We do have some plans to address that segment of the market but we've had to focus where there's an addressable opportunity for our size and scale. This is great feedback and we'll figure this out soon.

$1000 is much too expensive for a startup that is not yet funded, or one that is bootstrapped. Suggest you start lower with a pay-for-what-you-use model. Otherwise, you're looking at an enterprise sale with a longer sales cycle. Make it easy for people to try this thing.

I agree. We are mostly targeting startups that have been funded but for those that aren't and are interested we definitely find ways to make it work for them. Much like how larger companies offer credits for early stage companies we are capable of making it work for them.

If I'm on Kubernetes already, what does this bring over something like ArgoCD? Is it just a managed version of the same feature set, or does it do things Argo can't?

It seems to hint at some sauce to swap in production-like data but I can't see much on that usecase. (https://releasehub.com/use-cases#migration-test-environments)

Having a tight integration into Github would be great (https://docs.releasehub.com/whats-new/january-2021#github-de...), this is definitely an area that has room for polish in ArgoCD for example.

I think ArgoCD is a good parallel to what Releasehub offers, so the question of what we offer is probably a bit of bias on our part. Objectively, though, what we offer is a fully integrated experience from a PR/git commit being built into a fully functioning environment every time. Sometimes the other side of that is just as important: when the PR is closed, we delete the environment!!

The other value add we offer, more subjectively, is the ease of use and reduced TCO of having someone else manage all the kubernetes, infrastructure, duct tape, and self-support required for open source solutions.

Congratulations on the raise and good luck making it work!

I already posted a similar question on an earlier thread from ReleaseHub, and maybe I'm misunderstanding the constraints, but I'm still wondering about your positioning strategy. Specifically, how will you deal with the chicken/egg problem of your customers needing a semi-mature ops pipeline in order to create the images that ReleaseHub can deploy?

It seems like your best customers would be those who don't have the technical expertise to setup automated build systems and CI pipelines. But in order to use ReleaseHub, do those customers need to ship some artifacts to you? And if they have to create those artifacts anyway, and also deploy them to prod in the meantime, isn't that like 90% of the way to having an environment per deployment? At that point, if they've managed to do that much by themselves, why would they outsource the last part?

Seems like you have two ways to approach this. (a) Add lots of bells-and-whistles post-deployment so that it's not just "the last 10%", but a full suite of marketing/demo/QA tools with each deployment. Or (b), simplify the requirements for what customers have to ship to you, so e.g. they can `git push` a repository with a `yarn.lock` and `package.json`, and you'll handle all the pre-deploy build steps as well.

The risk of (b) seems to be feature creep, in that you end up building a generic PaaS platform rather than focusing on your core differentiator of per-environment deployments. The risk of (a) might be the classic Parse.com problem – you attract a bunch of early startups as customers, but once they grow into a more profitable customer, they also outgrow your service and churn as they decide to replicate it in-house.

I'm sure you've thought about these challenges, and that the investors asked about them, so I'm just curious how you plan to approach them. You've got a clear value proposition, but positioning and differentiation will be your biggest challenges IMO. I'd be especially weary of GitLab and GitHub encroaching on this territory.

Either way, best of luck to you. The website is great and the product sounds useful!

I think ReleaseHub is going for (b). The differentiation is that it would be a fully managed and fully configurable/customizable PaaS on your own infrastructure or even on premise instead of a black-box infrastructure owned and managed by the PaaS provider.

Thank you for the kind words. I'll try to answer what I can!

In regards to the customers needing an ops pipeline to create images, that isn't necessary to use Release. We have our own build infrastructure, running on Docker Buildx so we can take your code, turn it into container images and deploy it without you needing to have anything set up yourself aside from a working Dockerfile.

But there may be customers who do already have their own pipeline setup running tests and creating images so we did create an external API for shipping those images to us [1]. Creating full fledged integrations with other service providers is something we've thought of exploring, but for now it would be possible to create an environment via a POST call with the image information and a bit of pre-setup to make sure we can pull the images from where you've stored them.

What you describe in (b) is definitely possible right now. The `git push` will send the webhook to us, we'll create the image and automatically deploy the environment. What you describe in (a) is also something we think is important. We have an integration with LaunchDarkly [2] that has pre and post deployment hooks so building out features around those type of hooks for different use cases is something we want to lean into. Another example in the (b) category is our Instant Datasets [3] which gives you an RDS instance with pre-filled data to be used for say a sales demo or a QA validation.

[1] - https://docs.releasehub.com/api-documentation/release-api/cr... [2] - https://docs.releasehub.com/integrations/integrations-overvi... [3] - https://docs.releasehub.com/reference-guide/instant-datasets

Sounds like a great acquisition target for Github.

This seems very similar to https://layerci.com/

LayerCI seems to have some “secret sauce” in the caching mechanisms to speed up builds.

This seems to take a wider approach offer environments outside of just CI.

Any other notable differentiators?

Releasehub goes all the way to CD if you build out a staging and/or production environment. Releasehub also does super fast builds with buildkit. So it's CB->CI->CD all the way.

CD is the real end-goal and there is an argument to be made to be an expert in only one. However, integrating all the different parts of these chains and tools just adds more compatibility and complexity problems, which is exactly what Releasehub tries to solve.

How does ReleaseHub work when you're working with a lot of microservices? I find the challenge isn't necessarily with monoliths, but our microservice-happy architecture design puts a lot of strain on devops, environment reliability, development, etc.

Hi, I built out our microservices solution and you read more about it in the Microservices Architecture documentation [1]. There is also a walk through of setting up two applications with this approach in the documentation [2].

At a high level, the way ReleaseHub solves this issue is through a feature we call App Imports. Each App would be microservice and there would be one application that imports all the others. For the sake of simplicity let's have two microservices, Frontend and Backend. Frontend would import Backend and when a deployment goes out, ReleaseHub would deploy Backend first, followed by Frontend. Both deployments end up in the same Kubernetes namespace so the pods can talk to each other directly.

This setup allows for creating the dependencies needed to run the services. If you wanted to set up Backend to only deploy itself and say run integration tests against it, you don't have to connect it to any other services. But Frontend may be useless without Backend, so hooking them together is a requirement.

[1] - https://docs.releasehub.com/getting-started/common-setup-exa... [2] - https://docs.releasehub.com/examples/app-imports-connecting-...

no self-serve trial option? Looks like I have to speak to a salesperson to try this out.

It's a shame because my company could potentially use something like this.

Hit me up at tommy@releasehub.com and I'll hook you up.

How does secrets management work? Would a customer need to provide access to hashicorp vault or secrets manager on AWS to a CI user?

ReleaseHub has an encrypted secrets at rest solution built-in, but can support vault or secrets manager if an organization is already using that.

Nice, I have been looking forward to platform.sh as well in the same topic. How do you compare with them ?

I’m not an expert in platform.sh, but when looking at this https://docs.platform.sh/languages/ruby.html It looks like platform.sh has to add support for specific kinds of languages and frameworks. Release doesn’t work like that.

Ours is all based on K8s and containers. We use buildx to build just about anything and we then orchestrate the deployment of multiple services into our customers cloud accounts. We have a full Ci/cd platform from build to production to even managing on-prem deployments following our customers business rules. Our goal is to “virtualize” your entire environment to be cloud agnostic over time. We have customers now that have chosen to have their ephemeral environments and production in different cloud providers and that is something we enable.

We have a workflow engine that allows you to run terraform, migrations, tests, anything you can think of as part of your deployments. You can customize the config for every environment from replicas to liveness probes to adjusting memory for every pod, or you can ignore all of that and just deploy away!

Hopefully that helps. Sorry I’m not to knowledgeable on their platform.

Reply on news.ycombinator.com