5 ms·

An interesting rant to be sure, but what the author misses (in my opinion of course) that serverless isn't new, it just isn't recognized by a lot of programmers

An interesting rant to be sure, but what the author misses (in my opinion of course) that serverless isn't new, it just isn't recognized by a lot of programmers for what it is. Serverless computing is exactly mainframe computing. And by exactly I mean exactly. You see when I was taking CS classes for my degree students bought something called "kilocoreseconds" (kCs) and they are exactly what they sound like, they are a unit measured in the combination of amount of RAM + the amount of compute per unit time your project consumed of the shared computing resource, the mainframe. You also got a quota of storage with which to hold your projects before you "launched" them on the mainframe with the all powerful "run" command :-). For those of us who liked to explore, it was a very real possibility that you would have to buy more kCs to get through the semester. There was vendor lock in because Doh! you weren't writing operating system code, you were writing application code. And once you make this connection, you can see all the problems that "serverless" has are all the exact same problems mainframes have for all of the same reasons. Basically mainframes are "good" when you want to have a small team do all the compute resource management and you have many teams that will want fractional usage of that resource over time. You can developed a closed form solution to the question "what does this compute resource cost to operate per unit time" and you minimize all of the things that affect that cost. Everyone maintaining it are all in one building, all of the equipment is in one room, all of the maintenance is logged and verifiable, etc. When do mainframes kind of suck? Well when you don't know whether or not you want to use them. Or when you have a different set of OS services you, and only you, need but burden every user of the mainframe. It is hilarious when you think about it, imagine this giant homogeneous blob of compute, the mainframe, that people disliked because it was "far away" and they didn't have any control, so desktop computers became a thing so that everyone could have their "own" computer, but then networks got bigger so people started virtualizing their desktop compters so IT departments started building bigger and bigger computers to hold many VMs and then because people figured out they could scale by using someone else servers, they started putting their VMs in data centers with a bunch of other company VMs and the data center people optimized by making bigger and bigger data centers, until even the lower cost of a VM was really more than someone wanted to pay for just running a single program so the Data Center types built a layer over all of their machines and services to make it seem like one giant machine. Ending up, nearly exactly back where they started except that now one company owns a mainframe and dozens of companies use it to run their bits of code. I literally laughed out loud when a low employee number senior engineer at Google proudly announced to the folks that Google was building this new concept of "Data center sized computers." This was like 12 years ago so I'm sure their vision has evolved but it never occurred to them (I checked) that maybe everything old was new again. But I still remember touring computer rooms that took up an entire floor of the building and were basically one computer. When you get this, you can then go look at where mainframe computers are today. Look at how the IBM Z series can slice and dice itself into logical partitions or LPARs and dynamically become a compute nexus of just the right size for your application, in either bare metal or OS based versions. That is where "serverless" should be looking for inspiration. Modern "web 2" architectures still partition various services into clusters. So you have the EC2 cluster, the S3 cluster, the Elastic Search cluster, Etc. Make the atoms in your world the pivot point and dynamically allocate resource based on your exact needs. Then bill it out in the gigacorepackethours or some other unit of measurement that captures what fraction of the overall datacenter your application consumed and for how long. Just don't bring back punched cards. They didn't really add value as far as I could tell.

FpUser 6y ago
Bows and hats off. I was thinking along the same line but your post is just a gem.
disqard 6y ago
A beautiful summary, compressing decades of experience into a pithy "Big Picture". Thank you for writing this, Chuck!
jacques_chester 6y ago
I generally agree that there is nothing new under the sun. But I also think history doesn't repeat, it rhymes. > When to mainframes kind of suck? Well when you don't know whether or not you want to use them. ... Ending up, nearly exactly back where they started except that now one company owns a mainframe and dozens of companies use it to run their bits of code. I think this reveals that there is an economic distinction between mainframes and serverless, along two fronts: size of commitment and economies of scale. Mainframe time could be extremely precisely subdivided when billing users, but the capital cost of getting to the first kilosecond was extremely high. In serverless settings the capital cost for the first unit of consumption is experienced as zero by everyone except the vendor. (Yes, IBM runs mainframes-as-a-service, but they don't do it on the cheap). The second difference is that the hyperscalers enjoy economies of scale and scope that no other organizations can match, including mainframe operations. If IBM is choosing between two different parts for a mainframe, they can pick the more expensive part and foist most of the cost onto their buyers, for whom there is little alternative. Meanwhile, for the hyperscalers, customers are much more price sensitive. More expense falls to their bottom line. But because they operate at such high scale, even tiny improvements are rational to pursue. Similarly, economies of scope come from the fact that they can pool much larger amounts of variance, which makes their workloads more predictable overall than any smaller organisation can achieve. This is just the central limit theorem mercilessly steamrolling noise into smooth, predictable shapes. But at least no punched cards.
- ChuckMcM 6y ago
  I really like this observation as well, especially the "cost to first kCs" which, for me, is the one differentiator. One of the things that amazed people was the Blekko, the search engine company, operated its own clusters in a data center rather than using AWS. We got a lot of side-eye for that but the numbers were pretty stunning. For our app, the cost of running that data center was about $120K/month, on Amazon (or IBM's cloud) that cost was at least $1.2M/month so 10x higher. What was even more of a pain that getting all the machines in the same racks so that they didn't share "east west" bandwidth with other racks in the data center was a huge ask for these folks, the proposed solution of over provisioning, made it just that much more expensive.

FpUser 6y ago

Bows and hats off. I was thinking along the same line but your post is just a gem.

disqard 6y ago

A beautiful summary, compressing decades of experience into a pithy "Big Picture". Thank you for writing this, Chuck!

jacques_chester 6y ago

I generally agree that there is nothing new under the sun. But I also think history doesn't repeat, it rhymes. > When to mainframes kind of suck? Well when you don't know whether or not you want to use them. ... Ending up, nearly exactly back where they started except that now one company owns a mainframe and dozens of companies use it to run their bits of code. I think this reveals that there is an economic distinction between mainframes and serverless, along two fronts: size of commitment and economies of scale. Mainframe time could be extremely precisely subdivided when billing users, but the capital cost of getting to the first kilosecond was extremely high. In serverless settings the capital cost for the first unit of consumption is experienced as zero by everyone except the vendor. (Yes, IBM runs mainframes-as-a-service, but they don't do it on the cheap). The second difference is that the hyperscalers enjoy economies of scale and scope that no other organizations can match, including mainframe operations. If IBM is choosing between two different parts for a mainframe, they can pick the more expensive part and foist most of the cost onto their buyers, for whom there is little alternative. Meanwhile, for the hyperscalers, customers are much more price sensitive. More expense falls to their bottom line. But because they operate at such high scale, even tiny improvements are rational to pursue. Similarly, economies of scope come from the fact that they can pool much larger amounts of variance, which makes their workloads more predictable overall than any smaller organisation can achieve. This is just the central limit theorem mercilessly steamrolling noise into smooth, predictable shapes. But at least no punched cards.

ChuckMcM 6y ago
I really like this observation as well, especially the "cost to first kCs" which, for me, is the one differentiator. One of the things that amazed people was the Blekko, the search engine company, operated its own clusters in a data center rather than using AWS. We got a lot of side-eye for that but the numbers were pretty stunning. For our app, the cost of running that data center was about $120K/month, on Amazon (or IBM's cloud) that cost was at least $1.2M/month so 10x higher. What was even more of a pain that getting all the machines in the same racks so that they didn't share "east west" bandwidth with other racks in the data center was a huge ask for these folks, the proposed solution of over provisioning, made it just that much more expensive.