Oscar Borrallo:

1. The point of “phoenix-ing” (or burning it to the ground and starting from scratch) a project from time to time is to give yourself a clean slate to start from. Otherwise you left cruft like leftover code, bad design ideas, etc. creep into the codebase and its too easy to end up with an unwieldy mess. Rebuilding a project isn’t abstraction work, either, its a necessary part of the application lifecycle.
2. K8S was designed by engineers at Google to solve Google-scale problems. Having worked with it professionally, and having used other container schedulers, I can say that while K8S solves a lot of problems and offers a really flexible solution it also brings a lot of operational and development overhead with it. In my mind its similar to Openstack in that its great if you have a dedicated team working on and supporting it. That’s why in my opinion if you’re going to run K8S in your organization there needs to be a paradigm shift in how its architected. The tendency is to think of the K8S cluster as a parallel for a division or a group of teams, with namespaces separating those teams out, but because of the scale that K8S was designed to run at, you should broaden that scope. I’m all in favor of running a single cluster for an entire company. Not only can it actually handle that scale but you minimize the overall amount of operational work needed if you’re running a single cluster versus a number of them. For smaller-scoped architectures I would highly recommend something like Hashicorp’s Nomad instead of K8S for its stability and ease of use. So when you take all of this in mind its easy to see how it doesn’t make sense to run K8S for a few hundred container or even IoT — its like taking a bath in an Olympic-sized swimming pool; sure, you can do it, but it makes a lot more sense to just use a bathtub.