As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm trying to decide between Heroku and Engineyard.
Heroku seems so much better but they charge for everything and their prices are crazy!
Why one should use Heroku over EY or vice versa?
Heroku makes setup and launching of an app super-simple. You will be dependent to some degree on versions that Heroku supports (for instance, I heard today of a bundler versioning issue).
One thing to take into account with any "managed full-stack" solution like Heroku or EY is cost. You don't have to hire an ops person or have ops expertise, but you're still paying. Storage is where things get really expensive. Crank up your DB to a more than a few GB and watch the price go up.
We have in-house ops (was me doing it while coding, now a dedicated person) and run on Joyent. A big cost savings was having a few master-slave DBs and sharing them among a few dozen applications. We essentially have 100 Facebook apps running on Joyent at the same cost as 10 apps on Heroku. But this doesn't take into account the ops salary/time.
Everyone's needs are different, but the great thing is that its easy to experiment with these cloud deployment tools in quick fashion, and you will find that they each have their own strengths that you can leverage as you need.
What is most valuable to me, and my smaller clients, is to be able to experiment and get end-user feedback quickly. I have startup clients that want to be able to push out new ideas and test them quickly, deploy different combinations of ideas to different markets, get customer feedback, and keep moving forward. Launch a facebook app, a test server for an API integration client, a lightweight 'freemium' version of a product, etc. As traffic picks up, we make changes to scale up, and the increase in cost is never out of bounds (eg. our hosting costs are still well under the increase in value/revenue/marketing juice, etc).
EngineYard lets you play around with 500hrs for free, and you can easily turn it off when you are not using it, to stretch the 500hrs out. You can deploy your app quickly, deploy a CI server (that updates the app on every successful build), create a backup of your app or 'staging' server and see how it goes.
Amazon will give you 750hrs per month for free, for a year, if you are a new AWS customer. You can use this for a super fast CI server, hard-core image processing, batch reporting, whatever.
Personally I happen to use Heroku the most, as it just seems to work the best for my needs. I can put together a new application with full monitoring, backup, analytics, email, etc really fast, and feel confident in how to manage my setup (and confident that I can bring another person on board, and their learning curve will be pretty easy). As a freelancer, my use of Heroku has brought my setup time down to almost nothing, so I'm able to focus my time on understanding the business, and developing a great product. I'm not saying that can't be done on other platforms, I'm just saying heroku is working great for me in that way.
I do have one app that processes Voip data over UDP, so I'll need to figure out if I prefer amazon or engineyard for that (heroku won't let you open a UDP port, as far as I know).
I recently put together a presentation on these tools, and how I use them. (it was for newer developers, so it may be too basic for this audience, but there is a list of pros/cons that others may find useful)
Also, I think this conversation does belong here, and not necessarily on a webmasters forum, because the choice of hosting platform will influence your development capabilities and architecture, and the people making the decision are developers, not 'webmasters' or systems people.
I'd vote to use EngineYard over Heroku. Although you can probably deploy a large scale application on Heroku, there's a lot of lock-in you'll have to endure and the pricing can become crippling at higher levels of use.
EngineYard does provide application-level support, too, which is a fair bit better than what Heroku does.
If you're making a quick hobby application or simple demo site, Heroku is great for launching small, simple instances. If you're building a real application where it will need to scale, use EngineYard.
We have been running our platform on Heroku for about 9 months, and I am very satisfied.
I think the biggest complaint that most people have is that it gets "expensive" when your site gets large or high traffic. Personally, I think it is much more effective to focus on growing your business or improving your value proposition than maintaining servers or figuring how to get Rails working. (It is no easy task unless you want to spend a lot of time figuring it out). I would much rather pay Heroku to manage the servers for me than hire someone.
Here's what's great about Heroku:
Pretty easy to use. I didn't know anything about Rails when I got started, and Heroku was simple to get working.
Good documentation for most things.
OK tech support.
Extremely cost effective when you are small.
Heroku is pretty smart, and I am sure they are going to read this, so here's what can be improved:
Tech support: Typically you ask a question and they respond, and that begs a new obvious question. The tech support person should answer the next question I am going to ask. For example, I might ask how to do something, and then they tell me a certain way of doing it. Now I need information about it. Supply all the information in the first response, so I don't have to ask, "How do I use it?"
Documentation: Everyone has the same questions. The documentation could be greatly improved by adding all the questions and answers that I have asked, let alone the tens of thousands of other customers.
Logs: The free logging options are useless, and $100/month for real logs is silly. Our solution has been http://papertrailapp.com which has been outstanding. Use it.
I might as well throw my opinion in here since I have "tried" to use EngineYard and "successfully" use Heroku. While I think both are potentially good choices, I found deploying to Heroku much easier. The ala-carte pricing for Heroku add-ons may add expense, but it also gives you the opportunity to add functionality immediately to your app. The largest expense for our app is the actual web dynos, followed by the database. Heroku has a great selection of add-ons, many of which are free or low cost.
EngineYard also seems like a great company but I think they "hold your hand" a little less than Heroku. For my company, the benefits of Heroku outweighed the cost issue. The read-only filesystem which is a platform feature of Heroku also forces you to learn some new tricks.
I now have several apps (small to medium) on Heroku and happily have my assets served up from s3.
In the end, I would encourage you to try them both. EngineYard offers a 500 hour trial (though that is computing hours, not necessarily real-time hours) and Heroku let's you get started right away for pretty much free.
PS: When selecting add-ons consider your choice carefully, just like when you choose gems for your project. I have experienced an add-on that I was using, simply flaming out and had to scramble to replace that functionality. What was it? Progstr-Filer, which I was using for file uploads. That was a lesson learned.
It depends of the condition. On some case, it's highly expensive
Here we can get a 24 GB o RAM dedicated server for 99 euros.
I can have it set up an running my rail app in less than half an hour, with a mongodb database, as many runner that I want, etc...
Additionally, I can add "small" other project (the ones that costs between 15$ and 35$ monthly at Heroku)
If your business require huge amount of data and processing power, my advice is to use a dedicated hosting and spend the time in managing and monitoring your app.
Related
I have been using Heroku up to now, but need to offer something more "enterprise-y" to an organisation that would otherwise insist on local server deployment.
AWS VPC sounds like the ideal infrastructure to use. I'll have Rails + Postgres + AWS S3.
Maybe a silly questions, but is there an automated PaaS that runs on top of AWS? Such that we own the AWS account but can outsource the server admin side? Or is this just a case of having to hire a consultant and deal with upgrades etc. as they arise?
is there an automated PaaS that runs on top of AWS?
Yes, there are LOTS of them. They range in spectrum from "a thin layer on Elastic BeanStalk" to wanna-be Heroku clones. (From my experience, most don't think about HA enough, so it works great, but has plenty of Single Points of Failure that can bite you down the road. But maybe you don't need so many nines of availability at first. Anyone remember Twitter in the early days?)
There are plenty of points in between, such as EC2 Containers, OpsWorks, Flynn, CoreOS, etc. Even Empire which I haven't looked at yet.
Every PaaS is a "Straitjacket" that reduces your "freedom to do anything" in exchange for "simplifying some things". That trade-off is not a constant, nor universal.
A PaaS that works for one company may not work for another, or even the same company six months later. I frequently see companies use Heroku or Google AppEngine for months/years, then suddenly hit a wall and need move off of it. After, they wonder why they put up with the limitations for so long.
we own the AWS account but can outsource the server admin side?
Yes, you can easily pay someone to setup a "PaaS" for you. The problem is they have to have a lot of knowledge to know which one will work best. (Few people have tried them all and talk intelligently about the trade-offs between them all. And new ones get written practically every day.)
The one universal thing: Companies rarely outgrow AWS. (Remember Zynga? They thought they were "spending too much money" on AWS, so they built their own datacenter. It supposedly "saved them money" until their fortunes turned around. Then that datacenter became a boat anchor that pulled them under. Ooops.)
Or is this just a case of having to hire a consultant and deal with upgrades etc. as they arise?
You need to think deeply about what it is that you want.
You could stay high level and run on a 3rd party PaaS. There are no shortage of them (Engine Yard, Heroku, etc). You trade a bit of extra money now (and it's really a few bucks per month) for speed. But you pay a cost later when you have to move off. That's OK, as long as it bought you some time to prove your business model, get customers, etc.
You could hire a consultant to build you a PaaS on AWS. (Why? Is it merely to save money? To gain flexibility? How will you know they are competent? How do you know they aren't a one-trick pony building the same solution they built for everybody else, without knowing where it will work and not work?)
You could bite the bullet and hire (or grow) a cloud guy. They learn AWS and iterate. This will give you the most flexibility in the future. You will be prepared to take advantage of cost savings offered by tuning your application to AWS. (A generic PaaS doesn't encourage you do to this, which means you will loose out of performance or cost savings.)
Long term, I think only the last one makes sense. The 3rd party PaaS is also a fine way to gain speed in the short-term. I'm not so keen on a consultant, unless it's to help accelerate knowledge transfer to your company.
For a mostly static website without a lot of stuff going on in the back end, how many page views can the free version of heroku handle (ruby on rails). Can it handle 100 a month, 1,000, 10,000, etc. When shoudl I consider upgrading it and are there better services? Thanks in advance!
Unfortunately, the only real answer to this question is "It depends". It depends on how many database calls you are making, whether or not those database calls are optimized, whether you have any form of caching in place, etc.
However, I am currently in a similar situation as you and just launched an early stage startup on Heroku. I highly recommend installing New Relic (don't worry, there's a free tier) to keep an eye on site usage/statistics.
Another (free!) addon I installed was Papertrail, which allows me to keep a close eye on the Heroku logs, and trigger alerts if there are too many errors (which could mean it's time to scale-up).
On the other side, you can test your Heroku server by sending load to it using the Apache Bend tool. See this answer for a good explanation.
Lastly, I would take a look at this question, which provides many good references on Heroku performance.
Good luck!
Heroku is free for up to 5 apps. Each app has access to 750 dyno-hours per month. That should be more then enough for a mostly static site.
I get about 4k-5k visitors per month on a Ruby app, but with a lot of caching.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I just began switching from spring development to ruby on rails. I wanted to know from those who have used it before, what's the learning curve, if any, on a rails application being deployed for heroku?
Are there any special needs for heroku deployment?
What are the major advantages and disadvantages of heroku?
Thanks in advance :D
Heroku is the easiest possible Rails deployment. It's a fully managed black-box solution for your app with excellent documentation, and they are consistently improving it with an eye to usability. Once you have a working development version of your app, it's a very short hop to being up and running on Heroku. See the Quickstart and Getting Started with Ruby articles for the specifics.
The cost of this ease-of-use is a certain amount of inflexibility. They do a good job of making things open-ended, but a one-size-fits-all approach to hosting architecture inevitably will lead to issues. If you just have a small to medium web app with a standard relational database and common load profile this is not much of a problem. If you need a more custom stack with various additional services (eg. redis, sphinx, rabbitmq, etc) then you'll likely be getting into third-party addons. All of these hosted solutions and Heroku itself charge a premium over the Amazon Web Services that they are built on, which in turn charges a premium over raw hardware / colocation costs of running your own servers. If your site scales very large not only will you be paying a huge premium, but the assumptions that hosted service providers make for the general case will inevitably not fit your particular case as well as a custom-tuned cluster. This is why all truly massive companies like Google, Facebook, Yahoo all run their own data centers, because at that scale having a cadre of dedicated $200k/year systems engineers designing and maintaining your infrastructure pays for itself for many times over simply from the savings of moving away from commodity solutions.
But at small scale, especially during the early rapid iteration of a product, using something like Heroku means you can focus entirely on your application and have a minimum of worry about infrastructure. One exception is if you have a lot of Linux sysadmin chops, then Heroku may not be worth the cost even early, and in that case you might be more comfortable with something like Engine Yard that still provides you with a full Rails stack out of the box, but keeps you closer to the metal.
In any case though, Heroku is a great place to start for a Rails beginner. It's free to get started, and there's no reason you can't do a cost assessment and migrate away later when you have more experience.
The answer by gtd is great, just to add a bit about the problems I have ran into with heroku:
When I started with Ruby on Rails and Heroku about a year ago, the thing that gave me most problems was that by default on my dev machine, Rails used SQLite, and on Heroku the default is postgreSQL.
It usually doesn't give much trouble but certain things such as GROUP BY work differently which led me to lots of frustration when certain things would work on my dev machine and not on Heroku. I would suggest you install a postgreSQL server on your dev machine, for non trivial apps that you are planning to deploy on Heroku.
There are a couple other things that you can't do on Heroku and you can on a VPS, I had problems when working with a payment provider which required me to have a static ip, because Heroku is a cloud service it couldn't be done, and I had to use a proxy to connect with the provider.
Also there are a couple of gems (very few) which you can't install there, and you can't install binaries which some gems depend on, although it's never been a problem for me, bear that in mind.
Other than that couple of gotchas, Heroku is the easiest place to start deploying your apps.
We need CI on Heroku for our RoR app.
We want to use an add-on. I don't mind paying a few bucks to avoid complexity / distraction.
I see its basically Railsonfire vs. Tddium
What are the factors that we should consider in choosing to use one vs. the other?
A similar question was asked at the link below, but it appears that this was before the add-ons above were created.
Proper continuous integration and continuous deployment with Git and Heroku
Another option is CircleCi, which makes it incredibly easy, though it isn't yet in the Heroku add-on marketplace.
I personally believe speed is the major consideration. The speed at which your team moves is tied to how quickly you can get notifications, and a platform optimized for speed is going to make a major difference.
In addition, on slow platforms, tests may fail randomly (for example, Cucumber might fail if a button doesn't appear in 3 seconds, which may not happen soon enough on a slow platform).
I'm a founder of CircleCi, and we make an incredibly fast CI solution (faster than both services you mentioned). It's really easy to set up (one-click), though it's not in the Heroku marketplace (yet).
One consideration I'd give you to… uh… consider is support. I don't know anything about the Tddium team, but I do know that a couple months ago I tried Rails On Fire was blown away by the support. I asked some crazy questions (I do crazy things) and Florian responded in email and on Twitter right away with both help and suggestions.
Then, when I decided not to use the service because it couldn't support one edge-case feature, he implemented the feature! I hadn't been using it for a couple weeks and he wrote back to me personally to say "Hey, we finally got that feature you thought would be helpful."
I've used Hudson/Jenkins for years and know what you mean about complexity. But I also think that having someone on the other end is pretty key, and the RailsOnFire team, for now at least, do that quite well.
I know this is not a really programmic question, but which one should I deploy my app too?
Basically, I will have a straight forward Rails app with a a decent database usage. Heroku is obviously a great platform and has a lot of gimmicks. Duostack however seems to getting bigger and bigger while still in beta, and I really like their autoscaling feature, since I wouldn't have to monitor my site like 24/7 to be as cost efficient as possible.
Secretly, I just hope that Amazon will extend Elastic to Rails, but that would probably take a while
Well you have to get an invite to use Duostack, I don't know how hard that is. Plus, if you're looking to do a production app, they're still in Beta so there's no 100% guarantee things will be stable, or that there won't be API changes.
ALso, is duostack going to offer a free usage tier?
If you're comfortable with the answers to all those questions, then just go for whichever one you like better.
One nice thing about Heroku is it is well-established enough to have a lot of third party integration, and that can make development just blissful if it includes the integrations you need :)
Probably not a wrong choice between the two, though. Request a beta invite and if you get in, try both. Since all you have to do is "git push" to deploy to both, it ought to be pretty easy to do a direct side-by-side comparison of the workflow.