Yeah. In my experience, Heroku starts being a drag at moderate scale:

1. You still have to worry about your systems, as Heroku has its own outages, not to mention the other pieces of your infrastructure like DBs, queues, etc.

2. Architecture flexibility goes way down, as vertical scaling isn't a real option on Heroku (and a surprising number of problems can be easily solved in the short term by just throwing big iron at them).

3. The premium you pay on the hardware you're using starts to add up, especially when you're in the realm of "let's solve this problem in the short term by throwing machines at it."

Of course, that's not to say you can't use a hybrid approach of, say AWS + Heroku to solve some of these, but it's a bigger hurdle to clear if you've outsourced all your systems work to Heroku from the beginning. You suddenly find yourself having to figure this stuff out at some level of scale, vs growing it organically and learning as you go.

Yeah, this is what I'm doing. Using Heroku for their Postgres offering and AWS with convox.io (part of the current ycombinator batch) for deploying web services to AWS.

Hosting is trending towards containers and a Heroku-like approach all over the place, it may not really matter if manually provisioning and maintaining servers stops being popular knowledge.

Pricing can be great if you're using a high-throughput language - I had a sustained 8 - 12k requests per second across 8 dynos years ago with nodejs.

Your question is framed at someone who "learned" deployments via heroku. I will answer it from a different perspective. I recently started at a company who began their staging and production hosting on heroku. I would have a very hard time recommending it to anyone.

In addition to uncompetitive pricing, the "add-on" architecture is itself expensive and inflexible. Redis feels artificially limited, and the scheduler's timing options are, i kid you not: Daily, Hourly, Every 10 minutes.

To people who know linux hosting: avoid heroku. To people who don't know linux hosting: spend some time gaining a serviceable linux hosting skillset.

don't use heroku's scheduler - it's a best effort scheduler that doesn't guarantee it will even execute your jobs at the times you set.

the company i work for runs a rails app and we've ported almost everything over to running with the clock gem instead of with heroku's scheduler.

Any advise on some good tutorials? Heroku makes it easy for me to get going.

The truth is you can pretty much do everything with AWS EBS that you can do with Heroku. I wish I knew about EBS earlier. But I don't thik EBS existed when I first began using Heroku.

It was mainly for throwaway projects. But you never know your throwaway project may start getting traction. And before you realize you may end up owing hundreds of dollars to Heroku.

Do mean Elastic Beanstalk? "EBS" is Elastic Block Storage, that doesn't make sense in this context.

Another thing to note, Elastic Beanstalk auto scales whereas you have to increase/decrease dynos yourself.

In other words, you may be paying for "dyno hours" (wall-clock time) when you don't need to.

Elastic Beanstalk. :)