10 ms·
Heroku XL
- zrail 13y agoThere's also a more informative blog post here: https://blog.heroku.com/archives/2014/2/3/heroku-xl https://blog.heroku.com/archives/2014/2/3/heroku-xl
- seanhandley 13y agoThanks - this is a much better resource than the marketing page!
- ROFISH 13y agoHeroku'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. :/
- rplnt 13y agoAnd 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.
- neilmiddleton 13y agoThere is no vendor lock-in with any aspect of Heroku. https://www.heroku.com/policy/promise https://www.heroku.com/policy/promise
- talkingquickly 13y agoThey don't actively lock you in which is great but you will almost certainly end up with bits of your workflow which are extremely dependant on Heroku. IMO pure AWS has exactly the same problem if not more. If you compare this to deploying to "choose a generic VPS" the lock in is substantial. If any of my apps fail, I'm comfortable I can provision an Ubuntu VPS from any provider with a one line chef command and then deploy to it with one more. So although Heroku isn't locking you in through any bad practices on their part, by using them you're choosing to make your workflow very specific to them. To me and quite a few of my clients, while Heroku is awesome for getting started, there isn't enough benefit for the increased single provider dependency and costs. Not hating on them at all, I use them quite regularly, but I can understand where people are coming from when they talk about Vendor lock in. Perhaps a more accurate description would be single vendor dependency.
- mwcampbell 13y agoWhy can't you write a Chef cookbook, Ansible playbook, or the like to deploy a 12-factor-compliant app on a generic VPS? Especially since all the Heroku buildpacks are open source?
- talkingquickly 13y agoI think it's less that you can't and more that most people won't. The reason I know I can provision a new server for app x without hassle is because the chef setup to do it gets used regularly, it's part of the workflow of developing the app. If it breaks I know it's broken because next time me or someone in the team spins up a staging enviro, it won't work. If you're using Heroku sure you could write that cookbook but in 90% of cases it's going to end up being unmaintained because it's there as a contingency that no-one uses in their everyday workflow. What's more for it to have real value it needs to be tested regularly to make sure it actually functions as expected. So it's definitely possible to avoid the dependency as long as you don't mind adding a big chunk of devops work. At that point you've got to ask why are you paying the premium for Heroku if you're maintaining the devops expertise and codebase to deploy to a VPS alongside?
- cmelbye 13y agoYeah, I don't buy that. The build packs are open source. Clone them and use them to build your app. It's no different than Heroku. Yeah, you have rebuild some of the stuff they were giving you for free, but that's the whole premise behind their business. They handle things like deployments, etc. so that you don't have to.
- rplnt 13y agoWell, you can't just take your app as is and move it elsewhere, can you?
- film42 13y agoKind 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.
- ctide 13y agohttps://blog.heroku.com/archives/2009/4/24/commercial_launch 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/announcing-lower-amazon-ec2-instance-pricing/ 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.
- eli 13y agoshrug I kinda feel like the service is either worth it to you at the price they're charging... or it isn't. I don't particularly care what their wholesale costs are.
- ctide 13y agoThe price they're charging is their price minus the Amazon price. You are paying for a set of tools that sit on top of Amazon. You choose to either invest in those tools yourself (and save the the difference between Heroku and Amazon) or you don't. Every time Amazon reduces prices, this means the cost of those tools increases. Since Heroku has launched, the price of those tools has steadily increased by virtue of not staying in line with Amazon's price reductions.
- eli 13y agoI get what you're saying... but the price they're charging is the price they're charging. The whole point is that I don't have to care how they make it work, just that it does work. Would the price for Heroku magically become "better" if they decided to switch from Amazon to a more expensive or less efficient backend? That can't be right. Heroku has many alternatives -- hosting directly on Amazon among them -- but (IMHO) there are not many direct competitors. Doing it any other way involves different tradeoffs of time, money, skill, and maybe lock-in risk. I sometimes buy a burger at a restaurant even though I know I can make one at home. That doesn't automatically mean it was a bad call even if raw beef is on sale at the supermarket.
- acjohnson55 13y agoI 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 13y agoHeroku 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 13y agoDokku does just that: https://github.com/progrium/dokku https://github.com/progrium/dokku It's even based on heroku buildpacks so it's very compatible.
- rgbrgb 13y agoDokku is far from stable and it's still going to be a bit more intensive than flipping a switch when you have to scale. The beautiful thing about heroku as a product is it removes an entire domain of skills/worries from building your app. Like Heroku is your linux/ops person.
- neilmiddleton 13y agoHow's your bandwidth bill?
- happywolf 13y agoA 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-manager 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-annotated http://news.rapgenius.com/James-somers-herokus-ugly-secret-a...
- strmpnk 13y agoWhile 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.
- bgentry 13y agothe dyno routing algorithm now routes requests to random dynos That's not a change; that's how routing on Cedar has always worked.
- thinkbohemian 13y agoRandom 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://wiki.nginx.org/LoadBalanceExample - http://serverfault.com/questions/537450/what-algorithm-does-amazon-elb-use-to-balance-load http://serverfault.com/questions/537450/what-algorithm-does-...
- machbio 13y agoSomeone 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 13y agoMaybe 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 13y agoHeroku 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.
- grandalf 13y agoHeroku 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.
- zrail 13y agoRunning 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 13y agoRunning rails on JRuby and Torquebox (especially the upcoming version 4) would provide MUCH better performance.
- mwcampbell 13y agoAm 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.
- grandalf 13y agoNot just concurrency but also boot time.
- ukd1 13y agoIt'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 http://i.imgur.com/BGKwGfp.png. Orange is perc99.
- thinkbohemian 13y agoThanks for sharing! Can you share your before and after web server configuration? Also what web server are you using, Unicorn?
- ukd1 13y agoRails 4, Grape, Postgres. We use unicorn; went from 3 workers to 30, though I've not had time to tune this since.
- thu 13y agoSo 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)?
- ukd1 13y agoYep, but it didn't help like this did. I don't have graphs for you I'm afraid.