- Original Title: Serverless Is the New Timeshare , Author: Shai Almog
Remember mainframes? Serverless is like: We own this machine, you come and rent it from me. Innovation is often born on the shoulders of giants!
Time-sharing vacation is a vacation model originated in Europe, which divides the use right of a room or a tourist apartment in a hotel or resort into several weeks, with a period of 10 to 40 years or even longer. The way of membership system is sold to customers at one time, and members get a leisure way of staying in hotels or resorts for 7 days a year. And through the exchange service system, members exchange their own guest room use rights with other members' room use rights in different places, so as to realize the purpose of traveling and vacationing in various places at low cost.
Looking back, serverless is the new timeshare!
We all have amnesia. When I talk to young developers about technologies of the past, I often get blank stares. To be fair, some of it is because I'm a bit "nervous" or "weird", but some of it is because young techies don't understand old tech.
For example: Some young technicians have no idea what 2 Phase Commit is. Is it that transaction management is no longer needed?
Do banks no longer need consistency? This technique works by transferring transaction context between different servers if you are not on the "same page". So a commit on one server is a multi-stage process that is almost guaranteed to succeed on all servers or rollback as one. This is pretty amazing and actually works pretty well (with some caveats obviously). Surprisingly, this is achieved through method calls. You don't have to do anything, it will work just fine even when calling the remote method on a completely different server.
A few years ago, I was talking to a startup in the banking industry called Node-based. Banks are very open to working with Node, they said. I know they rewrite their stuff in a more "mature" environment. When I use some "newer" tools like Node, I'm always surprised by the lack of basic functionality. Of course, it's simpler and smaller if you don't fit everything we need into it. It's easy to build something simple when you ditch the core functionality.
The NoSQL Dramas of the 2010s
Back in 1999, I was forming my own consulting firm when a friend asked me to meet his boss. I went to this office and the "boss" said he had the most amazing idea that no one else had. They have the funding and will launch in 6 months and roll out to 1 million users on day one!
me: ok. what idea?
Him: I'll let you know after you sign up to work for us.
Me: I will sign an NDA (NON-DISCLOSURE AGREEMENT, that is, a non-disclosure agreement).
he does not. It's a great idea. Those NDAs are worthless. you sign up and...
Somehow, I was able to resist the temptation to work for this company. After about a year, they obviously didn't launch, but my consulting firm is doing just fine. My friend called me again. This time they needed help with the product, so I went there in a consulting capacity to help them.
The idea is to have a chat application built into the website so that the site's visitors can chat with each other. A competitor has launched and I'm consulting several other companies with the same idea. Instead, they focus on chat related to e-commerce. But I digress...
Their system performed very badly. A user's speed is as slow as an ant stuck to honey. Apparently the CEO was adamant that they needed to be able to support 1 million users on day one (as he told me). They communicated this to Oracle Corporation, who said they needed a cluster of three servers to support this capacity. Then they talked to an object-oriented database vendor who promised they could handle a million users on a single machine. So they went all-in on object-oriented databases. When I was shocked by this, they claimed that their data was very "object oriented" in that each user could have multiple items... duh.
They don't understand transaction boundaries, store code is mixed with all code, and they're slow. This is unreliable and incomprehensible. You may not remember the object-oriented database days, but it was a precursor to the NoSQL fad that swept our industry in the 2010s. During my time as a consultant, I re-watched reruns of this story. This time most companies have successfully launched.
But then they discovered that having unstructured data is not a panacea. The performance gain they gain is negligible compared to just using good caching and well-tuned SQL. Deployment stories are complex, and assistive tools may never reach the level we have in the SQL world.
To be clear: NoSQL has its niche, but the common uses of these databases are not very good and stem from RDD (Recovery Driven Development). Here's a pattern that those of us who have turned around the block a few times have seen over and over again:
- • Old technology is cumbersome and complex
- • People invented something clean and simple
- • Forget about old technology
- • New stuff is simplistic and doesn't do many basic things
- • Reshape these complexities
- • New stuff becomes old and clunky complexity that needs to be reinvented... rinse/repeat
Serverless is the new mainframe
I've been doing a lot of serverless work in the past month, and I feel like this is a big step back. This is a repeat of the same problem we have with PaaS. It's actually a mainframe. In the past, we used to pay to run our jobs on shared-use mainframes. It's a bit like a virtualized environment , but the idea is similar: we don't own the environment. The same can be said for cloud SaaS, but serverless takes the concept very far.
Even the debugging experience sucks. We have no fundamental control over our code or basic application logic. I'm trying to figure out why people use it for anything other than basic tasks.
I can think of one good use case: webhooks. Getting the plumbing code for a webhook is always a pain. They trigger infrequently and dealing with it is a chore. It can be as simple as adding content to a database and getting the job done using serverless functions. Since it's hard to debug callbacks anyway, a poor debugging experience in serverless isn't a huge hurdle. But for every other use case I'm absolutely stumped.
People spend a lot of time checking and measuring throughput, but using only a slightly larger server, and only local calls yields more throughput than you probably need. Without all the vendor bundling we're stuck with. You will save a lot of money with hosting like Linode, Digital Ocean, etc. In terms of time to market, just using caching and fast local tools will be much easier than anything you can build in the cloud.
Containers are a great advancement, they make this a lot easier, but we would be overwhelmed by the complexity of using containers, like K8S. Don't get me wrong. K8S is great. But 98% of us don't really need it, nor should we use it. If you're a small startup, Kubernetes is a waste of your time and energy.
Back to Java and Rust
Java is an example that does a great job of "forgetting". We have Smalltalk and it's great. When Java first came out, it was an inferior solution with a weird C syntax style. Java threw away many great ideas in Smalltalk and C++. It employs some controversial ideas (checked exceptions, primitives, etc.). Yet it worked. It grabs attention; it can capitalize on that.
It started out as a lightweight language that discarded all the garbage and overengineering that other platforms had added. Look now, no one described it as "lightweight" anymore. Developers are busy creating lighter, simpler languages to complain about Java's bugs. Success will bring them back to where we started. A lightweight language that has grown too much. Java is where it should be right now. This is one of the few examples of a good rewrite.
Rust also seems to be one of the few exceptions. It reinvents C in a whole new way. It's hard to say whether it will survive long term. But make no mistake, it takes a lot of complexity along the way.
conscious remodeling
What makes the reinvention of an existing language or tool successful for the mass market, and what makes those tools fall by the wayside?
SQL is back from the dead, and is once again a favorite of new startups. The same cannot be said for C++. How are they different?
Despite lacking the basic features we have in the JVM world, Node and Python are still popular. So what's going on, and will they maintain this popularity? Will they add these things back?
Until the teenage years, our brains are constantly adding synapses. In our teens, we chopped them off. One theory is that this is at the root of all the changes we experience as teenagers. We need to disconnect what is no longer working for us. Otherwise, we only learn what our parents know. We cannot improve by making our own mistakes. Try again what that generation failed.
As a result, we repeated our mistakes and made some new horrible ones. We've also made some amazing leaps and discoveries. This is where innovation takes off, and so does engineering.
How do we tell the difference: Adolescent anxiety and bright new directions?
Honestly, we can't. As an older person, when I first saw this stuff, a lot of it seemed silly to me. We've tried these things and failed. Why repeat that wrong direction? This is where the innovation lies. However, if we look closely at successful attempts, we can see what worked for them.
Java was not designed to end C++. Of course, this could be an illusion. But Gosling designed it for simplicity and lightness. To address a very narrow niche, focus on security, scale, and networking.
Rust is not designed to kill C. It's designed to make projects like Firefox more stable and performant.
I think secondary inventions, like any startup, work well when we initially limit ourselves to a very small and narrow use case. By doing this and maintaining that initial focus, we can build something good and then make great leaps.