queerlilhayseed

Requests per second getting higher, and higher, then they level out – but the server is just barely hanging in there, frantically serving as many requests as it possibly can, and then all at once they come crashing down into warm, gentle waves of relaxing human pings.

A poor architect blames their tools. Serverless is an option among many, and it’s good for occasional atomic workloads. And, like many hot new things, it’s built with huge customers in mind and sold to everyone else who wants to be the next huge customer. It’s the architect’s job to determine whether functions are fit for their purposes. Also,

Here’s the fundamental problem with serverless: it forces you into a request-response model that most real applications outgrew years ago.

IDK what they consider a “real” application but plenty of software still operates this way and it works just fine. If you need a lot of background work, or low latency responses, or scheduled tasks or whatever then use something else that suits your needs, it doesn’t all have to be functions all the time.

And if you have a higher-up that got stars in their eyes and mandated a switch to serverless, you have my pity. But if you run a dairy and you switch from cows to horses, don’t blame the horses when you can’t get milk.

It’s an old joke from back when IBM was the dominant player in IT infrastructure. The idea was that IBM was such a known quantity that even non-technical executives knew what it was and knew that other companies also used IBM equipment. If you decide to buy from a lesser known vendor and something breaks, you might be blamed for going off the beaten track and fired (regardless of where the fault actually lay), whereas if you bought IBM gear and it broke, it was simply considered the cost of doing business, so buying IBM became a CYA tactic for sysadmins even if it went against their better technical judgement. AWS is the modern IBM.

No one ever got fired for buying IBM.