An OpenStack Crime Story solved by tcpdump, sysdig, and iostat (2014)(blog.codecentric.de)
blog.codecentric.de
An OpenStack Crime Story solved by tcpdump, sysdig, and iostat (2014)
https://blog.codecentric.de/en/2014/09/openstack-crime-story-solved-tcpdump-sysdig-iostat-episode-2/
2 comments
I think that's poignant. The example that comes to mind is SAP: their dev teams embraced both, OpenStack and K8S, culminating in this glorious monstrosity[1] called openstack-helm, by which you could run Kubernetes on bare metal nodes, then deploy OpenStack on top of that, and finally running Kubernetes on those virtual machines again.
The idea being that if your customers need Kubernetes clusters, you should be able to provision them on-demand from elastic resources.
This seems like a great approach, since you can pick a layer to apply redundancy at, and only apply it there. You do not need a triple-redundant control plane built on a redundant backplane, if you are confident in the redundancy of the backplane. I am not a customer of SAP but I am a fan of many complex uses of Helm, and this seemed like it had been very well-considered application of the tool.
Anyway learning about this implementation left me with a slightly dirty feeling that I was idolizing a Rube Goldberg level of complexity system that didn't need to be so complicated.
Then I heard about Gardener[2], which solves the same problem without OpenStack at all. Seed clusters create shoot clusters, with their control planes deployed inside namespaces of the seed cluster. There's no virtualization overhead, and you get all of the same benefits in terms of supervision. Also from SAP. I hope I get to work with something like this.
[1]: https://github.com/sapcc/openstack-helm
[2]: https://gardener.cloud/
The idea being that if your customers need Kubernetes clusters, you should be able to provision them on-demand from elastic resources.
This seems like a great approach, since you can pick a layer to apply redundancy at, and only apply it there. You do not need a triple-redundant control plane built on a redundant backplane, if you are confident in the redundancy of the backplane. I am not a customer of SAP but I am a fan of many complex uses of Helm, and this seemed like it had been very well-considered application of the tool.
Anyway learning about this implementation left me with a slightly dirty feeling that I was idolizing a Rube Goldberg level of complexity system that didn't need to be so complicated.
Then I heard about Gardener[2], which solves the same problem without OpenStack at all. Seed clusters create shoot clusters, with their control planes deployed inside namespaces of the seed cluster. There's no virtualization overhead, and you get all of the same benefits in terms of supervision. Also from SAP. I hope I get to work with something like this.
[1]: https://github.com/sapcc/openstack-helm
[2]: https://gardener.cloud/
Not sure if intentional but that is the second episode. Here is the first episode
https://blog.codecentric.de/en/2014/09/openstack-crime-story...
https://blog.codecentric.de/en/2014/09/openstack-crime-story...
A fairly accurate description of a typical experience of running OpenStack. A behemoth of complexity to manage, requiring an operator to understand a huge amount of layers, ranging from high level concepts like VRRP-based HAproxy setups all the down to kernel network namespaces and low-level tap-devices. All at the same time and with no central control plane to debug but rather crawl multiple log files from multiple systems in parallel.
Back in 2014 OpenStack may have been a thing but nowadays, 4 years later, people learned a lesson. There is no value in being a full-stack operator of infrastructure for systems. The idea of running a complex, distributed architecture like a private cloud at the same or higher stability and comparable or even lower cost than public clouds eventually proved futile.
That's why in 2018, consensus is, infrastructure for systems has been replaced by infrastructure for applications (k8s). The infrastructure is typically consumed on public clouds.