3 ms·

I agree with everything you said, except that I don't think you need to spend any time working on an exit plan until the day you realize you're paying "too much

by aculver 14y ago

I agree with everything you said, except that I don't think you need to spend any time working on an exit plan until the day you realize you're paying "too much" (whatever that means to you) for the benefit you're receiving from their managed hosting. I recommend: Launch on Heroku. Reevaluate that choice on success.

Estragon 14y ago
Surely designing with the eventual migration in mind will reduce the pain in the end, though.
- WALoeIII 14y ago
  YAGNI - your first problem is getting customers.
  - taligent 14y ago
    But your customers aren't going to be happy if your site is slow whilst your bleeding money. Heroku/EC2 are fantastic for what they are but quite pricy.
  - Estragon 14y ago
    Absolutely agree that that is the first priority, but there are many factors you can keep in mind during development without slowing it down much, and this is one of them.
- taligent 14y ago
  I am actually going through this right now as we saw our EC2 instances start doing 2-10 second response times under little load. So currently migrating to a dedicated server. What is is found an interesting product called VCider which allows you to create mini private clouds. This might be something to look into using from day one to help with eventual migration. It is free up to 8 servers.
  - sciurus 14y ago
    vCider is mostly a cleverly marketed VPN. It could be useful when you have servers mixed across different IaaS providers or IaaS and your own physical infrastructure. I don't see how it solves much of the problem of migrating off an IaaS or PaaS provider. http://www.vcider.com/vpc-overview http://www.vcider.com/vpc-overview
- easp 14y ago
  You know the best way to do that? Keep it simple. I think the people who are most likely to worry up front about a plan for migrating off of Heroku has a great deal of overlap with the sort of people who will make migrating off Heroku difficult for themselves by depending on too many "exotic" add-ins.
- aculver 14y ago
  I'm not sure, actually. Running an application on such specialized application servers as Heroku provides has the benefit of being highly scalable, but it also means you have to adhere to some architectural patterns, which I believe address a lot of the migration issues people would normally encounter. The most obvious example (and probably most relevant) is that on Heroku you can't store permanent files locally. Instead you need to store them on something like Amazon S3. However, the application servers also aren't a great place to do things like video processing. Instead, you'd lean on a third-party service like Zencoder. As a result, applications that run well on Heroku have very few environmental dependancies and migration should be relatively straight forward. They even make it brilliantly easy to dump your database to a file that can be imported elsewhere. I think the real pain in migrating from Heroku is outside of the application itself. I think the real pain is duplicating all the infrastructure and staffing you never had to think about when you deployed your app in the beginning. Honestly, I don't even know all the details of what they do. But I know I've never set it up myself and I'm not really interested in doing it. I don't want to hire someone to do it, either. It's enough being on call for application issues, never mind all the rest. In every venture I'm involved in, traffic and users translate directly into money, so paying Heroku a cut of that success is not a problem. They've earned it.
easp 14y ago
I agree. Think about what "too much" Heroku spend is. Think about what level of adoption/success it will take to reach that much Heroku spend. Then consider if you actually get to that level of adoption, are your Heroku costs really going to be "too much?" Don't spend more than 90 minutes on the whole exercise. My guess is that, for most apps, worrying before launch about migrating off of Heroku is a premature optimization.

by aculver 14y ago

Estragon 14y ago

Surely designing with the eventual migration in mind will reduce the pain in the end, though.

WALoeIII 14y ago
YAGNI - your first problem is getting customers.
- taligent 14y ago
  But your customers aren't going to be happy if your site is slow whilst your bleeding money. Heroku/EC2 are fantastic for what they are but quite pricy.
- Estragon 14y ago
  Absolutely agree that that is the first priority, but there are many factors you can keep in mind during development without slowing it down much, and this is one of them.
taligent 14y ago
I am actually going through this right now as we saw our EC2 instances start doing 2-10 second response times under little load. So currently migrating to a dedicated server. What is is found an interesting product called VCider which allows you to create mini private clouds. This might be something to look into using from day one to help with eventual migration. It is free up to 8 servers.
- sciurus 14y ago
  vCider is mostly a cleverly marketed VPN. It could be useful when you have servers mixed across different IaaS providers or IaaS and your own physical infrastructure. I don't see how it solves much of the problem of migrating off an IaaS or PaaS provider. http://www.vcider.com/vpc-overview http://www.vcider.com/vpc-overview
easp 14y ago
You know the best way to do that? Keep it simple. I think the people who are most likely to worry up front about a plan for migrating off of Heroku has a great deal of overlap with the sort of people who will make migrating off Heroku difficult for themselves by depending on too many "exotic" add-ins.
aculver 14y ago
I'm not sure, actually. Running an application on such specialized application servers as Heroku provides has the benefit of being highly scalable, but it also means you have to adhere to some architectural patterns, which I believe address a lot of the migration issues people would normally encounter. The most obvious example (and probably most relevant) is that on Heroku you can't store permanent files locally. Instead you need to store them on something like Amazon S3. However, the application servers also aren't a great place to do things like video processing. Instead, you'd lean on a third-party service like Zencoder. As a result, applications that run well on Heroku have very few environmental dependancies and migration should be relatively straight forward. They even make it brilliantly easy to dump your database to a file that can be imported elsewhere. I think the real pain in migrating from Heroku is outside of the application itself. I think the real pain is duplicating all the infrastructure and staffing you never had to think about when you deployed your app in the beginning. Honestly, I don't even know all the details of what they do. But I know I've never set it up myself and I'm not really interested in doing it. I don't want to hire someone to do it, either. It's enough being on call for application issues, never mind all the rest. In every venture I'm involved in, traffic and users translate directly into money, so paying Heroku a cut of that success is not a problem. They've earned it.

easp 14y ago

I agree. Think about what "too much" Heroku spend is. Think about what level of adoption/success it will take to reach that much Heroku spend. Then consider if you actually get to that level of adoption, are your Heroku costs really going to be "too much?" Don't spend more than 90 minutes on the whole exercise. My guess is that, for most apps, worrying before launch about migrating off of Heroku is a premature optimization.