New Heroku Dynos Get 2.5GB RAM(devcenter.heroku.com)
devcenter.heroku.com
New Heroku Dynos Get 2.5GB RAM
https://devcenter.heroku.com/changelog-items/696
59 comments
Yeah. In my experience, Heroku starts being a drag at moderate scale:
1. You still have to worry about your systems, as Heroku has its own outages, not to mention the other pieces of your infrastructure like DBs, queues, etc.
2. Architecture flexibility goes way down, as vertical scaling isn't a real option on Heroku (and a surprising number of problems can be easily solved in the short term by just throwing big iron at them).
3. The premium you pay on the hardware you're using starts to add up, especially when you're in the realm of "let's solve this problem in the short term by throwing machines at it."
Of course, that's not to say you can't use a hybrid approach of, say AWS + Heroku to solve some of these, but it's a bigger hurdle to clear if you've outsourced all your systems work to Heroku from the beginning. You suddenly find yourself having to figure this stuff out at some level of scale, vs growing it organically and learning as you go.
1. You still have to worry about your systems, as Heroku has its own outages, not to mention the other pieces of your infrastructure like DBs, queues, etc.
2. Architecture flexibility goes way down, as vertical scaling isn't a real option on Heroku (and a surprising number of problems can be easily solved in the short term by just throwing big iron at them).
3. The premium you pay on the hardware you're using starts to add up, especially when you're in the realm of "let's solve this problem in the short term by throwing machines at it."
Of course, that's not to say you can't use a hybrid approach of, say AWS + Heroku to solve some of these, but it's a bigger hurdle to clear if you've outsourced all your systems work to Heroku from the beginning. You suddenly find yourself having to figure this stuff out at some level of scale, vs growing it organically and learning as you go.
Yeah, this is what I'm doing. Using Heroku for their Postgres offering and AWS with convox.io (part of the current ycombinator batch) for deploying web services to AWS.
Hosting is trending towards containers and a Heroku-like approach all over the place, it may not really matter if manually provisioning and maintaining servers stops being popular knowledge.
Pricing can be great if you're using a high-throughput language - I had a sustained 8 - 12k requests per second across 8 dynos years ago with nodejs.
Pricing can be great if you're using a high-throughput language - I had a sustained 8 - 12k requests per second across 8 dynos years ago with nodejs.
Your question is framed at someone who "learned" deployments via heroku. I will answer it from a different perspective. I recently started at a company who began their staging and production hosting on heroku. I would have a very hard time recommending it to anyone.
In addition to uncompetitive pricing, the "add-on" architecture is itself expensive and inflexible. Redis feels artificially limited, and the scheduler's timing options are, i kid you not: Daily, Hourly, Every 10 minutes.
To people who know linux hosting: avoid heroku. To people who don't know linux hosting: spend some time gaining a serviceable linux hosting skillset.
In addition to uncompetitive pricing, the "add-on" architecture is itself expensive and inflexible. Redis feels artificially limited, and the scheduler's timing options are, i kid you not: Daily, Hourly, Every 10 minutes.
To people who know linux hosting: avoid heroku. To people who don't know linux hosting: spend some time gaining a serviceable linux hosting skillset.
don't use heroku's scheduler - it's a best effort scheduler that doesn't guarantee it will even execute your jobs at the times you set.
the company i work for runs a rails app and we've ported almost everything over to running with the clock gem instead of with heroku's scheduler.
the company i work for runs a rails app and we've ported almost everything over to running with the clock gem instead of with heroku's scheduler.
Any advise on some good tutorials? Heroku makes it easy for me to get going.
The truth is you can pretty much do everything with AWS EBS that you can do with Heroku. I wish I knew about EBS earlier. But I don't thik EBS existed when I first began using Heroku.
It was mainly for throwaway projects. But you never know your throwaway project may start getting traction. And before you realize you may end up owing hundreds of dollars to Heroku.
It was mainly for throwaway projects. But you never know your throwaway project may start getting traction. And before you realize you may end up owing hundreds of dollars to Heroku.
Do mean Elastic Beanstalk? "EBS" is Elastic Block Storage, that doesn't make sense in this context.
Neat! That's five hundred MB more than my cellphone.
Am I correct that this represents a 10x cost over an IaaS provider like Digital Ocean? What features in the Heroku platform justify that? Not trolling, but looking for some brief and logical input that'll give me that 'aha' moment
Isn't Digital Ocean just a VPS provider? I'd encourage you to give Heroku a try (it's free to play with). It's pretty cool that with really minimal planning on your part you can "git push heroku" and have a working app.
I don't know if this is an "aha" moment for you -- it might depend on how much you enjoy provisioning servers yourself -- but when it works it's pretty cool.
I suspect there are people who are running apps "themselves" on heroku that would otherwise require them to pay a server administrator.
I don't know if this is an "aha" moment for you -- it might depend on how much you enjoy provisioning servers yourself -- but when it works it's pretty cool.
I suspect there are people who are running apps "themselves" on heroku that would otherwise require them to pay a server administrator.
That's fine for simple one-off apps that don't require serious infrastructure, but Heroku is just ridiculous with its pricing if you need any kind of complexity.
I can burn through 1GB of Redis cache really easily; on Heroku, that's $200 a month. On AWS a cache.t2.small instance is $16 a month. The same for SQL space, disk storage, etc., once you're past a certain point Heroku becomes just unbelievably expensive.
I can burn through 1GB of Redis cache really easily; on Heroku, that's $200 a month. On AWS a cache.t2.small instance is $16 a month. The same for SQL space, disk storage, etc., once you're past a certain point Heroku becomes just unbelievably expensive.
https://github.com/progrium/dokku
That gets you git push deployment, and runs just fine on DO. You're still responsible for hardening your VPSs, but DO has some fairly good guides for that too.
That gets you git push deployment, and runs just fine on DO. You're still responsible for hardening your VPSs, but DO has some fairly good guides for that too.
That's the disconnect for me. There have to be prebuilt Amazon AMIs with push to deploy functionality for various stack flavors. I guess the simplicity and allure of Heroku's git integration makes it easy for developers to forego research on those. It still seems one hell of a price to pay especially when coupled with vendor lock-in (Disclaimer: I don't know if Heroku PaaS locks you in as much as say, GAE)
Disclaimer: I don't know if Heroku PaaS locks you in as much as say, GAE
In my (limited) experience: not by a long shot. Heroku setups may seem locked in, but GAE is obscene. No outgoing HTTP requests, no normal DB, basically everything is GAE specific. Heroku is not the most generic thing out there, but, by God, it's still miles better than GAE.
In my (limited) experience: not by a long shot. Heroku setups may seem locked in, but GAE is obscene. No outgoing HTTP requests, no normal DB, basically everything is GAE specific. Heroku is not the most generic thing out there, but, by God, it's still miles better than GAE.
The key is that Heroku is trying to support all major web app frameworks, whereas GAE only supports the GAE framework.
The tradeoff is super interesting: using their framework allows them to hella optimize the instance for you, but you're pretty darn stuck with it :/
The tradeoff is super interesting: using their framework allows them to hella optimize the instance for you, but you're pretty darn stuck with it :/
No outgoing HTTP requests? GAE has URL Fetch API from first day.
Also, GAE can now run docker and also connect to MySQL running on Google Cloud infrastructure, which is a separate offering.
Also, GAE can now run docker and also connect to MySQL running on Google Cloud infrastructure, which is a separate offering.
Sorry for not being explicit. My point was: you need to use a special API to do outgoing HTTP requests. This leads to vendor lock-in. In Heroku, you just do it.
No you don't. You still use your language's standard library. But GAE uses their own version behind the scenes. You code still uses urllib if on Python and net/http if using Go.
So in GAE too, you just do it.
So in GAE too, you just do it.
I could re-deploy a heroku app on my typical stack (ruby, rails, postgres) to digital ocean or similar in a couple of hours.
Most of that would just be setting up the new one and migrating the data across.
You don't have to significantly alter apps (in that stack) to be heroku-compatible.
Most of that would just be setting up the new one and migrating the data across.
You don't have to significantly alter apps (in that stack) to be heroku-compatible.
You can have the best of both worlds with Cloud66. (git-based deployment, but you pay a small fee - $19 first server, $9 additional) and it targets cloud provider of your choice, with instance sizes you choose. (no I'm not a Cloud66 employee, but happy with their service)
Cloud66 was hacked in May 2013[1][2] and shortly afterwards, they scrubbed all references to the attack from their site. Pathetic.
[1] https://news.ycombinator.com/item?id=5669315
[2] https://news.ycombinator.com/item?id=5685406
[1] https://news.ycombinator.com/item?id=5669315
[2] https://news.ycombinator.com/item?id=5685406
They're not the first to get hacked, but covering it up is definitely concerning.
Heroku's value-add is that you don't need a system administrator: if they support the services your app needs, then they automate system administration for you.
Digital Ocean will sell you a VPS (essentially a machine) and grant you root-level access to it. You can run whatever you want, and deploy and manage it however you want.
Heroku will sell you a dyno (essentially a worker process) and grant you access to a set of deployment and management tools. You push your application code up to Heroku, and it automatically sets up the front-facing web server, the database, the cache service, etc., according to the add-ons you've selected. If you need to scale up, just purchase more dynos.
For complex apps, Heroku might not meet your needs and you might want some VPSs instead. In terms of price, though, you'd need to include system administration man-hours when comparing.
Digital Ocean will sell you a VPS (essentially a machine) and grant you root-level access to it. You can run whatever you want, and deploy and manage it however you want.
Heroku will sell you a dyno (essentially a worker process) and grant you access to a set of deployment and management tools. You push your application code up to Heroku, and it automatically sets up the front-facing web server, the database, the cache service, etc., according to the add-ons you've selected. If you need to scale up, just purchase more dynos.
For complex apps, Heroku might not meet your needs and you might want some VPSs instead. In terms of price, though, you'd need to include system administration man-hours when comparing.
Not as feature rich as Heroku, but AWS' Elastic Beanstalk was so much easier for me to get my Java/Spring application up and running. I had endless headaches on Heroku. Elastic Beanstalk was simple upload a WAR and off to the races. Considering most folks probably wind up with AWS as a deployment target and EB is at no additional cost over the normal AWS costs, it's probably worth looking into right off the bat.
Basically it comes down to time. I used to run a small business that depended on a Rails app. It was much easier to let Heroku manage the headaches of sys admin type duties than to manage servers myself. Below a certain scale, the money cost of using a platform-as-a-service like Heroku is cheaper than the dollar cost of managing servers and/or having an ops person.
I started with Heroku because it was so fast to get started. The documentation is very good and there are a lot of features that have allowed me to spend more time on building our app as opposed to doing devops/sysadmin. Some things I can do with one command: zero downtime deploy, rollback a release, add/remove dynos, provision a database. The list goes on. I've had several aha moments. My first rollback was a pretty big deal. I had a bunch of dynos running (12 or so) and I pushed a bad deploy. With one command, I was running the previous (working) version of the app. Actually, it was more like a "phew" moment.
Everyone here is right about the costs. It's very expensive. Especially compared to AWS and DO. But how much is your time worth to you? If I have to spend an extra $300 a month on hosting, that's fine--as long as I'm saving more than, say, 3 hours of time not doing sys admin. The dynos are expensive, but you don't have to provision machines and setup autoscaling groups. The database is expensive, but backups and upgrades take only minutes. The addons are all expensive, but... you get the idea.
I've run into limitations of Heroku and we now use AWS as well. I really like AWS, but it's a lot more work. The documentation takes more effort to read, initial setup is more complicated (AMI, IAM roles, Elastic IP, key pairs, etc). AWS is cheaper and the product is great and it does things Heroku can't, but I spend much more time on it.
Everyone here is right about the costs. It's very expensive. Especially compared to AWS and DO. But how much is your time worth to you? If I have to spend an extra $300 a month on hosting, that's fine--as long as I'm saving more than, say, 3 hours of time not doing sys admin. The dynos are expensive, but you don't have to provision machines and setup autoscaling groups. The database is expensive, but backups and upgrades take only minutes. The addons are all expensive, but... you get the idea.
I've run into limitations of Heroku and we now use AWS as well. I really like AWS, but it's a lot more work. The documentation takes more effort to read, initial setup is more complicated (AMI, IAM roles, Elastic IP, key pairs, etc). AWS is cheaper and the product is great and it does things Heroku can't, but I spend much more time on it.
"git push origin master" is effectively 100% of your DevOps. Running a web application reliably and at scale on IaaS requires effort and skill; Heroku will make it so you effectively don't have to have those skills or spend that effort, for a fee. Cheaper than hiring a DevOps team.
Most large tech companies with an infrastructure/DevOps team are trying to create an "internal Heroku" - and, at best, coming pretty close.
Most large tech companies with an infrastructure/DevOps team are trying to create an "internal Heroku" - and, at best, coming pretty close.
PaaS solutions are worth more than IaaS I think -- someone is applying security patches, autoscaling your app, load balancing, etc. For a more apples to apples comparison:
It's 5x the cost of Elastic Beanstalk... 250 / (0.067 * 24 * 365 / 12) = 5.11 -- though this is misleading because the closest instance was an m3.medium, which has 3 vcpus and 3.75gb of ram. You can also get a major discount if you go reserved.
It's 0.68x the cost of App Engine F4 instances (the biggest available).. 250 / (0.20 * 2.5 * 24 * 365 / 12), though those only have 1G of ram, so that's assuming you somehow buy 2.5 of them :p
It's 2.2x the cost of AWS Lambda... 250 / ((0.000001667 + 0.000002501) * 10 * 60 * 60 * 24 * 365 / 12) = 2.28, though this is misleading because it'm adding up a 1.5gb instance and a 1gb instance. Also it's likely much cheaper as Lambda only charges you for used time, and almost all traffic loads are TOD / DOW dependent.
It's 5x the cost of Elastic Beanstalk... 250 / (0.067 * 24 * 365 / 12) = 5.11 -- though this is misleading because the closest instance was an m3.medium, which has 3 vcpus and 3.75gb of ram. You can also get a major discount if you go reserved.
It's 0.68x the cost of App Engine F4 instances (the biggest available).. 250 / (0.20 * 2.5 * 24 * 365 / 12), though those only have 1G of ram, so that's assuming you somehow buy 2.5 of them :p
It's 2.2x the cost of AWS Lambda... 250 / ((0.000001667 + 0.000002501) * 10 * 60 * 60 * 24 * 365 / 12) = 2.28, though this is misleading because it'm adding up a 1.5gb instance and a 1gb instance. Also it's likely much cheaper as Lambda only charges you for used time, and almost all traffic loads are TOD / DOW dependent.
It seems like they still struggle with Security exploits--It's not a perfect system. For example:
https://blog.heroku.com/archives/2013/1/9/password_hijacking...
Also, you could get pretty solid protection and faster response time with something like unattended-upgrades
https://help.ubuntu.com/community/AutomaticSecurityUpdates
I think the value proposition mostly lies in the autoscaling, but seems like a waste in aggregate since most apps never hit any sort of scale.
https://blog.heroku.com/archives/2013/1/9/password_hijacking...
Also, you could get pretty solid protection and faster response time with something like unattended-upgrades
https://help.ubuntu.com/community/AutomaticSecurityUpdates
I think the value proposition mostly lies in the autoscaling, but seems like a waste in aggregate since most apps never hit any sort of scale.
In fairness to Heroku you're citing a security issue with the heroku.com webapp, not an issue with the platform they're selling.
Also: as long as traffic spikes remain a thing, autoscaling isn't wasteful... The alternatives are your site going down or buying bigger servers than you need in the first place...
(That's not to say I approve of heroku though, the foundation it supplies is horrible, and missing basic things like [gzip'd asset transfers](https://stackoverflow.com/questions/12326191/any-way-to-serv...)...)
Also: as long as traffic spikes remain a thing, autoscaling isn't wasteful... The alternatives are your site going down or buying bigger servers than you need in the first place...
(That's not to say I approve of heroku though, the foundation it supplies is horrible, and missing basic things like [gzip'd asset transfers](https://stackoverflow.com/questions/12326191/any-way-to-serv...)...)
Digital Ocean, Linode, etc. are do-it-yourself platforms. If you have the time and knowledge to install, configure, secure, monitor, etc. etc. all the services that go into a typical application, then spending the time yourself will save you money.
On the flip side, if you have the money but lack time, knowledge, or desire to manage all that complexity just pay Heroku to do it for you... or any other PaaS for that matter.
I've never used Heroku, but long ago I reached a point where dealing with hardware, services, networking, server racks, etc. got really boring. Today, I expect computing resources to be little more than appliances where I can effectively say "Here's the code I want you to run. Make it happen." and not have to even think about firewalls, scalability, failover, backups, software conflicts/compatibility, security updates, and a hundred other things. If you're managing all that yourself, you're basically doing a job that a computer ought to be doing on your behalf based on a specification you've provided.
On the flip side, if you have the money but lack time, knowledge, or desire to manage all that complexity just pay Heroku to do it for you... or any other PaaS for that matter.
I've never used Heroku, but long ago I reached a point where dealing with hardware, services, networking, server racks, etc. got really boring. Today, I expect computing resources to be little more than appliances where I can effectively say "Here's the code I want you to run. Make it happen." and not have to even think about firewalls, scalability, failover, backups, software conflicts/compatibility, security updates, and a hundred other things. If you're managing all that yourself, you're basically doing a job that a computer ought to be doing on your behalf based on a specification you've provided.
Don't forget that with Docker, Vagrant, Salt, Puppet, StackScripts, etc you can turn DigitalOcean or Linode into your own platform. Best of both worlds.
Takes away quite a bit of administration work, which isn't exactly free either, especially if you don't have the expertise for it in your team.
Especially for smaller projects deploying them on heroku instead of worrying (and spending time on) about setup, deployment, patches, ... is an attractive option.
Especially for smaller projects deploying them on heroku instead of worrying (and spending time on) about setup, deployment, patches, ... is an attractive option.
Just try it I'd say. Professionally, I do no Web development and software often runs on big iron machines. I tried out Heroku to inspire me on where I want my deployment process to be, and I might use it for the odd hobby project at home.
Dead simple stack deployment and automation. People are very willing to pay 10x the amount just to git init, git push and heroku add apps to their stack without worrying about anything else under the hood.
It reduces the number of engineers you have to hire to maintain your DO / AWS deployments.
As engineering talent becomes more scarce and expensive, the appeal of such a solution ironically increases.
As engineering talent becomes more scarce and expensive, the appeal of such a solution ironically increases.
>What features in the Heroku platform justify that?
Not having to care about deployment that much.
Not having to care about deployment that much.
I wonder if the 2 cores presented are dedicated on DO?
It's all kind of opaque.
It's all kind of opaque.
If you want to know, in general, what Heroku is, don't bother with their web pages. It's marketing fluff.
The first paragraph in Wikipedia is a concise explanation. https://en.wikipedia.org/wiki/Heroku
The first paragraph in Wikipedia is a concise explanation. https://en.wikipedia.org/wiki/Heroku
I'm wondering what people need this much RAM for? Wouldn't it make more sense to just spin up more dyno's with fewer instances of your app running on each dyno?
Depends on what you're doing. I've worked on systems where we had 72gb and 96gb of RAM, and we tuned them within an inch of their lives.
But hey, 512k is good enough for anyone, Bill Gates once said.
edit: If I was doing something memory-intensive or performance-intensive, I wouldn't be on Heroku anyway.
But hey, 512k is good enough for anyone, Bill Gates once said.
edit: If I was doing something memory-intensive or performance-intensive, I wouldn't be on Heroku anyway.
I'd assume its for worker dynos with a process which cant easily scale horizontally.
I'm running a game server in node.js where the app's state is persistent so can't really so can't really spin up more dynos. The whole server lives in that particular instance.
I'm not that familiar with dynos but I can see how people would need even more than 2.5gb for specific jobs. We push the limits of servers with 512gb of RAM regularly.
Worth noting that you can get 16GB RAM on AWS or Digital Ocean using Cloud66 and have almost the same deployment experience, for less.
Off topic: What's the best free alternative for small side projects?
Closest thing with a "full" free tier I know about is OpenShift. (For some stuff, heroku's free tier still can work out fine)
Yeah. I think Heroku is the best choice right now.
A web dyno and a worker dyno running 18h/day for free
AWS opsworks is free, you pay for the instances. So a small app can be free with their free tier for one year.
convox.io is pretty awesome for deploying docker applications to AWS ~ part of the current ycombinator batch.
Had pricing ever been an issue for any of you?