How Heroku Works

https://devcenter.heroku.com/articles/how-heroku-works

by swampthing • 13 years ago

156 36 13 years ago

devcenter.heroku.com

benhalllondon• 13 years ago

Re: The Rap Genius Question:

"""A random selection algorithm is used for HTTP request load balancing across web dynos""

bit more....

"""and this routing handles both HTTP and HTTPS traffic. It also supports multiple simultaneous connections, as well as timeout handling."""

positr0n• 13 years ago

    For example, dynos are cycled at least once per day

Why so often? I wonder if this is just to protect against memory leaks leading to poor performance from poorly coded apps or if it's an issue with their infrastructure.

gkop• 13 years ago

For one thing, it demonstrates empirically that the app can be successfully restarted.

derefr• 13 years ago

I would bet it's horizontal migration to "compact" dynos down onto fewer servers during off-hours, so they can terminate some of their EC2 instances. Basically, generational garbage collection performed on VM containers.

bifrost2• 13 years ago

I have yet to see one rails app that doesn't leak memory like crazy, this is the easiest way to maintain sanity :)

ryan-allen• 13 years ago

Stop using RMagick!

davidbanham• 13 years ago

""""If you’re using some established framework, Heroku can figure it out. For example, in Ruby on Rails, it’s typically rails server, in Django it’s python <app>/manage.py runserver and in Node.js it’s node web.js."""

Been working in node for years now, have never named anything web.js. Why not index.js, server.js or app.js?

sksksk• 13 years ago

You define the start command in the package.json anyway, so presumably Herkou can just read that?

tlrobinson3• 13 years ago

Yeah I think that's a relic of their very early Node.js beta. Now they look for package.json (https://github.com/heroku/heroku-buildpack-nodejs/blob/maste...) and you define the command to start the app in the Procfile.

jonmountjoy2• 13 years ago

Dang - thanks for catching. Fixed.

bradhe3• 13 years ago

Does...it really matter?

tlrobinson3• 13 years ago

Here's my outsider's analysis of how Heroku works (well, worked in 2011) from a couple years ago: https://www.quora.com/Scalability/How-does-Heroku-work

hk__2• 13 years ago

Here is the full link, for those that are not on Quora: https://www.quora.com/Scalability/How-does-Heroku-work/answe...

diminish• 13 years ago

Has the whole or parts of the architecture been made available as open source?

I want to create a container based PAAS architecture myself, based on docker etc. Does anyone recommend a ready made solution similar to heroku, to serve ruby web apps.

bradleyg_• 13 years ago

This looks promising https://github.com/progrium/dokku and even uses Heroku buildpacks.

zeckalpha3• 13 years ago

https://github.com/ddollar/foreman is what is used for the local testing, but also for the actual running of the app on the Cedar stack. One could use Foreman and Docker and AWS to make a pretty reasonable PaaS.

(I'm working on a S3 static-site-only version of Heroku so people don't have to serve static sites behind 3 layers of web servers.)

opdemand• 13 years ago

Deis will be released soon. It's an open-source PaaS based on Docker & Chef, with a user experience modeled after Heroku. You create a "formation" which contains a configurable number of backends and Nginx proxies. After you git push your app to the formation, you can scale web=N worker=N just like Heroku. Deis will automatically balance Docker containers across the backends, reconfigure routing, etc.. all using Chef. The goal is to provide a Heroku-like platform where you control everything: Chef Server, PaaS controllers, hosting providers, routing layer, etc..

oelmekki3• 13 years ago

Terminology: Dynos are isolated, virtualized Unix containers, that provide the environment required to run an application.

... also known as "process".

codebeaker• 13 years ago

Actually I believe the containers are implemented with something similar to http://lxc.sourceforge.net/ which is more akin to a process level chroot, and kernel resource limits. This also the same technology that fundamentally underpins Docker and some other similar super-lightweight virtualisation technologies. With lxc and buildroot, for example it's trivial to create a self-contained 20Mb image for running a PostgreSQL server. With all the security guarantees [sic] that would be provided by paravirtualisation.

oelmekki3• 13 years ago

(this reply is for jschulenklopper too)

Certainly, it was provocative of me to imply it was that simple : when you have to deal with processes at this scale, you can't do it without any sandboxing if you want to avoid users messing with one another.

It's still the basic scheme, though : when you rent dynos, you actually rent processes. That's the heroku business model (with all the deployment sugar on top of it, of course), and I'm always surprised people are ok to pay that much to rent processes.

Of course, one could argue you can spawn multiple processes in a dyno. But 1. thoses processes have to consume very low memory because of low memory limits of dynos and 2. this could lead to boot up nightmare.

Before the "rap-genuis-gate", the company I worked for then had scalability issues with heroku, being the later described router random timeout problem. Our dyno costs were already very high, even when using hirefire, so adding more dynos sounds not a good option.

We tried to replace thin with unicorn, which was later the proposed solution from heroku. But even with two unicorn workers, we reached memory limits. Even worse : when dyno booted unicorn master process, it considered itself ready, while unicorn was still spawning its children, so it ends up with more failed requests.

Bottom line is : using (and paying for) a heroku dyno is basically the same as using a process on a dedicated server. That may not be a problem, provided heroku clients are aware of that, and are not sold dynos as if it was what we all know as virtual servers.

jschulenklopper3• 13 years ago

No, dynos are 'containers', not processes. Those run inside the dynos. From the documentation at https://devcenter.heroku.com/articles/dynos: "The commands run within dynos include web processes, worker processes".

jonmountjoy2• 13 years ago

Yes absolutely. A process is something that can run within a dyno. The root process is typically the one defined in the Procfile. It may spawn sub-processes, all running within the same dyno.

znowi• 13 years ago

Since Heroku's Ugly Secret I don't trust this company.

http://news.rapgenius.com/James-somers-herokus-ugly-secret-l...

happywolf2• 13 years ago

Not trusting a company that has a record of inaccurate documentations, and a record of ignoring customer complaints until got hammered hard (enough)

psychometry• 13 years ago

Well, they're obviously working on improving their documentation and have made public statements about some of the high-profile complaints. Is that not what you want? Or would you prefer they do nothing so that you can continue making tired accusations against them?

happywolf2• 13 years ago

How do you know they document accurately this time? 'Obviously' as compared to what? Except if you have internal access to their source code and be able to verify against the documentation.

I am always happy to give honest mistakes a chance, but not to a company who ignored customers complaints for years, sold inaccurate tools for big bucks, and tried to obfuscating documentation to hide the change of algorithm in request routing at dyno level. Sorry, I just find these acts are bordering evil, and my money will go to other businesses. If you are not so sure what I am talking, read the following link and see how Heroku's CTO and COO responded to complaints.

http://news.rapgenius.com/Lemon-money-trees-rap-genius-respo...

How Heroku Works

Related Stories