Only certain kinds of application would deploy painlessly.
Only certain kinds of application would deploy painlessly. I suspect the kinds of application that would deploy painlessly would have another design/architecture that doesn't assume k8 is in the foreground, and that design would be able to simplify itself even further.
Thus the authors point about the "tax".
K8 forced a certain (high) level of operational overhead, additional security gymnastics, log collection, specialty tools to deal with tracing and secret vaulting, special sauce to deal with data/mounts and stateful across crash fault lines.
Sometimes, after you peel away the layers, it comes down to the core developer still want to write applications "the old way", with packages, libraries and dependencies that "look like client server".
Truly "cloud freedom to dream" solutions are thus hidden if we have to translate everything back to client/server, code-packages-os paradigm. It's like trying to be cloud modern, but without really doing it, abstracting every thing back to what a kernel understands.
On the absolute opposite of k8s, are event based customizations for a series of AWS data-exchange, s3, sns, step functions; or the no code platforms that customize business tables and logic; or the Azure functions you add to SharePoint or office workflows. None of these examples, warts or not, demands the reduction of application back into "code-packages-os", but instead forces a different way to think about solutions.
That's what cloud should be.