4 ms·

This, Dokku, Flynn, that 1000+ line bash/chef/ansible script that the guy who used to do your job before he left are all legitimate solutions for deploying apps

This, Dokku, Flynn, that 1000+ line bash/chef/ansible script that the guy who used to do your job before he left are all legitimate solutions for deploying apps (and all better than FTP'ing up whatever the developer happens to have on their laptop). But, I feel like the comparison to Heroku isn't great. Heroku saves you from having to do and worry about significant amounts of (I would argue) extremely important admin and security work. How are datastore backups handled in this scenario? How do you handle updating redundancy? Can you in a couple clicks add a secure Postgres, MongoDB, Memcached or Redis server to your app? Setup CI? Or even just secure these things properly. This stuff gets complex and it's extremely easy to accidently set up something that's much more open to the world than you would want. To sum up: Heroku -> A way for developers to put up much more robust sites than they could otherwise. Scripted Setups -> a (very positive and cool thing) for those with devops/sysadmin skills to more rapidly setup a site. Full disclosure: I do a lot of work in the Heroku ecosystem and could well be defending the platform out of greed. But, I've also seen first hand some of the wild misconceptions and mistakes that were caught by the built in systems and limits to the platform.

timewarrior 9y ago
While I agree that a script can't match what Heroku does, in the end Heroku shouldn't be used for anything serious. I love Heroku for it's simplicity. They give you very few levers, making it less likely for you to screw up. When we had a production add we faced following issues with Heroku: 1. Frequent downtimes. Heroku would have a 3-4 hour downtime every 2 months. In some cases, site would be down. In most cases you couldn't deploy and add machines. 2. There is an end user impact in terms of performance. After moving to Elastic Beanstalk, we had a 20% decrease in response time and 5% increase in revenue. 3. In the end Heroku is very simplistic. They don't have features like rolling deployment or Blue-green deployment. They had some beta version of rolling deployment, however that was buggy and caused version issues with deployment. With Elastic Beanstalk we have a health check based rolling deploy, which has caught production issues many times. 4. To do custom things, you need to deal with buildpacks etc, which is not very convenient. 5. Thought it wasn't an issue for us, Heroku can be expensive. Our server costs went down 80% while giving better performance. So, in summary - Heroku is great to get you started quickly. However if you are doing anything serious but do not want to get deep into DevOps, consider something like Elastic Beanstalk. Eventually we managed our environments using CloudFormation. That allows us to create repeatable Elastic Beanstalk instances. Once we got the CloudFormation template right, it was easier to maintain Elastic Beanstalk vs Heroku.
- malyk 9y ago
  Just for the other perspective... 1.) I’ve been running production apps on Heroku for 7 years and we’ve had about 3-4 hours of downtime total in that time with the exception of the major AWS outage a few years ago that was a full day. Maybe US-East is more robust than other regions? 2. It’s true. Request queuing specifically can be a killer. 3.) Heroku has had rolling deployments for a long time. 5 or 6 years at least. It was a beta feature for a lon time, but has worked perfectly since the day they opened the beta for my apps. 4.) sure, but there are a ton of build packs out there and even if they aren’t a little scripting makes everything pretty straightforward. Especially compared to scripting everything yourself. 5.) definitely true. But, if you have a team less experience or less interested in devops it can be a great platform to trade salary for ease.
- acjohnson55 9y ago
  My company hosts a whole bunch of critical software on Heroku. It generally works fantastic. We do use relatively less "batteries infra for some of our services, and we'll probably shift further in that direction, but I think you're underselling just how effective Heroku is. It goes a long way towards letting your team worry more about the business domain and less about the infrastructure concerns that aren't at all unique.
- michaelbuckbee 9y ago
  I think we're agreeing more than disagreeing here. But I think you're not properly valuing yourself in this scenario. People that can utilize AWS and navigate through all the services, use CloudFormation, etc. are in a high demand and at some level in the cost analysis you need to factor that in.
  - timewarrior 9y ago
    In terms of my time, it has been very valuable. I had to spend quite some time working around Heroku's limitations. We have had 100% uptime (based on external monitoring) since we moved to Elastic Beanstalk. Health check based rolling deploys are awesome. Caught production bugs 3-4 times. I agree that it was easier for me to do, because I have extensive DevOps experience. However if someone is getting to anything more than a hobby project, consider investing in someone to build a basic CloudFormation script for ElasticBeanstalk. I will open source ours in a couple of months (things really hectic right now).
tedmiston 9y ago
It's that whole "as a Service" part people tend to forget when making overly generous analogies.
icebraining 9y ago
OTOH, the Heroku people aren't personally managing each instance you create; their work is writing the automation code that turns AWS VMs into these more manageable, higher-level pods. Maybe Dokku and Flynn aren't there yet, but conceptually, is there a real difference between the two? I don't see it.

timewarrior 9y ago

While I agree that a script can't match what Heroku does, in the end Heroku shouldn't be used for anything serious. I love Heroku for it's simplicity. They give you very few levers, making it less likely for you to screw up. When we had a production add we faced following issues with Heroku: 1. Frequent downtimes. Heroku would have a 3-4 hour downtime every 2 months. In some cases, site would be down. In most cases you couldn't deploy and add machines. 2. There is an end user impact in terms of performance. After moving to Elastic Beanstalk, we had a 20% decrease in response time and 5% increase in revenue. 3. In the end Heroku is very simplistic. They don't have features like rolling deployment or Blue-green deployment. They had some beta version of rolling deployment, however that was buggy and caused version issues with deployment. With Elastic Beanstalk we have a health check based rolling deploy, which has caught production issues many times. 4. To do custom things, you need to deal with buildpacks etc, which is not very convenient. 5. Thought it wasn't an issue for us, Heroku can be expensive. Our server costs went down 80% while giving better performance. So, in summary - Heroku is great to get you started quickly. However if you are doing anything serious but do not want to get deep into DevOps, consider something like Elastic Beanstalk. Eventually we managed our environments using CloudFormation. That allows us to create repeatable Elastic Beanstalk instances. Once we got the CloudFormation template right, it was easier to maintain Elastic Beanstalk vs Heroku.

malyk 9y ago
Just for the other perspective... 1.) I’ve been running production apps on Heroku for 7 years and we’ve had about 3-4 hours of downtime total in that time with the exception of the major AWS outage a few years ago that was a full day. Maybe US-East is more robust than other regions? 2. It’s true. Request queuing specifically can be a killer. 3.) Heroku has had rolling deployments for a long time. 5 or 6 years at least. It was a beta feature for a lon time, but has worked perfectly since the day they opened the beta for my apps. 4.) sure, but there are a ton of build packs out there and even if they aren’t a little scripting makes everything pretty straightforward. Especially compared to scripting everything yourself. 5.) definitely true. But, if you have a team less experience or less interested in devops it can be a great platform to trade salary for ease.
acjohnson55 9y ago
My company hosts a whole bunch of critical software on Heroku. It generally works fantastic. We do use relatively less "batteries infra for some of our services, and we'll probably shift further in that direction, but I think you're underselling just how effective Heroku is. It goes a long way towards letting your team worry more about the business domain and less about the infrastructure concerns that aren't at all unique.
michaelbuckbee 9y ago
I think we're agreeing more than disagreeing here. But I think you're not properly valuing yourself in this scenario. People that can utilize AWS and navigate through all the services, use CloudFormation, etc. are in a high demand and at some level in the cost analysis you need to factor that in.
- timewarrior 9y ago
  In terms of my time, it has been very valuable. I had to spend quite some time working around Heroku's limitations. We have had 100% uptime (based on external monitoring) since we moved to Elastic Beanstalk. Health check based rolling deploys are awesome. Caught production bugs 3-4 times. I agree that it was easier for me to do, because I have extensive DevOps experience. However if someone is getting to anything more than a hobby project, consider investing in someone to build a basic CloudFormation script for ElasticBeanstalk. I will open source ours in a couple of months (things really hectic right now).

tedmiston 9y ago

It's that whole "as a Service" part people tend to forget when making overly generous analogies.

icebraining 9y ago

OTOH, the Heroku people aren't personally managing each instance you create; their work is writing the automation code that turns AWS VMs into these more manageable, higher-level pods. Maybe Dokku and Flynn aren't there yet, but conceptually, is there a real difference between the two? I don't see it.