Asking from a business perspective - I of course intend to keep developing this, but am also really trying to think through the business case as well.
Asking from a business perspective - I of course intend to keep developing this, but am also really trying to think through the business case as well.
The answer depends on funding, i.e. in my own never-leaves-my-house case it is always self-host, much like SOC work.
In the case of startup or research lab work (day-job, for lack of a better descriptor). It's frequently a slice of AWS, GCP, or Azure, i.e. 6 figure/mo cloud bills.
I think those two broad cases are worth considering.
If you look at the history from J2EE to the k8s prototype in Java to what we have now, it's a great idea to encapsulate all of these things into a single container, particularly at Google scale, but many unintended consequences arise from complexity accruing to features and functions which weren't actually requirements for your particular project being supported, i.e. the notion that YAGNI because few orgs have Google scale problems. If so, great! Carry on... If not, consider k3s or aptible or more emergent platforms I haven't actually used.
The mere presence of unneeded items in source and documentation presents a "why am I here?" choice paradox. That's before we even get into keeping track of deprecations in the never-at-rest source/release evolution.
Federation is a good example. I've worked at places that needed it and places that didn't.