3 ms·

So at a cost of $18k per month you are getting 30M pages served, 140M API calls, 2.2M background jobs and 143TB of bandwidth. That sounds like a lot of bang for

So at a cost of $18k per month you are getting 30M pages served, 140M API calls, 2.2M background jobs and 143TB of bandwidth. That sounds like a lot of bang for your buck. When deciding on making any changes you have to consider the cost/benefit. Say an engineer costs you $10k for a month (fully loaded cost). For them to spend a month on reducing costs then what kind of reduction makes it worthwhile? For me, I would want it to take a year or less to pay back. So for me, a developer would need to reduce the monthly bill by $1k in order to justify the effort of a month of their time. Maybe they have ideas to easily do that, or maybe not. Over time, as the bill keeps rising, you eventually reach a point where the savings become greater than the developer cost and so you go ahead and do it. So just work out your numbers (engineer cost, minimum payback period) and the decision becomes easy.

lukechesser 11y ago
Bang on right. That's exactly how we're looking at it. One thing we also consider as well is the overhead of adding another person to our team. We're learning a lot as we go (we've never built anything like this), so we have to be very careful that each teammate we bring on is aligned on vision, has the tools and resources they need to be successful and make smart autonomous decisions, and can fit into the current team without disrupting too much of the other teammates. That means that we can't just double our team size overnight and stick two new people on optimizations and cost reduction, even if it financially and procedurally made sense.
- ZenoArrow 11y ago
  It makes sense to weigh up your options. I'll propose one you may want to consider. By hosting on Heroku (or any other cloud hosting provider) you're saving on devops, but you're also paying over the odds for your hosting. However, if you had an option that retained most of the devops simplicity of Heroku, but also cut costs, evaluating this would make sense. I would suggest that this option exists, and that option is application containers (Docker, etc...). If you can build your infrastructure around application containers, not only do you have the option of using dedicated hosting when you have access to the processing capacity to do so (and thereby save money), but you also have option to scale into the cloud if/when the local capacity is exceeded. A number of the cloud hosts support Docker, including but not limited to OpenShift: https://blog.openshift.com/openshift-v3-platform-combines-docker-kubernetes-atomic-and-more/ https://blog.openshift.com/openshift-v3-platform-combines-do... Furthermore, it's a change you can make gradually. Developers can start using application containers as development environments, and you can roll them out more broadly once the implementation issues have been ironed out. Does this sound like something you would consider? EDIT: Worth noting that Heroku also supports deploying using Docker containers: https://devcenter.heroku.com/articles/docker https://devcenter.heroku.com/articles/docker

lukechesser 11y ago

Bang on right. That's exactly how we're looking at it. One thing we also consider as well is the overhead of adding another person to our team. We're learning a lot as we go (we've never built anything like this), so we have to be very careful that each teammate we bring on is aligned on vision, has the tools and resources they need to be successful and make smart autonomous decisions, and can fit into the current team without disrupting too much of the other teammates. That means that we can't just double our team size overnight and stick two new people on optimizations and cost reduction, even if it financially and procedurally made sense.

ZenoArrow 11y ago
It makes sense to weigh up your options. I'll propose one you may want to consider. By hosting on Heroku (or any other cloud hosting provider) you're saving on devops, but you're also paying over the odds for your hosting. However, if you had an option that retained most of the devops simplicity of Heroku, but also cut costs, evaluating this would make sense. I would suggest that this option exists, and that option is application containers (Docker, etc...). If you can build your infrastructure around application containers, not only do you have the option of using dedicated hosting when you have access to the processing capacity to do so (and thereby save money), but you also have option to scale into the cloud if/when the local capacity is exceeded. A number of the cloud hosts support Docker, including but not limited to OpenShift: https://blog.openshift.com/openshift-v3-platform-combines-docker-kubernetes-atomic-and-more/ https://blog.openshift.com/openshift-v3-platform-combines-do... Furthermore, it's a change you can make gradually. Developers can start using application containers as development environments, and you can roll them out more broadly once the implementation issues have been ironed out. Does this sound like something you would consider? EDIT: Worth noting that Heroku also supports deploying using Docker containers: https://devcenter.heroku.com/articles/docker https://devcenter.heroku.com/articles/docker