4 ms·
I don't know what to tell you except that with years of experience implementing this infrastructure outside Kubernetes, letting Kubernetes handle it is cheaper.
by anchochilis 6y ago
I don't know what to tell you except that with years of experience implementing this infrastructure outside Kubernetes, letting Kubernetes handle it is cheaper. That doesn't mean Kubernetes is a good fit for every organization or workload.
You can roll your own anything with enough time and manpower. Whether it makes sense to do so depends on your circumstances.
- zug_zug 6y agoWell for example, I'm a lead devops on a team of 2-3. We have 6 core services. For the last several years, due to static load we've been fine with 2 instances per service. Now that we want autoscale (even though all the real load is really just the DB), it seems we could get ourselves onto AWS autoscale in ~1 month, though it would require some coding. Spending 3 devops on 1 year doing something is a red-flag to me. If your changes save devs 1 hour per deploy, it'll pay off 6,000 deploys from now.
- anchochilis 6y agoIt's not the only thing we've been doing, just the most important. I think it's great you guys have 2.5 dedicated people operating 6 services across 12 prod instances, with that kind of ratio our team would be 15 people!
- justin_oaks 6y agoI agree with your point overall, I just want to add that some DevOps efforts aren't to save DevOps time, but to prevent errors. When you make a change manually, there's a chance that you forget something, have a typo, etc. Those problems disappear when those same things are automated.