At the end of the day, it all comes down to usage patterns. It often makes total sense for low-volume tasks to be processed by Lambda. If your company only has

At the end of the day, it all comes down to usage patterns. It often makes total sense for low-volume tasks to be processed by Lambda. If your company only has low-volume usage, or even just bursty usage, then Lambda is a slam dunk. Now, say your company has a mix of low-volume and high-volume tasks--sure, you could comingle your low-volume work use some of the cycles from the high-volume workloads--e.g. add some endpoints to your high-volume application that handles low-volume tasks. But, isn't this trending towards the monolith of yesteryear? Which, is fine, I guess--monoliths aren't pure evil--but with microservices and serverless we've finally been able to apply the tried-and-true design patterns of separation-of-concerns/do-one-thing-well to entire applications (not just to little utilities and libraries). The point is, there's nothing wrong with embracing the right-tool-for-the-right-job and using a mix of infra strategies is often what's best for an org. You don't have to go all serverless, nor do you have to go all containerized. Let your big-dog 24/7 high-volume applications do their thing in Kubernetes and let your one-off admin tasks spin up for 100ms and die and not bother anyone else.