4 ms·

And how much developer time did it cost? We have done the same - our bills went down, but not by as much as 80% I think closer to 50%. But it took a fair bit o

by collyw 7y ago

And how much developer time did it cost? We have done the same - our bills went down, but not by as much as 80% I think closer to 50%. But it took a fair bit of developer time, and we now have a lot of Kubernetes related problems to deal with. I guess those will smooth out over time, but I don't think anyone ever factors in this stuff when they claim great savings. Developer time ain't cheap. On a plus note, running multiple small boxes via Kubernetes does give you a more high availability system. If one instance goes down, there will still be another one available, so it's not all negative.

satanspastaroll 7y ago
I think most people over-estimate the need for availability anyway. It's tempting to build the very best you can, when in reality a business really needs a good-enough solution. A whole ton of software can be down every weekend if needed. A great in-between is to simply have a backup server ready to go in a few minutes time. Super simple compared to orchestrated container system. Of course for client projects that spec out a certain number of 9's must be done just so, but can also be billed accordingly.
merb 7y ago
what were the challenges or what challenges do you have? currently my company runs on GKE and auto scheduling, even from "spot" instances (called preemptible on gke) is a breeze. we basically only run jobs on the spot instances that don't need to run instantenious, so it's really cheap for us.
- collyw 7y ago
  Large uploads and downloads filling up memory and crashing pods. When we had one large machine it didn't have this problem.
ramraj07 7y ago
Goes back to the fact that stack overflow itself runs on a single beefed up machine for all their traffic (with a backup machine of course). What this company does that needs so many instances? And they use the same tech too (.NET). Instead of thinking about that people always think about over engineering for "scale" to overcompensate bad code.
- collyw 7y ago
  Do you have any idea how big their actual database is? And how many clients thay serve? It does seem to be an example of a "standard" architecture done well. Our application has a tiny fraction of the traffic and it struggles with some things.
  - manigandham 7y ago
    It's all public: https://stackexchange.com/performance https://stackexchange.com/performance Here's a series of blog posts with a lot more detail by one of their devs: https://nickcraver.com/blog/archive/ https://nickcraver.com/blog/archive/ They're very optimized and can serve all of their traffic on a single webserver, redis instance and SQL server.
  - ramraj07 7y ago
    Being a compiled program vs something in python or Ruby probably makes the majority of the difference!
jve 7y ago
> And how much developer time did it cost? The nice side effect is they did migrate to .NET Core And as another commenter said, another side effect was they got fault tolerant infrastructure. So not every minute they spent on migrating to "spot" instances is dedicated to that.
cbushko 7y ago
When that developer leaves you will still be saving 50%. It should pay for itself over the long haul.

by collyw 7y ago

satanspastaroll 7y ago

I think most people over-estimate the need for availability anyway. It's tempting to build the very best you can, when in reality a business really needs a good-enough solution. A whole ton of software can be down every weekend if needed. A great in-between is to simply have a backup server ready to go in a few minutes time. Super simple compared to orchestrated container system. Of course for client projects that spec out a certain number of 9's must be done just so, but can also be billed accordingly.

merb 7y ago

what were the challenges or what challenges do you have? currently my company runs on GKE and auto scheduling, even from "spot" instances (called preemptible on gke) is a breeze. we basically only run jobs on the spot instances that don't need to run instantenious, so it's really cheap for us.

collyw 7y ago
Large uploads and downloads filling up memory and crashing pods. When we had one large machine it didn't have this problem.

ramraj07 7y ago

Goes back to the fact that stack overflow itself runs on a single beefed up machine for all their traffic (with a backup machine of course). What this company does that needs so many instances? And they use the same tech too (.NET). Instead of thinking about that people always think about over engineering for "scale" to overcompensate bad code.

collyw 7y ago
Do you have any idea how big their actual database is? And how many clients thay serve? It does seem to be an example of a "standard" architecture done well. Our application has a tiny fraction of the traffic and it struggles with some things.
- manigandham 7y ago
  It's all public: https://stackexchange.com/performance https://stackexchange.com/performance Here's a series of blog posts with a lot more detail by one of their devs: https://nickcraver.com/blog/archive/ https://nickcraver.com/blog/archive/ They're very optimized and can serve all of their traffic on a single webserver, redis instance and SQL server.
- ramraj07 7y ago
  Being a compiled program vs something in python or Ruby probably makes the majority of the difference!

jve 7y ago

> And how much developer time did it cost? The nice side effect is they did migrate to .NET Core And as another commenter said, another side effect was they got fault tolerant infrastructure. So not every minute they spent on migrating to "spot" instances is dedicated to that.

cbushko 7y ago

When that developer leaves you will still be saving 50%. It should pay for itself over the long haul.