Why aren't we all serverless yet? (opens in new tab)

I still find the DevEx of serverless terrible compared to the well-established monolith frameworks available to us.

The YAML config, IAM permissions, generating requests and responses, it's all so painful to get anything done.

Admittedly I speak as a software engineer primarily building CRUD apps, where frameworks have had decades of development. I can see use cases for event-driven applications where serverless may make life easier. But for CRUD, currently no chance.

This misses the main factor, I think: Vendor lock-in.

There is no unification of APIs - every provider has their own bespoke abstractions typically requiring heavy integration into further vendor-specific services - moreso if you are to leverage USPs.

Testing and reproducing locally is usually a pipe-dream (or take significantly more effort than the production deploy). Migrating to a different cloud usually requires significant rewrites and sometimes rearchitecturing.

Because most applications have 27 active users per day and a $10/month VPS can handle 100000.

This article misses the most important reason to not use Serverless: Cost. It's way more expensive to run serverless than it is to run any other format, even something like AWS Fargate is better than Lambda if you keep your Lambda running for 5% of the time.

The second one is even more important though: Time. How many of my systems are guaranteed to stop after 15 minutes or less? Web Servers wouldn't like that, anything stateful doesn't like that. Even compute-heavy tasks where you might like elastic scaling fall down if they take longer than 15 minutes sometimes, and then you've paid for those 15 minutes at a steep premium and have to restart the task.

Serverless only makes sense if I can do it for minor markup compared to owning a server and if I can set time limits that make sense. Neither of these are true in the current landscape.

For me, it's because Rails has continued to be an excellent solution in every application I've ever needed to build, whether it's a project with 1 user or 10 million, or with a dev team of 1 or 100.

Every time I try to solve a problem with anything other than Rails, I run into endless issues and headaches that would have been already solved if I just. used. Rails.

> The median product engineer should reason about applications as composites of high-level, functional Lego blocks where technical low-level details are invisible

This is a good way to get nonfunctioning product. Or at least a lot of frustrating meetings.

The thing is, "serverless" still has a server in it, it's just one that you don't own or control and instead lease by short timeslices. Mostly that doesn't matter, but the costs are really there.

they constantly try to escape

from the complexity outside and within

by dreaming of abstractions so perfect that no one will need to be good

but the latency that is will shadow

the "simple" that pretends to be

Because it's more expensive for less performance with less control.

If it were 5% worse performance for 7% more cost, most people would probably not bat an eye.

When it can be 50% less performant for 200% more cost, eventually someone is going to say: sure there's overhead to owning that but I will be at a major competitive advantage if I can do it even just OK. And it turns out for most businesses doing it at the scale they need isn't all that difficult to get right.

> The median product engineer should reason about applications as composites of high-level, functional Lego blocks where technical low-level details are invisible. Serverless represents just about the ultimate abstraction for this mindset.

I think the answer is in the first sentence. A lot of engineers make products that don't touch the internet. This concept is lost in the noise quite a bit.

Because we use Nix recipes to deploy our Datalog-ish backend connectors that talk to Amazon Elastic Beanstalk via a bespoke database we wrote in Julia that's deployed on Snowflake Container Cloud. But there's a missing backslash somewhere and nobody can find it because even ChatGPT cannot decipher the error messages.

Maybe it's an expired certificate but the guy who knew how that stuff works built a 12,000 line shell script that uses awk, perl, and a cert library that for some reason requires both CMake and Autotools. It also requires GCC 4.6.4 because nobody can figure out how to turn off warnings are errors.

Because serverless doesn't exist. Serverless just means it runs on someone else's servers, just like the cloud. And 10 years down the road people have forgotten how to run basic things, but Bezos buys Panama.

Serverless doesn’t mean no-server. It means someone else’s server. Their system. Their rules. Their way or the highway. No thank you.

Simple monoliths are much easier to reason about and debug. And the costs are much easier to estimate.

Serverless functions are quite interesting for certain use cases, but those are mostly additions to the main application. I'd hesitate to build a typical web application with mostly CRUD around serverless, it's just more complexity I don't need. But for handling jobs that are potentially resource intensive or that come in bursts something like Lambda would be a good fit.

How about cost at scale? Amazon itself shifted Prime Video from serverless to mostly containers and it resulted in huge savings.

> The median product engineer should reason about applications as composites of high-level, functional Lego blocks where technical low-level details are invisible.

We don't make buildings from Lego blocks. We do use modular components on buildings (ceramic bricks, steel beams, etc), but they are cemented or soldered together into a monolithic whole.

In my opinion, "serverless" (which, as others have noted, is an horrible misnomer since the server still exists; true "serverless" software would run code exclusively on the client, like desktop software of old) suffers from the same issue as "remote procedure call" style distributed software from back when that was the fashion: introducing the network in place of a simple synchronous in-process call also introduces several extra failure modes.

1. Speed 2. Price 3. Vendor locked-in

* https://einaregilsson.com/serverless-15-percent-slower-and-e...

It's not appropriate for high compute / long running workloads. Eg video transcoding. It's more expensive. Potentially higher latency.

I worked for a company once whose entire product was built on hundreds of lambdas, it was a nightmare.

Because tools like lambda are expensive Because it locks us into a cloud provider Because the architectures tend towards function explosion. Think CommonFuntions.java but all the calls are on the network. What could have been 2 containers and rabbitmq has become 50 lambdas and 51 sqs topics Because distributed observability is hard The ESB people became serverless function people and they brought their craziness with them. Im busy cleaning up what should be a fairly simple application but instead it has 300 lambdas. All that said, serverless managed services like databases are useful.

For what I need it sounds overly complex and expensive, when a $5/mo VPS works just fine.

Any time AWS is mentioned I know it's going to be some huge expensive setup.

"Look at how streamlined our organization is. We have no infrastructure to manage!" -IT Director with 206 different contract renewal dates.

You pay per compute, and thus you have unpredictable costs. People and businesses don’t like unpredictable things, we tend to avoid it.

We're all-in on serverless / cloud-native for our platform (document management); it works really well for our model, as we deploy into the customer's AWS account.

The initial development learning curve was higher, but the end result is a system that runs with high reliability in customer clouds that doesn't require customers (or us) to manage servers. There are also benefits for data sovereignty and compliance from running in the customer's cloud account.

But another upside to serverless is the flexibility we've found when orchestrating the components. Deploying certain modules in specific configurations has been more manageable for us with this serverless / cloud-native architecture vs. past projects with EC2s and other servers.

The only downside that we see is possible vendor lock-in, but having worked across the major cloud providers, I don't think it's an impossible task to eventually offer Azure and GCP versions of our platform.

I built a serverless startup (GalaticFog) about 8 years ago, had to shut it down. Market never developed. There were some obvious lessons learned.

First most companies thought they needed to do containers before serverless, and frankly it took them a while to get good at that.

Second the programming model was crap. It's really hard to debug across a bunch of function calls that are completely seperate apps. It's just a lot of work, and it made you want to go monolith and containers.

Third, the spin up time was a deal killer in that most people would not let that go, and wanted something always running so there was no latency. Sure workload exist that do not require that, but they are niche, and serverless stayed niche.

There's a huge grey area of "I want the response of a warmed up lambda" and "I don't have enough hits that it is actually warmed up" - pair with using certain language "runtimes" like the JVM and there you have it.

>Something I’m still having trouble believing is that complex workflows are going to move to e.g. AWS Lambda rather than stateless containers orchestrated by e.g. Amazon EKS. I think 0-1 it makes sense, but operating/scaling efficiently seems hard. […]

This isn't really saying anything about serverless though. The issue here is not with serverless but that Lambda wants you to break up your server into multiple smaller functions. Google cloud run[0] let's you simply upload a Dockerfile and it will run it for you and deal with scalling (including scaling to zero).

[0] https://cloud.google.com/run

We've looked at these tradeoffs over and over at places I work.

There's always part of the stack (at least on the kinds of problems I work on) that is CPU intense. That part makes sense to have elastic scaling.

But there's also a ton of the stack that is stateful and / or requires long buildup to start from scratch. That part will always be a server. It's just much easier.

For my own projects, I prefer lambda. It comes with zero sysadmin, costs zero to start and maintain, and can more easily scale to infinity than a backend server. It's not without costs, but most the backend services I use can easily work in lambda or a traditional server (fastapi, axum), so it is a two-way door.

'Serverless' has it's uses, but not for everything

- Serverless can get very expensive - DevEx is less than stellar, can't run a debugger - Vendor lock-in - You might be forced to update when they stop supporting older runtime versions

I understand the appeal of serverless, especially for small stuff (we have a few serverless projects at work, and I've built some hobby projects using Lambda), but ime DevEx is such a dealbreaker. Testing changes or debugging an issue? forget about it.

Without tooling to run a serverless service locally, this is always going to be a sticking point. This is fine for hobby projects where you can push to prod in order to test (which is what I've ended up doing) but if you want stronger safeguards, it's a real problem.

Before we all go into why lambda doesn’t work, remember that companies are happily handing many many millions of dollars to AWS each year, and will continue to do so for some time.

IMO, the dev workflow is significantly worse, integration testing is harder and I don't see the value on "scale to zero", when the alternative is a $5/mo VPS.

The optimistic tone at the start of the article might just be a hallucinatory strawman set up. But as a probably old dog, I fail to see the allure of these technologies(*).

When I read the copy trying to peddle them, to me it sounds quite like someone saying "Heey.. PSST! Wanna borrow 5000$ in cash, I can give it to you right now! Don't worry about 'interest rates', we'll get back to that LATER".

When I build stuff out of 'serverless', I find it rather difficult to figure out what my operation costs are going to be; I usually learn later through perusing the monthly bills.

I think the main two things I have appreciated(?), is

(1) that I can publish/update functions on cloud in 1-5 seconds, whereas the older web services I also use, often take 30-120 SECONDS(not minutes, sorry) to 'flip around' for each publish.

(2) I can publish/deploy relatively small units of code with 'functions'. But again, that is not quite accurate. It's more like 'I need to include less boilerplate' with some code to deploy it.. Because to do anything relevant, I more or less need to publish the same amount of domain/business-logic code as I used to with the older technologies.

Part from that, I mostly see downsides - my 'function/serverless' code becomes very tied-to-vendor. - testing a local dev setup is either impossible or convoluted, so I usually end up doing my dev work directly against cloud instances.

I'm probably just old dog, but I much prefer a dev environment that allows me to work on my own laptop, even if the TCP/IP cable is yanked.

Oh yeah, and spit on you too, YAML :-) They found a curse to match the abomination of "coding in xml languages" of 20 years ago..

> Microservices made a canonical example of how easy it is to miscalibrate that bet. Since the trend started ~15y ago,....

What started was the rebranding from distributed systems.

We have had Sun RPC (The network is the computer, a slogan now owned by Cloudflare), DCE, CORBA, DCOM, RMI, Jini, .NET Remoting, SOAP, XML-RPC, JSON-RPC,....

Client-Server, N-Tier Architecture, SOA, WebServices,...

Apparently the new trend is Microservices-based, API-first, Cloud-native, and Headless with SaaS products, aka MACH.

Shameless plug.

I work for a community project that is building a descentralized orchestration mechanism that is intended, among other things, to democratise access to serverless open compute while also being cloudless.

Take a look at the project at https://nunet.io to know more about it!

For anyone here struggling with AWS Amplify or AWS CDK - I recently discovered https://sst.dev/ for serverless deployment.

It doesn't solve all problems (tt isn't a CRUD framework) - but it does make the developer experience much better as compared to Amplify.

Lack of vendor-agnostic solutions, and ridiculous amounts of configuration. It explodes complexity.

I always found the whole thing odd personally. The Venn Diagram of people who both need to run a service in the cloud AND cannot manage an EC2 instance is a seemingly small set of people. I never saw the advantage to it and its got plenty of drawbacks.

I think it’s all about cost analysis. That said, there are definitely some services that are worth outsourcing, like smtp, until you get to a certain size.

Separately, when you factor in data privacy, your decision making tree will certainly change quickly.

Why would I care about serverless? I love managing and working with bare metal servers.

Why should I be serverless? I like servers. I like containers. I like options.

Isn't a shared host with php serverless for all intents and purposes?

Because most companies have incompetent OPs and leadership, that Cargo Cult themselves into more tech debt.

to me it seems much more intuitive to think in terms of actual servers. lambda seems like chicken nuggets but i wanna eat -say- a decent rotisserie not nuggets.

It’s expensive. Even considering dev and ops hours.

it's annoying and expensive

It's too bloody expensive. QED.

"A death star of death stars".

Because some of us need to have the servers that the "serverless" people use.