5 ms·
"Modern" devops (and kubernetes). It seems to me that people want to avoid human error and dependence by replacing human operators with complex networks of doze
by gnuvince 5y ago
"Modern" devops (and kubernetes). It seems to me that people want to avoid human error and dependence by replacing human operators with complex networks of dozen of services, each of which can fail in isolation or in conjunction with others. How do we measure the costs and benefits of putting in all that extra complexity in our stacks, how do we ensure that the friction they cause will not be a greater detriment than the previous situation they aim to improve? Are we in a situation where the solutions to existing problems have so many problems themselves that they need solutions of their own, thus creating an infinite tower of ever more complex software?
- vladfr 5y agoThe crux of the issue is scaling. Devops is, for the most part, automation. You could never run 500 nodes across 10 geos and 2 clouds by hand. What works for 100 http reqs/s cannot work for 100k. Kubernetes is a different beast. Most people think of it as a cluster manager: instead of managing your own nodes, then running scripts or automation on them, you write a bunch of yaml and K8s deploys and runs it. While that is fine and true, that's not why Kubernetes was built. Instead, k8s is a platform for building platforms. You don't run your microservices on it, you run your clouds on it, which in turn run your stuff. At this level, you can see why you need the comical amount of complexity.
- seanw444 5y agoThis is it for me as well. The best way I can describe it is "bloat."
- plooooooop 5y agoThe best success measurement is described in Google’s SRE book: you’re doing it right when you can scale the number of services/features/products/customers you support faster than the size of your ops/devops/sre team.