[HN Gopher] ReleaseHub Environments as a Service Gets 2.7M Seed ...
___________________________________________________________________
ReleaseHub Environments as a Service Gets 2.7M Seed from Sequoia
Author : AmandaPeer
Score : 44 points
Date : 2021-04-29 15:32 UTC (7 hours ago)
(HTM) web link (releasehub.com)
(TXT) w3m dump (releasehub.com)
| strangelove026 wrote:
| How does secrets management work? Would a customer need to
| provide access to hashicorp vault or secrets manager on AWS to a
| CI user?
| cardmagic wrote:
| ReleaseHub has an encrypted secrets at rest solution built-in,
| but can support vault or secrets manager if an organization is
| already using that.
| ccleve wrote:
| 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.
| cardmagic wrote:
| > a simple, opinionated environment if it strips the complexity
| out of the process.
|
| That's exactly what ReleaseHub is :)
| abatilo wrote:
| Couldn't you just use something like Heroku then?
| erik_landerholm wrote:
| 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.
| ccleve wrote:
| Too expensive for larger deployments.
| fnord77 wrote:
| and this new thing won't be?
| koblinski wrote:
| Also Heroku deployments are a PITA when you want fully (or
| partially) isolated environments but also work with a lot
| of microservices.
| nrmitchi wrote:
| 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.
| endisneigh wrote:
| 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?
| erik_landerholm wrote:
| 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!
| sdesol wrote:
| > 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.
| regiswilson wrote:
| > 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.
| ccleve wrote:
| 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.
| msmart wrote:
| 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.
| leetrout wrote:
| 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?
| regiswilson wrote:
| 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.
| theptip wrote:
| 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.
| regiswilson wrote:
| 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.
| erik_landerholm wrote:
| 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.
| sergiotapia wrote:
| 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.
| tommy_mcclung wrote:
| 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.
| ccleve wrote:
| $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.
| tommy_mcclung wrote:
| 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.
| [deleted]
| sshroot wrote:
| 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.
| temp667 wrote:
| No kidding - first thing I look for. It just saves so much
| time!
| [deleted]
| koblinski wrote:
| 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.
| jeremy_k wrote:
| 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-...
| chatmasta wrote:
| 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!
| cardmagic wrote:
| 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.
| jeremy_k wrote:
| 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
| fnord77 wrote:
| 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.
| tommy_mcclung wrote:
| Hit me up at tommy@releasehub.com and I'll hook you up.
| blaydator wrote:
| Nice, I have been looking forward to platform.sh as well in the
| same topic. How do you compare with them ?
| erik_landerholm wrote:
| 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.
| ksec wrote:
| Sounds like a great acquisition target for Github.
___________________________________________________________________
(page generated 2021-04-29 23:02 UTC)