6 ms·

When you are in a position to pay someone full time to look after the web infrastructure of your project, that's when you should think this stuff through. Befo

When you are in a position to pay someone full time to look after the web infrastructure of your project, that's when you should think this stuff through. Before that, don't worry about the tech, go for what you know, and expect it to need totally re-writing at some point. Let's face it, this stuff moves quickly.

blacktriangle 6y ago
That's the best metric I've heard. When your Heroku bill is the same as what a full time ops person would cost, start looking to hire.
- jacquesm 6y ago
  I would say it has to be at least double that and maybe even higher.
- rualca 6y ago
  If you are already deploying to Heroku, you are already doing ops. It makes zero sense to presume you don't need to know what you're doing or benefit from automating processes just because you can't hire a full-time expert.
  - blacktriangle 6y ago
    True, but there's a difference between solving ops problems by throwing more money at hardware and solving ops problems by thinking smarter. That's why I think that some multiple of an FTE salary is a good metric for when you start transitioning to more complex operational setups, because it gives you a number for when the gain of that new complexity is worth the cost.
Melkman 6y ago
Also, when cost caused by downtime and updates and/or hardware problems exceed the cost of this full time engineer. Even then K8s is probable not the next step. Simple HA with a load balancer and seperate test and production environments plus some automation with an orchestration tool works wonders.
marcosdumay 6y ago
That's not good. That kind of stuff must be derived from your business plan, not from the current situation. You should know that "if I'm successful at this level, I will need this kind of infrastructure" before the problems appear, and not be caught by surprise and react in a hush. (Granted that reacting in a hush will probably happen anyway, but it shouldn't be surprising.) If your business requires enough infrastructure that this kind of tooling is a need at all, it may very well be an important variable on whether you can possibly be profitable or not.
- marcus_holmes 6y ago
  if your business plan has this much detail, you'll spend more time updating it to reflect current reality than actually shipping features. Companies that are growing fast enough to need Kubernetes are also changing fast and learning fast.
- lmm 6y ago
  > You should know that "if I'm successful at this level, I will need this kind of infrastructure" before the problems appear, and not be caught by surprise and react in a hush. (Granted that reacting in a hush will probably happen anyway, but it shouldn't be surprising.) What's the ROI on spending time on planning for that, given that you acknowledge that the response will be mess anyway? In my experience companies that planned for scaling don't handle it noticeably better than companies that didn't plan for it, so maybe it's better not to bother?
  - rualca 6y ago
    > What's the ROI on spending time on planning for that, given that you acknowledge that the response will be mess anyway? Let's put it this way: what's the ROI of failing to address any of the failure modes avoided or mitigated by taking the time to thing things through at design time? Are you planning on getting paid when you can't deliver value because your service is down?
    - lmm 6y ago
marcus_holmes 6y ago
This. When you have enough revenue to hire new dev, and infrastructure is your most pressing problem to solve with that money, hire someone who knows this stuff backwards to solve it.

blacktriangle 6y ago

That's the best metric I've heard. When your Heroku bill is the same as what a full time ops person would cost, start looking to hire.

jacquesm 6y ago
I would say it has to be at least double that and maybe even higher.
rualca 6y ago
If you are already deploying to Heroku, you are already doing ops. It makes zero sense to presume you don't need to know what you're doing or benefit from automating processes just because you can't hire a full-time expert.
- blacktriangle 6y ago
  True, but there's a difference between solving ops problems by throwing more money at hardware and solving ops problems by thinking smarter. That's why I think that some multiple of an FTE salary is a good metric for when you start transitioning to more complex operational setups, because it gives you a number for when the gain of that new complexity is worth the cost.

Melkman 6y ago

Also, when cost caused by downtime and updates and/or hardware problems exceed the cost of this full time engineer. Even then K8s is probable not the next step. Simple HA with a load balancer and seperate test and production environments plus some automation with an orchestration tool works wonders.

marcosdumay 6y ago

That's not good. That kind of stuff must be derived from your business plan, not from the current situation. You should know that "if I'm successful at this level, I will need this kind of infrastructure" before the problems appear, and not be caught by surprise and react in a hush. (Granted that reacting in a hush will probably happen anyway, but it shouldn't be surprising.) If your business requires enough infrastructure that this kind of tooling is a need at all, it may very well be an important variable on whether you can possibly be profitable or not.

marcus_holmes 6y ago
if your business plan has this much detail, you'll spend more time updating it to reflect current reality than actually shipping features. Companies that are growing fast enough to need Kubernetes are also changing fast and learning fast.
lmm 6y ago
> You should know that "if I'm successful at this level, I will need this kind of infrastructure" before the problems appear, and not be caught by surprise and react in a hush. (Granted that reacting in a hush will probably happen anyway, but it shouldn't be surprising.) What's the ROI on spending time on planning for that, given that you acknowledge that the response will be mess anyway? In my experience companies that planned for scaling don't handle it noticeably better than companies that didn't plan for it, so maybe it's better not to bother?
- rualca 6y ago
  > What's the ROI on spending time on planning for that, given that you acknowledge that the response will be mess anyway? Let's put it this way: what's the ROI of failing to address any of the failure modes avoided or mitigated by taking the time to thing things through at design time? Are you planning on getting paid when you can't deliver value because your service is down?
  - lmm 6y ago

marcus_holmes 6y ago

This. When you have enough revenue to hire new dev, and infrastructure is your most pressing problem to solve with that money, hire someone who knows this stuff backwards to solve it.