Serverless Doesn't Stand Still
Tags: serverless, aws, progress
Published: 2024-05-01 14:00:00

Last month, I read an article from Max Rohde titled ["Death by Cloud or How to Build Brittle Systems"](https://dev.to/mxro/death-by-cloud-or-how-to-build-brittle-systems-4hjf). It contained some common complaints about the challenges of working with emerging, ever-changing technology, with a focus on serverless in particular.

I don't want to spend a lot of time discussing his specific example, except to say that if you are worried about "extensive configuration," and you deploy your serverless apps with [Terraform](https://github.com/goldstack/goldstack/tree/fc0fbd4c356d7efb3ccc06f775ca5f12500f3052/workspaces/templates/packages/serverless-api/infra/aws) or raw CloudFormation, you are going to have a bad time. If you use an IaC generator like Serverless Framework, you can have a serverless app running in production in an hour.

However, the thing that most stuck with me from this article was its theme, its lamentation of change. Not any particular change, but change itself. I have a different perspective. I think change is good. All progress is change and I want more progress.

Change is constant. Change is everywhere. Complaining about change is like shaking your fist at the sky. It's happening in your cloud provider, your customers, and your competitors; it's metaphysical[^1] and you cannot escape it.

## Changes from Your Cloud Provider
As an example, the author mentions his experience with AWS Lambda's sliding window of supported NodeJS runtimes. Node 16 was no longer to be supported by AWS Lambda (or [by NodeJS](https://nodejs.org/en/blog/announcements/nodejs16-eol) for that matter). Changing the version would require engineering effort that could be spent elsewhere, building new features, or otherwise growing the business. This is all true. However, what I found objectionable is the conclusion reached.

The author then goes on to say that this kind of responding-to-change maintenance "raises questions about sustainability and long-term viability in an environment where change is relentless and often forced upon us by service providers' decisions. [emphasis mine]" But this is not limited to serverless, as the author initially implied. Every service AWS offers is changing every minute of every day as their teams make a constant stream of improvements[^2]. Nothing stands still.

In the name of "stability," perhaps you think you ought to move away from the cloud and its managed services and control your own machines. But, isn't the data center itself changing? New hardware is coming in and old hardware is going out, like a modern-day Ship of Theseus[^3]. Changes are being made to the electric grid. Other data centers/warehouses are being built in the area and are attaching to your Internet provider's backbone. What is staying the same?

Can your cloud provider drive change you need to respond to? Absolutely. Will my private data center be immune from change? Not in the least. But, are these the only sources of change we need to contend with? Hardly.

## Change from Competitors
Let's imagine for a minute that your cloud provider has frozen everything around your app so you never had to make a change to it. What's happening in your market? Are your competitors standing still? I guarantee (with one caveat below) that they are working hard to introduce a product that will render yours obsolete.

Even with a strong customer base who love your product, those customers don't yet know the cool new technology that your competitors are working on. Those of us old enough can remember how loyal Blackberry users were in the early 2000s. The term "crackberry" was coined to describe the level of fanaticism the device had on its users. They couldn't live without it… until Apple introduced the iPhone. Apple didn't stand still for Research in Motion. Does anyone remember MySpace? Facebook does.

There are endless examples of innovation (change!) disrupting industries. A few of my favorites are Standard Oil saving the whales[^4], Thomas Edison disrupting Standard Oil[^5], Microsoft putting a computer on everyone's desk, and AWS becoming everyone's operations team. Change doesn't stop for anyone.
> All progress is change and I want more progress

## Attempts to Stop Change
There is one place where change can be suppressed to the point it appears still, and that is where political force is applied in an attempt to halt change. In the United States, it doesn't matter if you have a groundbreaking new idea for 1st-class postal service, you are prevented--by law[^6]--from implementing it. The US Postal Service is a true, government-enforced[^7], monopoly.

Other industries are slightly less protected but are still tightly within the grasp of government control. Two of the most highly regulated industries in the U.S. are banking and air travel[^8]. Let's say you have a highly efficient and effective method for screening your passengers for safety that doesn't involve long lines at the airport. I’m sorry, but you cannot move forward without permission from the TSA and FAA. What if you have a tremendous new technology for people to manage and transfer money that could revolutionize banking? I'm afraid not, you don't have the approval of the OCC, FDIC, FRS, NCUA, and OTS. And that's just the federal level of bank regulators; there are many more at the state level.

I have worked in FinTech and have seen firsthand how restrictive the environment is. Half your brain is tied behind your back before you even begin. Your new idea doesn't go to customers to determine success, it goes to regulators and your in-house compliance team. Anything that runs afoul of what the little tyrants of D.C. (or Brussels) have deemed acceptable is out. Change is not welcome[^9].

Ironically (or not), the author cites--as examples of enduring technology--both banking and airlines as industries that still use mainframe computers. Isn't that cool? No. It's pathetic, and we all suffer from their third-rate technological offerings because innovation (change) is barred from entering.

## Impacts on Ownership
Does change make ownership easier or harder? Let me sketch in some context first. I'm an advocate for engineering ownership. I think the developers should build it and run it. Is it easier for a developer to run a relatively static mainframe in a data center or to run a constantly evolving Lambda in AWS? There's no comparison.

This is why I advocate for serverless. Serverless is currently the easiest way for engineers to build and run applications for their businesses. It's the easiest path to engineering ownership that I've found and I've had great results with teams who adopt this approach.

## Change Happens
I consider myself pro-progress, and progress is change. Without progress, we stagnate, materially and intellectually (material progress is just a manifestation of intellectual progress). I'm excited that AWS is building better services that I can introduce to my clients to build their businesses.

The bottom line is that everything great we have right now has displaced (changed!) something less great. There are amazing new things from great minds on their way to us if we let them. Will you let them? I will. Bring on the next great change!

[^1]: that which pertains to reality, to the nature of things, to existence. [ref](https://courses.aynrand.org/lexicon/metaphysical/)
[^2]: AWS News Blog: [Announcements](https://aws.amazon.com/blogs/aws/category/post-types/announcements/)
[^3]: Wikipedia: [Ship of Theseus](https://en.wikipedia.org/wiki/Ship_of_Theseus)
[^4]: Foundation for Economic Education: [How Capitalism Saved the Whales](https://fee.org/articles/how-capitalism-saved-the-whales/)
[^5]: Ibid
[^6]: Wikipedia: [Private Express Statutes](https://en.wikipedia.org/wiki/Private_Express_Statutes)
[^7]: the only kind of monopoly
[^8]: Mercatus Center at George Mason University: [The McLaughlin-Sherouse List](https://www.mercatus.org/research/data-visualizations/mclaughlin-sherouse-list-10-most-regulated-industries-2014)
[^9]: I now refuse to professionally contribute to these highly regulated sectors and will not work for them.