Heroku XL

https://www.heroku.com/xl

by zrail • 12 years ago

88 64 12 years ago

heroku.com

zrail3• 12 years ago

There's also a more informative blog post here:

https://blog.heroku.com/archives/2014/2/3/heroku-xl

seanhandley• 12 years ago

Thanks - this is a much better resource than the marketing page!

ROFISH• 12 years ago

Heroku's $0.05/hr base pricing hasn't changed in a very long time, while Amazon has both dropped price and increased power.

I love Heroku's service, but it's starting to get very expensive. This $576/month plan proves it. :/

rplnt2• 12 years ago

And it still goes down when Amazon does (or has this changed?). Sure you get something extra, but paying more just to add another layer that can possibly fail? I don't know...

edit: Oh, and you are getting vendor-locked and they can go Google-App-Engine on you.

neilmiddleton2• 12 years ago

There is no vendor lock-in with any aspect of Heroku. https://www.heroku.com/policy/promise

film42• 12 years ago

Kind of. I've actually found that bundling my apps for heroku actually make them easier to move onto different platforms. The fact that I can run foreman start and have my dev environment running locally is extremely useful to our team.

ctide3• 12 years ago

https://blog.heroku.com/archives/2009/4/24/commercial_launch

It was .055 / hour when it launched in 2009. Back then, EC2 small instances cost .10 / hour (http://aws.amazon.com/about-aws/whats-new/2009/10/27/announc...).

Now? Heroku is .05 / hour, and small EC2 instances are .06 / hour. This is why I stopped using Heroku a year or so ago for anything I plan on paying for. They just let Amazon keep driving down their bottom line without passing any of those savings onto their customers.

acjohnson55• 12 years ago

I think Heroku is still a fantastic option for when you just need to get a beta system online. It's certainly a lot less intimidating than navigating the galaxy of AWS offerings. Trying to scale on Heroku doesn't seem like a great idea though.

camus2• 12 years ago

Heroku is the simplest Paas out there.And I like the fact that they built their deployement workflow on simple stuff like git and bash script,but yeah, it's quite expensive.

I wonder if i could reproduce this kind of workflow on my own server, since i dont really need load balancing or auto-scaling for most of my apis.

lbotos• 12 years ago

Dokku does just that:

https://github.com/progrium/dokku

It's even based on heroku buildpacks so it's very compatible.

neilmiddleton2• 12 years ago

How's your bandwidth bill?

happywolf• 12 years ago

A quick check on the documentation reveals instead of routing the requests to the first available or least loaded dynos, the dyno routing algorithm now routes requests to random dynos(Reference: https://devcenter.heroku.com/articles/how-heroku-works#dyno-...)

Routing requests to random dyno is definitely not the smartest routing algorithm because it kind of defeats the purpose of having a routing layer. If you are not aware of the issue between Heroku and Rap Genius, I will think it is important enough for anybody who considers Heroku to be aware of. Here is the URL with relevant information: http://news.rapgenius.com/James-somers-herokus-ugly-secret-a...

strmpnk• 12 years ago

While good for some dynos, it can be poor for others. Any system that handles singe requests serially is an irresponsible choice for anyone who might bother to look into queuing theory enough to blame the router but not be willing to blame their application server.

There are systems that do benefit from other kinds of routing but there is very little margin to favor non-concurrent request handling in mostly state-less components like web servers. There are lots of responses on the web that take a much deeper look at the heroku router if you care to search. The conclusion is not so clear that Heroku is doing it wrong.

bgentry2• 12 years ago

the dyno routing algorithm now routes requests to random dynos

That's not a change; that's how routing on Cedar has always worked.

thinkbohemian4• 12 years ago

Random routing is more or less industry standard. NGINX and ELB (what I would consider two gold standards for load balancing) both use Round Robin (non-inteligent, pseudo-random) routing variants:

- http://wiki.nginx.org/LoadBalanceExample

- http://serverfault.com/questions/537450/what-algorithm-does-...

zrail3• 12 years ago

This has been talked to death, but for the general case, for applications that can handle concurrent requests (like Rails with a rack server just a tiny bit smarter than Webrick), random routing works just as well as intelligent routing with far less coupling in the routing later, making it more robust and easier to manage and scale.

sync• 12 years ago

Rails servers like Unicorn can still only support ~4 concurrent requests on regular dynos (roughly 1 per virtualized core), lessening the problem but not solving it if you have many requests per second.

oillio3• 12 years ago

This is assuming the application developers understand the problem and write the application accordingly.

There are workarounds, which require some legwork and forsight.

Reducing the pitfalls inherit in deploying a web app is generally what Heroku is selling. It is why they are making the big bucks. It would have been nice if Heroku would have been able to find a solution and implement smarter routing so that this just became a non-issue.

machbio• 12 years ago

Someone explain me, why I would need a 6GB RAM machine over a dedicated server that I could have with 10 times more machine at the same price..

adamlett• 12 years ago

Maybe you don't have a full time sysadmin in your employ. Maybe you are a one-man team that would rather spend your time working on user-facing features instead of fiddling with infrastructure.

vetrom• 12 years ago

Heroku also folds bandwidth and electrical costs into their price model.

Having built a couple of cloudy services, I can confirm that these far dominate your costs at scale.

grandalf4• 12 years ago

Heroku made the bold decision to design its routing technology to be optimized for things like Node and Go rather than Ruby. So if you are using Ruby on Rails (like RapGenius) Heroku's platform will simply fall short, both in terms of efficiency and flexibility.

XL Dynos let you throw money at the random routing problem which helps routing efficiency at the expense of spend efficiency (b/c they are a lot more expensive and scaling down to 1 XL dyno is still pretty expensive).

In my opinion, if you're using anything other than 1X dynos on Heroku you are compensating for some other part of your stack being broken.

We're probably months away from Heroku having some serious competition in the super easy PAAS space. Heroku's high prices have summoned competitors en masse, and by some stroke of luck Amazon has not really made a serious effort to encroach on Heroku's profits.

zrail3• 12 years ago

Running modern Rails on a threading server like Puma, especially on JRuby or Rubinius, would probably get an application within the same ballpark of concurrency. At the very least it'd be better than Unicorn or Webrick or whatever the heck Rapgenius was using to serve their app.

programminggeek• 12 years ago

Running rails on JRuby and Torquebox (especially the upcoming version 4) would provide MUCH better performance.

mwcampbell2• 12 years ago

Am I correct in assuming that the relevant characteristic of Node and Go is high concurrency? If I'm not mistaken, Ruby can have that too, if you use something like Puma or Thin rather than Unicorn.

Python may be on the wrong side of this, though, as long as Gunicorn is the de-facto standard WSGI server for Python apps on Heroku.

grandalf4• 12 years ago

Not just concurrency but also boot time.

bgentry2• 12 years ago

In my opinion, if you're using anything other than 1X dynos on Heroku you are compensating for some other part of your stack being broken.

You may want to read this section: https://blog.heroku.com/archives/2014/2/3/heroku-xl#understa...

Performance dynos give you much higher performance and much better consistency, resulting in dramatically reduced tail latencies over 1X and 2X dynos.

Choosing performance dynos for a high-traffic or performance-sensitive app is definitely not "compensating for some other part of your stack being broken"; in fact it's a very smart choice.

mark_l_watson• 12 years ago

I tend to agree with you. For some large interconnected systems, long tail latencies have a high complexity cost because you need to code around the 1% cases when (for example) web service calls take much longer than normal to return results. Client code becomes more complex.

mjn• 12 years ago

Amazon has not really made a serious effort to encroach on Heroku's profits

Amazon hasn't, but there are a reasonable number of simple PaaS competitors these days:

Microsoft's Azure (http://www.windowsazure.com/en-us/pricing/details/web-sites/): ASP.NET, PHP, Node.js, Python

Red Hat's OpenShift (https://www.openshift.com/): Java, Ruby, PHP, Node.js, Python and Perl

Nodejitsu (https://www.nodejitsu.com/): Node.js

riffraff• 12 years ago

amazon has elastic beanstalk, but it's still not as easy as heroku.

shiftyrussian• 12 years ago

Ninefold.com has a wider choice of server sizes and is paas similar to heroku

oillio3• 12 years ago

It seems to me this move is to compensate for the well understood issues in their routing layer.

You can call these issues "bold decisions." In my opinion, it reads more like, "We don't know how to fix the problem. If you really want to pay for it, we will let you skip our routing layer and solve the problem yourself."

It is a bit disappointing. However, I've never had to write a routing layer to handle 60,000 requests a second, so I can't really fault them.

pvh• 12 years ago

XL dynos use the same router as everyone else.

AJ72• 12 years ago

Dyno Sleeping: Another interesting fact that hasn't been called out is that even with the Heroku XL Dyno, which costs ($580/mo), it will be spun down if not used for an hour. I don't understand how that matches the promise of 'performance' https://devcenter.heroku.com/articles/dynos#dyno-sleeping

ukd13• 12 years ago

It's made a massive difference to us; we've gone from 10 x 1x dynos to 2 x XL - it's done the following to our latency graph: http://i.imgur.com/BGKwGfp.png. Orange is perc99.

thinkbohemian4• 12 years ago

Thanks for sharing! Can you share your before and after web server configuration? Also what web server are you using, Unicorn?

ukd13• 12 years ago

Rails 4, Grape, Postgres. We use unicorn; went from 3 workers to 30, though I've not had time to tune this since.

thu• 12 years ago

So you changed from $0.50 / hour to $1.60 / hour. Did you first try with, say, 20 x 1x dynos (that would cost $1.00 / hour)?

ukd13• 12 years ago

Yep, but it didn't help like this did. I don't have graphs for you I'm afraid.

Heroku XL

Related Stories