I would love to use Heroku -- its tooling is better than anything else I've used, and integrated CI makes it that much better.
However, I run a machine learning service which requires ~3GB of RAM, which means I have to pay--at minimum--$500/mo on Heroku to get a single "Performance L" dyno. Google charges me somewhere in the neighborhood of $35/mo. I'm OK paying a little more for Heroku's convenience, but not 15x.
To any Heroku PMs here, are there plans to allow for custom-sized dynos or additional tiers?
I wish they had some "race to the bottom" price option for small side projects, with free custom domain and letsencrypt support. Something to compete with the $5 VPSs (soon to be the $3 VPSs).
Right now I rent a large server to host multiple things because I don't like the limitations of their free tier. There's something very elegant about having all your "apps" isolated and with their own settings but the price must be just right. I really enjoyed using Heroku (for a client) because maintaining my own servers, even for hobby stuff, feels like such a waste of time.
yeah I would love to use Heroku Free/5USD/5€ with a 500k Rows PostgreSQL database and a simple app that is only for 24/7.
than it would be a no brainer to use heroku and letsencrypt.
Exactly my thoughts I am willing to accept the ridiculous pricing for web dynos considering that they provide a load-balancer / SSL / ability to quickly scale up etc. But running worker dynos or CI with same pricing just doesn't makes any sense.
Shameless plug: We at Boxfuse (https://boxfuse.com) offer effortless zero downtime blue/green deployments to AWS for JVM (Spring Boot, Play, Dropwizard, ...), Node.js and Go applications at a much lower total cost than Heroku.
Do you run the worker constantly? If not, there are autoscaling solutions which can shut it down while not in use. Heroku is pay per second, so this can save a lot for bursty/infrequent workloads.
The real problem is that their extremely high costs are an enormous barrier to entry for anyone trying to build a product that is more than just a low throughput CRUD app.
$35 vs. $500 means that when you are in the bootstrap phase you do not use Heroku. Meaning you do not get used to the very nice quality of life features they have for deployment, CI, etc. Then by the time you have income or an investment switching to Heroku makes even less sense because you've already invested into whatever stack you are using.
With the availability of high level tools on AWS and GCE, it does not take that much work to get to a functional system for CI and deployment. My small team of three at my last gig managed to tie Bamboo to a large scale AWS deployment with what amounted to basically a side project worth of effort.
Furthermore it's harder for developers to learn these things if they have a pay out of pocket for them. I know a lot of people who'd love to dive into kubernetes but don't feel like dropping $200+ to use it in a semi-production environment on GCP or AWS. The free $50-100 credits these services provide does not last long when the services are presumably designed to be used much more then that!
Cloud66 gives you a substantial chunk of what Heroku offers, atop whatever cloud you want. Deployment can be done via a c66 webhook, which you add to Circle/Codeship/Travis etc when your tests pass. Within a few minutes you have Heroku workflow at fraction of cost.
They have a free tier for a single user. However, for all of the features you get with Cloud66, it looks like you need their $500/mo plan (though those features may not be necessary for many use cases)
We've been using Heroku CI on Kickass projects and we like it. Reliable, cheap and fairly easy to setup. However, still seems to be missing some basic functionality like notifications when the build breaks and stuff like that. Looking forward to continued evolution of the product and not having to rely on third party providers.
If you have contacts at Heroku (which you must if you got on the CI private beta), then ask to get on the other private beta they are running now (Hint: Slack)
We've been using this while it's in beta for a we app we are working on and it's been a blast. I had not had a ton of experience with CI/CD before this, but I can't imagine it being much easier. It's really helped our dev process and fits in with the workflow we were trying to accomplish.
Congratulations to the team that shipped this! CI / CD is something I welcome to comoditize and turn into an integrated feature. If any Heroku team members are out there, please consider reducing the minimum price for encryption at rest for your Postgres database so I can use you for my startup.
I'm not really sure why this is preferrable over CircleCI? Could someone explain? Especially since CirleCI is free for the first container. This costs $10, and I don't understand the additional benefits of $10 here.
If you use Heroku for production, using it for CI too means that a lot of the annoying configuration pieces involved in getting CI to match production exactly disappear.
In my opinion CircleCI's configuration UX is actually really poor—compared to what it could be, and what Heroku provides.
In CircleCI, you're configuring against a moving target installation of binaries, and whenever CircleCI decides to upgrade Postgres or Redis or whatever, your tests start failing and you don't know why. Then you have to try to figure out how they've configured the services, and what it will take to use Postgres 9.5.3 instead of 9.6.1—big hassle.
Then there's the little UX things—in CircleCI you can't read the config vars you've set previously from the interface, which means you have to go through the super tedious process running a new build, SSH'ing into it, and then reading them from there, just to remember what user your Postgres connection URI uses.
On top of that CircleCI's documentation is much worse than Heroku's, so re-learning how to do all the random configuration things you need to do each time is more difficult than it could be.
I think anything that reduces time spent messing with CI servers is a big plus, because that work is usually the most frustrating work there is. $10/mo is nothing compared to wasting a day dealing with CI configuration every once in a while.
"the annoying configuration pieces involved in getting CI to match production"
This could be resolved with proper tooling. Depending on what you're doing, Docker, Terraform, Make, build scripts, etc can be used to make every environment as identical as possible.
"n CircleCI, you're configuring against a moving target installation of binaries, and whenever CircleCI decides to upgrade Postgres or Redis or whatever, your tests start failing and you don't know why."
This is a very fair concern and has been voiced in the past. CircleCI 2.0 does not have that issue anymore, as the other commenter pointed out.
"in CircleCI you can't read the config vars you've set previously from the interface"
This is common in webapps and is for security reasons. If the variable value isn't secret, such as the local DB URI, you can set it in `circle.yml` or `.circleci/config.yml` instead. Fully visible and now versioned.
"On top of that CircleCI's documentation is much worse than Heroku's"
This I take very personally as docs are important to me and I work on them constantly. Our docs are open-sourced on GitHub (https://github.com/circleci/circleci-docs) if you'd like to help make them better. If you prefer a conversation, you can always reach out to me on CircleCI Discuss (https://discuss.circleci.com/) or DM me on Twitter (@FelicianoTech). I would LOVE to improve docs.
Your ultimate point of spending less time with CI servers is 100% the goal for SaaS CI. If Heroku, CircleCI, Travis CI, or any others cause you to spend more time in the tool, then they're failing.
Shameless plug: I was also tired of the absurdity around configuring various CI environments along with my local development environment, dev, staging, etc. Every new configuration variable required a change in 6 different platforms, so I created Environr (https://environr.com) to centrally manage configs in a way that works well across all platforms.
Is there any particular reason that the CI system defaults to using Performance-M dyno type ($250/mo)? I know that it's prorated to the second, but it seems like overkill.
Because unlike small scale we traffic, test runs and hard and heavy, and there's benefit in getting results out asap. I find it very useful - would never pay for big dynos for my app at this scale, but $0.05 per month for super fast test results is pretty cool.
There are significant engineering challenges in offering the level of abstraction that they do, and they don't appear to be swimming in cash, so maybe people are focused on better ROI opportunities? Besides, if you build a better heroku that people don't mind spending 15x AWS on, that's one thing, but if your plan is just to be cheaper, well, Heroku can kill you by lowering prices.
Elastic Beanstalk's Multi-container environment can be a nice way to ease a project into containerization, but it seems like it doesn't get much love from AWS these days. You're still forced to set hard memory limits on containers even though ECS support soft limits.
However, I run a machine learning service which requires ~3GB of RAM, which means I have to pay--at minimum--$500/mo on Heroku to get a single "Performance L" dyno. Google charges me somewhere in the neighborhood of $35/mo. I'm OK paying a little more for Heroku's convenience, but not 15x.
To any Heroku PMs here, are there plans to allow for custom-sized dynos or additional tiers?