5 ms·

Heroku Architecture (Ruby in the cloud)

73 points by ropiku 18y ago

pclark 18y ago
that page is borderline unreadable.
goodgoblin 18y ago
Does anyone know how much this is going to cost? Is it a premiumm on top of Ec2 or something like that?
- cubicle67 18y ago
  At the moment, it's free. I've got a number of apps running, and I've got nothing but praise for Heroku. From what I remember, their plan was to bill based on usage, so if you have a quiet month, you get a small(ish) bill. Things get busy; you pay more.
yesimahuman 18y ago
That looks really interesting...but what's with all the ruby-only stuff? I haven't seen enough of a reason to move from python to ruby, and they both seem like appropriate technologies for something like this.
- mdasen 18y ago
  I think the Ruby-only shtick is that they want to do one thing and do it well. There's enough of a Ruby community that they can serve that niche and do it well. There's nothing so exceptional about what they're doing that it couldn't be done in Python with what is available (the exceptional part is that they execute well and are highly reliable). Basically, the benefit of Heroku is that they can keep extra hardware on hand for spikes and there's a decent assumption that, say, your site spikes to 300% of normal once a week, but that not all sites will be spiking at the same time. Therefore, you get more efficient utilization of resources. But you could do this yourself - it would just mean that you would need to buy all the capacity to handle spikes while Heroku works off the assumption that part of that spike capacity can be shared since not all sites will spike at once.
  - davidw 18y ago
    > decent assumption that, say, your site spikes to 300% of normal once a week, but that not all sites will be spiking at the same time. This reminds me of something.... what is it... oh yeah, the economy. It's probably a better assumption than some of the junk that went on to tank the economy, but I'd still be interested in learning more about spike distributions. Amazon probably has some good data.
helium 18y ago
I have played with heroku in the past(what is now herokugarden.com) and I have to say I have been keeping an eye on this. It seems they have abandoned the whole web-editor idea and focused solely on the ruby\rails hosting-in-the-cloud aspects. Good way to go IMHO. The web-based editor was cool and all, but most people still wouldn't use it and just upload their apps or use git. I just registered for a beta-invite, so here goes!
- jedc 18y ago
  The ruby/rails hosting-in-the-cloud is a much bigger "value-add" than editing in the browser. I've been using them for a while and really like the way they're headed. Yes, they're Ruby/Rails-centric, but don't see why they have to stay there once they've established a real foothold in that market.
axod 18y ago
Routing mesh? Dyno grid? Compiled slugs? A Dyno has SEVEN layers? Grey font on grey background? Man I feel old.
- igorgue 18y ago
  Don't care about their style, its a very nice service, I wish somebody do it for Django+Python (or maybe a improvement to Google Appengine)
  - axod 18y ago
    OR you could just go the old way and buy hosting and use something that scales well.
    - moe 18y ago
      Care to elaborate on "use something that scales well"? It seems that's exactly what heroku is offering, no?
      - axod 18y ago
        For example, say you create a simple php website which has a single database. That could be a problem when it comes to scaling. Choosing something other than a database, and something other than php may make far more sense than something that 'helps php database apps scale'.
        moe 18y ago
        So, you're suggesting that joe sixpack should rather build his own heroku?
        axod 18y ago
        No, just that there are other ways to solve scaling that can be as simple as changing framework/language/db/architecture etc As I said though, more likely I'm just getting old...
moe 18y ago
I'm impressed, and that doesn't happen so often. The ruby and database lock-in need to go away - then you have a winner, hands down. This is actually my only recommendation to you guys: Don't limit yourselves to being the AppEngine for rails. Open up a bit and you'll wipe the floor with RightScale & friends, too.
- ericwaller 18y ago
  From this architectural overview it looks like they're ready for it. Presumably a "dyno" could run anything that speaks http.
  - cakeface 18y ago
    That would be fantastic. It would be so cool if you could launch a python, or even java dyno. I think most webapps could be structured to fit into this architecture, with the caveat of using ruby specific management tools such as rake.
    - jedc 18y ago
      I highly doubt they'll want to or be able to spend much time getting other "dyno"'s working until they've got a solid customer base with RoR. No reason to spread themselves too thin until they can demonstrate they can serve their customers well with what they already have. That said, I do hope they eventually will.
igorgue 18y ago
I like it!, they are going to be huge!, if they add Python + Django and maybe PHP they'd be the most awesome service.
bryanwoods 18y ago
I've been really excited for this for about a year now, and have been having a great time playing with the pure Git workflow. If you look at this problem in one direction (only does Ruby, won't kill the AppEngine), you're probably missing the point. We were about to bring our apps to Engine Yard's Solo EC2 management system, and Heroku's essentially deprecated similar offerings from a bunch of companies all over the place. I'm sure adding new technologies and languages will bring more people over in the future, but for now it seems like this platform could end up being a great reflection of the current state of the Ruby, with our preference for all things distributed and collaborative like cloud hosting and Git source control.
jshen 18y ago
I love that it's on ec2. This allows me to do things like setup a lucene/solr EC2 instance and talk to it from my heroku app with minimal latency. This is good stuff.
jim-greer 18y ago
Are there any high-volume apps using this yet?
deleted 18y ago
[deleted]
mchristoff 18y ago
i'm one of the lucky few hosting a few sites (not live yet) on the heroku platform and i can say that it's the best deployment experience i've ever had (prior to heroku i hosted my old startup on engineyard). literally all you need to do is a git push and your app is live in the cloud. i will speak more about scaling when i have an app that needs it, but for now the ease of deployment has got me hooked.
tlrobinson 18y ago
Looks awesome. Great website too. I'm having too much fun with the Dyno Grid page: http://heroku.com/how/dyno_grid http://heroku.com/how/dyno_grid

73 points by ropiku 18y ago

pclark 18y ago

that page is borderline unreadable.

goodgoblin 18y ago

Does anyone know how much this is going to cost? Is it a premiumm on top of Ec2 or something like that?

cubicle67 18y ago
At the moment, it's free. I've got a number of apps running, and I've got nothing but praise for Heroku. From what I remember, their plan was to bill based on usage, so if you have a quiet month, you get a small(ish) bill. Things get busy; you pay more.

yesimahuman 18y ago

That looks really interesting...but what's with all the ruby-only stuff? I haven't seen enough of a reason to move from python to ruby, and they both seem like appropriate technologies for something like this.

mdasen 18y ago
I think the Ruby-only shtick is that they want to do one thing and do it well. There's enough of a Ruby community that they can serve that niche and do it well. There's nothing so exceptional about what they're doing that it couldn't be done in Python with what is available (the exceptional part is that they execute well and are highly reliable). Basically, the benefit of Heroku is that they can keep extra hardware on hand for spikes and there's a decent assumption that, say, your site spikes to 300% of normal once a week, but that not all sites will be spiking at the same time. Therefore, you get more efficient utilization of resources. But you could do this yourself - it would just mean that you would need to buy all the capacity to handle spikes while Heroku works off the assumption that part of that spike capacity can be shared since not all sites will spike at once.
- davidw 18y ago
  > decent assumption that, say, your site spikes to 300% of normal once a week, but that not all sites will be spiking at the same time. This reminds me of something.... what is it... oh yeah, the economy. It's probably a better assumption than some of the junk that went on to tank the economy, but I'd still be interested in learning more about spike distributions. Amazon probably has some good data.

helium 18y ago

I have played with heroku in the past(what is now herokugarden.com) and I have to say I have been keeping an eye on this. It seems they have abandoned the whole web-editor idea and focused solely on the ruby\rails hosting-in-the-cloud aspects. Good way to go IMHO. The web-based editor was cool and all, but most people still wouldn't use it and just upload their apps or use git. I just registered for a beta-invite, so here goes!

jedc 18y ago
The ruby/rails hosting-in-the-cloud is a much bigger "value-add" than editing in the browser. I've been using them for a while and really like the way they're headed. Yes, they're Ruby/Rails-centric, but don't see why they have to stay there once they've established a real foothold in that market.

axod 18y ago

Routing mesh? Dyno grid? Compiled slugs? A Dyno has SEVEN layers? Grey font on grey background? Man I feel old.

igorgue 18y ago
Don't care about their style, its a very nice service, I wish somebody do it for Django+Python (or maybe a improvement to Google Appengine)
- axod 18y ago
  OR you could just go the old way and buy hosting and use something that scales well.
  - moe 18y ago
    Care to elaborate on "use something that scales well"? It seems that's exactly what heroku is offering, no?
    - axod 18y ago
      For example, say you create a simple php website which has a single database. That could be a problem when it comes to scaling. Choosing something other than a database, and something other than php may make far more sense than something that 'helps php database apps scale'.
      - moe 18y ago
        So, you're suggesting that joe sixpack should rather build his own heroku?
        axod 18y ago
        No, just that there are other ways to solve scaling that can be as simple as changing framework/language/db/architecture etc As I said though, more likely I'm just getting old...

moe 18y ago

I'm impressed, and that doesn't happen so often. The ruby and database lock-in need to go away - then you have a winner, hands down. This is actually my only recommendation to you guys: Don't limit yourselves to being the AppEngine for rails. Open up a bit and you'll wipe the floor with RightScale & friends, too.

ericwaller 18y ago
From this architectural overview it looks like they're ready for it. Presumably a "dyno" could run anything that speaks http.
- cakeface 18y ago
  That would be fantastic. It would be so cool if you could launch a python, or even java dyno. I think most webapps could be structured to fit into this architecture, with the caveat of using ruby specific management tools such as rake.
  - jedc 18y ago
    I highly doubt they'll want to or be able to spend much time getting other "dyno"'s working until they've got a solid customer base with RoR. No reason to spread themselves too thin until they can demonstrate they can serve their customers well with what they already have. That said, I do hope they eventually will.

igorgue 18y ago

I like it!, they are going to be huge!, if they add Python + Django and maybe PHP they'd be the most awesome service.

bryanwoods 18y ago

I've been really excited for this for about a year now, and have been having a great time playing with the pure Git workflow. If you look at this problem in one direction (only does Ruby, won't kill the AppEngine), you're probably missing the point. We were about to bring our apps to Engine Yard's Solo EC2 management system, and Heroku's essentially deprecated similar offerings from a bunch of companies all over the place. I'm sure adding new technologies and languages will bring more people over in the future, but for now it seems like this platform could end up being a great reflection of the current state of the Ruby, with our preference for all things distributed and collaborative like cloud hosting and Git source control.

jshen 18y ago

I love that it's on ec2. This allows me to do things like setup a lucene/solr EC2 instance and talk to it from my heroku app with minimal latency. This is good stuff.

jim-greer 18y ago

Are there any high-volume apps using this yet?

deleted 18y ago

[deleted]

mchristoff 18y ago

i'm one of the lucky few hosting a few sites (not live yet) on the heroku platform and i can say that it's the best deployment experience i've ever had (prior to heroku i hosted my old startup on engineyard). literally all you need to do is a git push and your app is live in the cloud. i will speak more about scaling when i have an app that needs it, but for now the ease of deployment has got me hooked.

tlrobinson 18y ago

Looks awesome. Great website too. I'm having too much fun with the Dyno Grid page: http://heroku.com/how/dyno_grid http://heroku.com/how/dyno_grid