So, I’d been hearing the name Sam McKeown floating around a bunch, especially when folks started yapping about serverless this and serverless that. Figured I should probably see what all the fuss was about, you know, try to keep up.
Diving In, Or So I Thought
I decided to really get my hands dirty. Picked one of his talks, I think it was on observability in serverless setups. Sounded important, right? Gotta know what your stuff is doing, or not doing. My plan was to take a small side project, nothing crazy, and try to implement some of the patterns he was pushing. Seemed like a good way to learn.
I started by trying to set up all this fancy distributed tracing he was going on about. And then the custom metrics for every little thing. My little Lambda functions were supposed to be chirping away, telling me their life stories in real-time. On paper, it was beautiful.
The Reality Slap
Well, let me tell you, it wasn’t exactly a walk in the park. First off, the amount of setup for what I considered a tiny application felt… a lot. I was spending more time configuring monitoring tools and IAM permissions than actually writing the code that did the thing I wanted the app to do. And the cost, man, even the “free tier” stuff started to look like it could bite you if you weren’t careful with all these new services I was plugging in.
I found myself thinking:
- Is all this really necessary for my scale?
- Am I just adding complexity because someone smart said it’s good?
- How much time am I going to spend maintaining this observability stack versus the actual application?
It started to feel like I was building a space shuttle just to go to the grocery store. Sure, the shuttle has amazing telemetry, but maybe a bicycle is fine for a milk run, you know?
Reminded Me Of The Old Days…
This whole experience gave me a serious flashback. I was at this other company a few years back. We had this “genius” architect, a real smooth talker, who convinced management we needed to rebuild our entire monolith into like, a hundred microservices. He had all the buzzwords, all the fancy diagrams. Said it would solve all our problems. We were all drinking the Kool-Aid.
So, we spent a year, maybe more, breaking everything apart. Every team had their own little fiefdom. We ended up with this massive, tangled web of services. If one tiny thing broke, good luck finding out where. It was a blame game half the time. Deployments became these terrifying, all-hands-on-deck affairs. The original problems? Some got solved, sure, but we traded them for a whole new set of, arguably worse, problems. That “genius” architect? He collected his fat paycheck and was gone before the real SHTF.
That whole mess taught me to be real skeptical of anyone selling a silver bullet, no matter how shiny it looks or how smart they sound. You gotta look at your own situation, your own team, your own actual needs. Not just what’s trendy or what some conference speaker is peddling.
So, About Sam McKeown’s Stuff…
Coming back to Sam McKeown and his serverless advice. I don’t think he’s wrong, not at all. For big, complex systems, with huge teams and massive scale, yeah, that level of deep observability is probably a lifesaver. But for my little project? It was overkill. Plain and simple.
I ended up stripping a lot of it back. Went for some basic logging, some simple CloudWatch metrics. Stuff I could set up quick and understand without needing a PhD in observability. And you know what? It works fine for what I need. The project is humming along, and I’m not losing sleep over my monitoring bill or wrestling with complex dashboards.
So, my takeaway? Good ideas are out there, Sam McKeown has plenty of them. But you gotta be the one to filter. You gotta be the one to decide if that fancy tool or technique actually solves a problem you have, or if you’re just adding chrome to a lawnmower. Keep it real, folks.
