If you're maintaining an app and a db, yeah, there may not be a ton of advantage. Your bespoke artisinal admin-ing directly by the teams writing the code is pro

If you're maintaining an app and a db, yeah, there may not be a ton of advantage. Your bespoke artisinal admin-ing directly by the teams writing the code is probably fine. And hopefully it will be somewhat understandable in 3 years when there's no one left from that era & folks have to go repair/extend/improve their inheritance. If you are an org with multiple services & apps, with multiple teams, a container is a very compelling encapsulation, of a lot of aggregated build/deploy/manage complexity, with very little overhead, and some decently good isolation benefits. Likewise if you just have a dozen boxes and are ok hand managing what resources are allocated to what systems, you might not need any orchestration. You can just do whatever. But again, over time, you may come to want something that can handle a wider range of apps & services well. You may benefit from the autonomic behavior, rather than having to be as on call & juggling allocations yourself. As your teams grow, having RBAC may be smart or necessary. Having logical namespaces can be useful. Being able to plug in various container storage capabilities, for remote storage, might be a boon for some. There's a suite of potential nice to haves, that you might keep being able to replicate if you tried. The view that it's all easy & all this stuff is unnecessary is alluring. It is a little extra comedic to see the viewpoint being raised from the house of Rails though. Rails was the original batteries included/omakase "the rails way" well built out path (and that still ended up pretty sprawling, especially widening out as the un-JS-ness diminished). Kubernetes is & isnt as everything baked in- on the one hand, there's a sea of storage & networking plugins, and oodles of operators one can add to extend their cloud. But on the positive hand, there is one consistent way to manage & run everything, via api-server & letting control-loops kick in, there is a standard set of primitives, that manage standard, modular, interoperable containers. It's a way, and it's common, and while one can get fancy it mostly works fine out of the box with k3s for example & isnt ostentatious about it. It's a reasonable way to tackle complexity that is real & exists, for legitemate reasons, and having The Kubernetes Way is a huge leap over what we had before, which was next to mo consistency between shops for how to do anything, a mix & match of various small parts that were never designed to work together at all.