Thread by @halberenson

I love the opportunity to dive into the history here, especially since @Grady_Booch and I get to play the Grey Beard card. Think of Serverless in two ways, as an architectural pattern and as an operational pattern. The IT guys are the ones who see it as an operational pattern.

https://twitter.com/ben11kehoe/status/1435353387688620035

As an operational pattern Serverless is new, because without “the Cloud” IT can’t get away from having to manage Servers. As an architectural pattern it is OLD, dating back at least to the 1970s. It is a concept intertwined with that of the Remote Procedure Call (RPC).

So from at least the late 70s, but particularly in the 80s, we see architectural efforts to disconnect the functional breakdown of applications from their execution environment and allow each procedure/function to be independently placed.

Originally the boundaries were usually processes, later they became computers (whose roll we eventually called servers). OLTP Monitors (Application Servers) evolved to be one of the major mediators of the mapping between functional decomposition and execution resources.

When I first saw AWS Lambda I had an immediate “Cloud OLTP Monitor” reaction. Everything old is new again. Only the young think it is really that new 🤣 But I’m an OLTP guy, and helped develop OLTP Monitors, so to me it was cool.

Now we have two dynamics at play. We have developers without the decades of scars from this design pattern jumping on it like the universal cure for disease meeting up with IT’s disdain for having to deal with servers and their costs (in all its dimensions). What could go wrong?

It is a formula for bad design decisions. Don’t let the lure of the cost savings overwhelm your architectural thinking or you end up with both bad design decisions and failure to achieve cost savings. That’s all I see Grady pointing out.

Instead think of Serverless as another tool. As an engineer, for me the design pattern has always been about a way to achieve scalability and availability. Could that lead to cost savings? Oh yes! But that was an outcome of good design, not the primary objective.

My mission in the 70s and 80s was how to make distributed minicomputers a better solution than mainframes. This design pattern helped make that a reality. And to be fair, the anticipated cost savings was a great driver for customers.

Just as with Serverless, if a customer let cost savings be the primary driver for the distributed-mini vs mainframe decision they often had a disappointing result. It was when you took advantage of the unique properties afforded by the new architecture that you had the big win.