Re: re: how do you even begin to debug that when something goes wrong
Logging is only as good as you make it. No free lunch regardless of where the app is running. If logs are spread out, now you have to now have an aggregator to correlate all that. Just one more dependency.
You make serverless sound so easy. But when you build something totally serverless and have 70+ functions your deploying, in practice it just doesn't work. I've seen it. Eventually they just switched to a simple monolithic app that was super easy to monitor and debug and hosted it in a container (or something with pretty low maintenance). Isn't the cheapest option, but it was the easiest to reason about and maintain. Right tool for the right job which was the right fit for the size of team maintaining it. AWS, for example, provides XRay as a poor man's Dynatrace, but it is woefully inadequate. Just "looking at logs" is the old way, there has to be ways to easily trace entire business transactions through all dependencies and serverless makes that hard right now because unless you have something in your code that can plugin into the runtime, it's really hard to monitor. We pay for Dynatrace and run the OneAgent on K8s and anything else that is not serverless. It figures out our dependencies and tells us exactly where the issues are. You can't get that with serverless. I get the serverless concept and why it is cool, but I don't get how a spaghetti bowl diagram of 20+ interwoven AWS services (all "serverless") is better than a much simpler maybe more monolithic design. I'm for microservices as much as the next person, but microservices being good doesn't make monoliths bad or less maintainable. Nor does serverless solve all the things.
Biting the hand that feeds IT
