Live data from Hacker News

A simple DIY Heroku replacement to keep your hosting costs down

github.com

21–30 of 76 posts

Re: A simple DIY Heroku replacement to keep your hosting costs down

#21

Earlier quoted context omitted.

There's minikube, but so far as I'm aware, it's not really meant for production use; it exists mostly for local development. My own company has Pivotal Web Services[0], which gives a Heroku-like experience using Cloud Foundry. Pricing is per-megabyte[1], plus services. I expect we'll introduce a container service before long, because we like to dogfood our stuff with real production workloads. [0] http://run.pivotal.…

Yeah, minikube is just for trying K8s out. PWS looks interesting, but, as with other managed/cloud offerings, it's much more expensive than a dedicated server (50ish EUR/mo for a 64 GB RAM i7). For my side-projects, where I am cost-sensitive, I think the best solution would be a dedicated server with something like Dokku. It would just be nice if the "something" could be an industry standard.

I think it's hard to split the difference. If there was a service using RackHD to spit out cheap bare metal it'd be more doable to run on top of that, I think.

Re: A simple DIY Heroku replacement to keep your hosting costs down

#23

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…

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.

Re: A simple DIY Heroku replacement to keep your hosting costs down

#24

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…

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

Re: A simple DIY Heroku replacement to keep your hosting costs down

#25
post #4

Earlier quoted context omitted.

The great thing about CaptainDuckDuck is that it expressly aims to address your argument. I haven't used it myself, but from reading his blog post (linked below), his goal is to build something 75% cheaper, but just as easy-to-use. > My goal was to enable a typical web app developer create a Heroku-like server instance in less than 10 minutes. I am happy to say, I did it!

I think I worked out what my actual problem is here: pride. I work on a platform partly inspired by Heroku and which consequently deals with many of the same problems. I am intimately aware of how much work has been required to build that platform and expand its capabilities. It is hard to read someone saying they have replaced Heroku and not feel annoyance, because it downplays the enormous amount of careful enginee…

Also, infrastructure and support.

Re: A simple DIY Heroku replacement to keep your hosting costs down

#26

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…

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 y…

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.

Re: A simple DIY Heroku replacement to keep your hosting costs down

#27

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…

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 y…

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.

Re: A simple DIY Heroku replacement to keep your hosting costs down

#29

Earlier quoted context omitted.

You might look at Red Hat's OpenShift, which builds on top of Kubernetes. Or Deis, which has adopted buildpacks. Cloud Foundry has buildpacks too, but it's usually seen as a heavyweight solution -- the light footprint variant is 6 VMs, the standard variant is 20-something. Disclosure: I work for Pivotal, we contribute a lot to Cloud Foundry. Red Hat is a competitor.

Ah, I've heard about Deis, I'll check that one out, thanks. My main concern is the fact that Kubernetes recommends running more than one server, which is a luxury my personal projects cannot afford. Does anyone know how well it runs on a single server?

It is possible to run Kubernetes on a single machine combining master and worker nodes but there are few instructions for it. Really only makes sense for single bare metal machine. For production, better to run separate VMs. The hosted Kubernetes, GKE and Azure, can run clusters without paying for master nodes and can have pretty small nodes.

Re: A simple DIY Heroku replacement to keep your hosting costs down

#30

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…

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 y…

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.

Post reply on HN