by Dylan Huang on August 21, 2023
From DHH shunning serverless, Ahrefs saving millions by using a cloud provider at all, to Amazon raining fire on their own serverless product, serverless has recently faced significant scrutiny.
But still, everyone and their pet goldfish seem to be creating a serverless runtime (see Bun, Deno, Pydantic, Cloudflare, Vercel, Serverless, Neon, Planetscale, Xata, FaunaDB, Convex, Supabase, Hasura, Banana, and literally hundreds more). One research paper from Berkeley even claimed:
Serverless computing will become the default computing paradigm of the Cloud Era, largely replacing serverful computing and thereby bringing closure to the Client-Server Era.
-- Cloud Programming Simplified: A Berkeley View on Serverless Computing
Is it all hype? Is there real 100% objective merit to it? Where does serverless excel? Where do the trade-offs make sense?
To understand how developers are receiving serverless, I went to where developers live: Reddit, Twitter, Hacker News, and YouTube. I parsed 1,000s of discussions and synthesized my findings in this article, striving to present only thought-provoking opinions.
Next, I transcribed these discussions onto a whiteboard, organizing them into "Pro Serverless," "Anti Serverless", or "Neutral" categories, and then clustering them into distinct opinions. Each section in this post showcases an opinion while referencing pertinent discussions.
Giant software companies such as Shopify, GitHub, and Stack Overflow have achieved new heights using tried-and-true frameworks like Ruby on Rails. However, serverless presents an intriguing new paradigm that promises to reduce costs, accelerate development, and eliminate the need for maintenance. And as with any technological shift, there will always be skeptics.
One of the most vocal criticisms of serverless computing is the unpredictability of its costs and the latency associated with cold starts. While cloud providers have made significant improvements in optimizing serverless runtimes over time, these issues remain a significant concern for many developers.
Additionally, serverless introduces a new paradigm that brings its own set of challenges when building complex applications, particularly those requiring multiple services to communicate with each other. This is already a common problem with microservices, but serverless further complicates the issue by forcing developers to work within a stateless and I/O-bound compute model.
These latencies can have real financial consequences; Amazon found that every 100ms of latency cost them 1% in sales. Moreover, without proper billing safeguards in place, serverless costs can spiral out of control, potentially leading to the infamous situation of a startup sinking under its cloud bill.
Encountering any of these issues could understandably leave a sour impression and be a compelling reason to abandon serverless in favor of a traditional VPS.
Serverless is a fad, and the hype will fade.
Kudos to AWS's marketing team, as they successfully persuaded thousands of CTOs to stake their entire technology stack on a contentious new paradigm for building applications.
Some even go as far as to say serverless is "dangerous" or "wrong". In some ways, this viewpoint is not exaggerated. If cloud providers were not striving to lock everyone into their products to capture market share and boost revenue, what kind of corporate entities would they be?
Early adopters and evangelists did a great job at highlighting 10x features and pushing the cloud computing agenda. But always be weary of a technology that necessitates developers to acquire a new set of skills and tools, potentially wasting developer's time in a low-demand technology. Engineering teams should exercise caution when betting the farm on serverless as it may lead to vendor lock-in. When things go wrong, good luck with troubleshooting and refactoring!
At the end of the day, serverless represents a substantial investment that could arguably be better allocated to other aspects of the business. Why not utilize long-running servers that were already deployable and maintainable in the late 2000s.
So, does serverless really solve your problems, or are you just succumbing to the hype?
Technologies that catch on usually have something good going for them, and serverless is no exception. Despite all the buzz and marketing blitz, there's some real enthusiasm for it. Some companies are saving time and money with serverless, making it a win-win. Some devs think serverless is the new must-have tool in the toolbox.
Counter-intuitively, an interesting aspect of serverless computing is that it appeals more to early product development than to enterprise products is the speed at which features can be developed. The virtually negligible time and cost required to provision cloud computing resources make serverless computing particularly attractive to hobbyists for their projects.
During the early stages of building a product, the most critical factor to consider when designing your system is the pace of development. Concerns about scalability fall far behind developer experience, as they are not yet relevant issues. In this context, serverless computing provides a compelling value proposition.
In light of this, why would anyone waste time setting up their own server? Starting with serverless computing is a logical choice. If cost or speed issues arise, other options can be considered at that time.
For those who have successfully adopted serverless and lived to share their experiences, the enthusiasm is palpable.
It appears that building on serverless from first principles can yield outstanding results. Beyond the marketing hype, the true benefits of serverless become evident. Maybe as the Berkeley researchers predicted, maintaining your own server is becoming a thing of the past. With serverless, you can save money, reduce development time, and cut maintenance costsβa triple win.
Moreover, as serverless offerings like storage, background jobs, and databases continue to improve, the ecosystem will support the construction of increasingly complex apps, while still upholding the promise of serverless.
If you can navigate the downsides of serverless, you can create a product with an infrastructure that feels almost effortless. Perhaps the naysayers' tales are louder than the truth.
I believe it is crucial to emphasize neutral viewpoints. In my view, these tend to be the most truthful because they recognize the advantages and disadvantages of each approach. They are also the opinions least commonly expressed, as many developers tend to be set in their ways.
No technology is a silver bullet, and serverless is no exception.
Every technological decision is about choosing the right tool for the job. Serverless has some distinct trade-offs that need to be understood before it's adopted. Conduct thorough research on compute density, single-responsibility microservices, and performance requirements. Once you do, you'll see that serverless can offer immediate and tangible value. Recognize that serverless is not a replacement, but an alternative.
Whenever you hear someone criticize serverless, be wary of the problems they encountered. Were they design problems? Were there clear misuses of serverless? Serverless is not a panacea.
The anticlimactic conclusion? As always, it depends.
Though, I am more convinced that developers should strongly consider using serverless during the early stages of their SDLC. I previously built an application exclusively using serverless but was burned by lop-sided unit economics1. In retrospect, I can attribute that failure to not considering the downsides of serverless before adopting it.
That being said, I have also grown accustomed to Render for fast-paced development, and so far, I have no complaints. However, as I am always striving to become a 10x engineer, I will consider adding serverless to my toolbox.
I built a Shopify App that gave shop owners pixel-perfect replays of customers navigating their online store. I stored session data (using rrweb) in S3 and processed events using lambda. I ended up operating at a loss until I shut it down. β©