21–30 of 63 posts
Heroku is Just Unix At its core, Heroku is just a simple unix platform; specifically, Ubuntu 10.04 LTS. I just threw up a little
Why?
I got what the author meant though, and it's not that big a deal.
512MB of RAM, 1GB of swap. Total = 1.5GB RAM. 4 CPU cores (Intel Xeon X5550 @ 2.67GHz)."
That is very interesting. So you get 200% of the CPU from a c1.medium but only 1/6 that memory? For 1/8 the price that Amazon charges? Maybe this is a the new math I keep hearing about.
I love this post, and hope it keeps coming up. Some day, developers will learn that even though they could do it as well as Heroku, given enough time and effort, it's just a lot cheaper not to! This comes up all the time with my company. We make hosted Continous Integration ( https://circleci.com ), and often hear "can't I just set up Jenkins?". And the answer is the same, "you could, but ...". Run it on EC2, where y…
The persistence scaling story for Heroku seems pretty questionable to me. Once you've maxed out what they offer for MySQL and Postgres, what exactly are you supposed to do? Start using EC2 RDS? Heroku seems to be like a more useful Google App Engine, a good place to host a blog or experimental project if you're not into dev-ops. If you have a knack (at all) for dev-ops, you're not saving yourself anything. The downti…
1) If your app crashes it takes ages to restart dynos "automatically", there's nothing at all instant about it and if it's a bug and you have a high volume of requests it's going to hit every dyno which means you are offline.
2) Performance can be variable and it can be hard to be sure an optimization has done anything. This will be easier when New Relic supports NodeJS but right now you're stuck using less elegant solutions. It is shared hosting and it's not necessarily anybody's fault if something is slow, and I know this because the same requests frequently have orders of magnitude difference in response time for me.
dyno=web.10 queue=0 wait=0ms service=3ms status=200 bytes=25
dyno=web.7 queue=0 wait=0ms service=207ms status=200 bytes=28
I love this post, and hope it keeps coming up. Some day, developers will learn that even though they could do it as well as Heroku, given enough time and effort, it's just a lot cheaper not to! This comes up all the time with my company. We make hosted Continous Integration ( https://circleci.com ), and often hear "can't I just set up Jenkins?". And the answer is the same, "you could, but ...". Run it on EC2, where y…
The persistence scaling story for Heroku seems pretty questionable to me. Once you've maxed out what they offer for MySQL and Postgres, what exactly are you supposed to do? Start using EC2 RDS? Heroku seems to be like a more useful Google App Engine, a good place to host a blog or experimental project if you're not into dev-ops. If you have a knack (at all) for dev-ops, you're not saving yourself anything. The downti…
Earlier quoted context omitted.
Why?
I'm going to guess it's because Ubuntu was called "unix" (which actually raised my eyebrow as well). Although similar, unix != linux, and Ubuntu especially != unix, as opposed to a distro like Slackware, which is more or less unix with a linux kernel slapped in. I got what the author meant though, and it's not that big a deal.
When I really want to annoy my BSD friends, I call it a "Linux-like" operating system. It never fails.
"Each instance (Heroku calls them dynos), has: 512MB of RAM, 1GB of swap. Total = 1.5GB RAM. 4 CPU cores (Intel Xeon X5550 @ 2.67GHz)." That is very interesting. So you get 200% of the CPU from a c1.medium but only 1/6 that memory? For 1/8 the price that Amazon charges? Maybe this is a the new math I keep hearing about.
I love this post, and hope it keeps coming up. Some day, developers will learn that even though they could do it as well as Heroku, given enough time and effort, it's just a lot cheaper not to! This comes up all the time with my company. We make hosted Continous Integration ( https://circleci.com ), and often hear "can't I just set up Jenkins?". And the answer is the same, "you could, but ...". Run it on EC2, where y…
First the UI could use some work, but it was really awesome seeing it pull down a Flask app and knowing to activate venv and install pip.
Also, not having an option to delete your account is a bit scary, seeing as I'm part of an organization on github and not comfortable with you having access to that code.
Earlier quoted context omitted.
The persistence scaling story for Heroku seems pretty questionable to me. Once you've maxed out what they offer for MySQL and Postgres, what exactly are you supposed to do? Start using EC2 RDS? Heroku seems to be like a more useful Google App Engine, a good place to host a blog or experimental project if you're not into dev-ops. If you have a knack (at all) for dev-ops, you're not saving yourself anything. The downti…
> The persistence scaling story for Heroku seems pretty questionable to me. Agree. Those people who tell horror stories about Heroku/EC2, usually give solid numbers, i.e. this was how much I spent, this is how much I save by moving away, and our response time is now X% faster. On the other hand, we have article like this that shows pretty graph for a web app serving 16.2 requests per minute, and make bold claims that…
https://api.playtomic.com/load.html
Savings aren't exclusively because of Heroku, I also switched the underlying architecture during that migration from C# / ASP.NET to NodeJS which is exceptionally well suited to what I'm doing there.
Previously: Dedicated servers, ~$1600 a month
8x dedicated servers at ~$200 each, each running 3 to 5 instances of the API depending on how many IP addresses they were provisioned with. Uploading was done via a simple hand-rolled script that'd just FTP everything to each server.
Now: Heroku, current usage $400 - $500 a month
With Heroku I don't have to worry about concurrent connections (typically 200 - 400 thousand people at once), I don't have to maintain all those servers and I don't have to fuck around with all the stupid things that can go wrong when you're operating at scale.
It was a lot of work to get to this point and I made a lot of mistakes like having a heavy redis pub/sub outside of the EC2 network that cost me $350 in excess bandwidth providing inter-dyno communication, and I saturated database connections lots of times because in the old days those dedicated servers each had a local mongodb which could keep up with ordinary connection pooling, but it was totally worth it.