Was very excited about this during the private beta, when the only pricing indication was about the dyno usage (billed by the second). Now, the GA pricing of $10/mo/pipeline doesn't seem like much, but with our small startup already at 32 pipelines, it ends up blowing past what we're currently paying for CircleCI.
I guess that's actually a more general criticism of Heroku in the microservices context; high availability (at least 2 dynos per service) and predictable performance (non-shared dynos, Performance-M at minimum) combine to make the cost of a "production" setup start at $500/mo/service. Non-issue for a monolith, quite tough for small microservices.
(To be fair, we compromise on both of those requirements and use both single-dyno apps and shared dynos, and so Heroku is very affordable for us. But the downside of those choices ends up biting us often enough that I, in turn, end up lamenting about it on HN.)
Heroku's strategy is about locking you in through services. It's the same playbook being followed by AWS, Azure and GCP. The concept of spinning up and scheduling containers is now well below the value line -- there are many competing platforms in this space. Raw compute is nearly a fungible, undifferentiated product at this point.
Insofar as you can decouple yourself from Heroku service offerings, you are able to decouple from Heroku.
Whether that's a full-service standalone platform like Cloud Foundry (partly inspired by, and partly sharing code with, Heroku), an IaaS-smoothing platform like Convox (founded by Heroku alumni), integrating some intermediate platforms like Deis or rolling your own with Kubernetes or Marathon.
Disclosure: I work for Pivotal, which sells a commercial distribution of Cloud Foundry. And I work in the Cloud R&D section on opensource bits of it. So I have a horse in this race.
Maybe I just have the wrong idea, but I'm pretty sure the whole USP of Heroku is easy deployments without having to worry about Dev Ops and infrastructure. If you want to use AWS directly, that's great... but that's not the customer they're targeting.
Maybe you meant $10/mo/team[1]? There is no monthly charge for pipelines and you can have as many pipelines as you want within a team. 1 pipeline or 5 pipelines, you just pay for dyno time of the apps in your pipelines -- pro rated to the second.
Pricing is similar for Heroku CI -- you pay for dyno time to run your tests.
Note: I work for Heroku and feedback welcome at heroku-ci-feedback@heroku.com (about features or docs).
> During the beta period [team name] will only be billed for dyno usage when tests run. After the beta period ends, each pipeline with Heroku CI enabled will be billed at $10/month plus dyno usage.
For anyone using github and heroku - this may be convenient, but for anyone on bitbucket side - there is built in alternative (even within free tier). I'd say that they are quite late in the game
Congrats to the Heroku team for pushing forward with this. While it's not attractive to this Heroku customer due to my preference for CI solutions that are agnostic to the rest of the deployment workflow, I'm sure this is a great prospect for orgs that are 100% Heroku ride or die.
I'm curious about the pricing model. Other hosted CI solutions have a low-power free tier or provide totally free services to OSS. I wonder if Heroku would consider providing a free version of CI with hobby dynos and other free-tier addons.
Also hoping that charging pro rata for usage is something that can be extended to hosting dynos.
Thanks! I saw someone in this thread mentioning the markup that various services charge https://news.ycombinator.com/item?id=13902492 With GitLab CI we want to make sure it is easy to test your code on any infrastructure. So you can use runners we host, but you can also bring your own runners from any (public) cloud. This way you can use whatever solution is cost effective for you.
The most interesting problem they are trying to solve is the way this integrates with their addon partners. Typical CI you specify services like MongoDB, Redis, Postgres, etc. to be installed directly on the image that your tests are running. Heroku seems to be literally creating accounts with their partners, forcing them to spin up necessary resources, and then just churning the account as soon as the tests are done. Most Heroku partners offer a free tier assuming they can get a percentage to switch to the higher tiers, but this is going to increase usage of those free tiers by a very large amount and I don't see it converting well for the partner.
Edit (clarity): They didn't solve the problem yet, and are limiting the addons to just Heroku services (Postgres/Redis) until they figure out best way to handle with partners. I will be keeping a close eye, very curious what they land on.
I guess that's actually a more general criticism of Heroku in the microservices context; high availability (at least 2 dynos per service) and predictable performance (non-shared dynos, Performance-M at minimum) combine to make the cost of a "production" setup start at $500/mo/service. Non-issue for a monolith, quite tough for small microservices.
(To be fair, we compromise on both of those requirements and use both single-dyno apps and shared dynos, and so Heroku is very affordable for us. But the downside of those choices ends up biting us often enough that I, in turn, end up lamenting about it on HN.)