Why aren't we all serverless yet?
varoa.net
varoa.net
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.
I do see its usefulness, but its not a one size fits all tool.
Ya, this is the majority of us.
https://github.com/dbos-inc/dbos-transact-py
You can build your software as a monolith and deploy it with one command to your own cloud or our cloud.
And gateway+lambda is a near perfect "dumb crud" app, though it is not without a startup cost.
If you need RDS for example you need the VPS.
It only looks good on the outside.
I find FaaS best when needing to automate something completely unrelated to what goes in to serving the customer. Stuff like bots to report CWV metrics from DataDog to a Slack channel.
But that means you're not starting with serverless, and it's your pivot from the original monolith.
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.
I want my code to be written and executed on my machine in a way that can at least kind of resemble the production execution environment. I want a binary that gets run and some IO access, most of the time.
If I have a VM or a "serverless"-style compute like Fargate on ECS, I can define an entry point, some environment variables, and we're off to the races in a very similar environment to my local (thank god for containers and VMs).
The _idea_ of lambda and the similar services is awesome to me, but it's just such a PITA to deal with as a developer, at least in my experience.
[0] https://github.com/aws/apprunner-roadmap/issues/9 (amusingly the issue OP posts on HN)
If you're not married to running your own Web server, you can use API gateway with your Lambda functions, which is the traditional approach. Your frontend and it's assets can be served from an S3 bucket with Lambdas powering your backend. Cold start times will be a concern with this approach, but there are "warm-up" strategies you can employ to prevent that.
(& the argument that I keep using against significant whitespace, which is that all sorts of other tools assume it can mess around with it with no downsides)
from lithops import FunctionExecutor
def hello(name):
return f'Hello {name}!'
with FunctionExecutor() as fexec:
f = fexec.call_async(hello, 'World')
print(f.result())
feedback: why make a clear distinction between "magic node" and "BYON"? Two new concepts to learn when I feel a value-prop for some users would be to not have think about these distinctions? (Just talking about wording and communication here - can you get the value prop across with less reification?)
Thanks again!
"Managed node" and "self-hosted nodes" are examples of more familiar concepts you can utilize to communicate.
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.
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.
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.
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
Now I'm stuck in the reality of backlash
And cashed–in chips.
seem very confusing to grug
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.
I have a friend who recently made a stupid bug in his processing pipeline on AWS. He woke up on morning and saw a message from his bank that his CC was over the limit.
When we have a bug, our Nagios send us a message that responces are more than 150% of average and we do a rollback.
So it's not only the risk of vendor lock-in, but also in surprising bills and policy changes, updates and other 3-rd party risks you end up with.
Serverless also means a lot of things. We also serve static content from an S3 bucket and cloudfront. Nothing else to manage once its setup.
The flip side of serverless is you really do need to think of state yourself. The J2EE code was rock solid in reliability, including recovering from almost every kind of issue you can imagine over a decade (database, connectivity, software crashes).
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.
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.
Not all abstractions and simplified services are good in all situations.
I really wish the 9mm headphone jack wasn’t being replaced with just Bluetooth. 9mm has worked for me 100% of the time. Bluetooth is regularly a piece of garbage.
I read Apple avoids that with their AirPods if your audio is already encoded in a supported format, but I don’t know if other general systems are smart about it.
If you remember the olden days of web development, when CGI was king, the web applications didn't listen. Instead, a separate web server (e.g. Apache) called upon the application as a subprocess and communicated with it using system primitives like environment variables, stdin, and stdout.
Over time, we started moving away from the CGI model, moving the server process into the application itself. While often a fronting web server (e.g. nginx) would proxy the requests to the application, technically the application was able to stand on its own.
Serverless returns to the old CGI model, although not necessarily using the CGI protocol anymore, removing the server from the application. The application is less a server, hence the name.
Of course I think that would be a DRM nightmare for big-corps. One could stream items another person's system owns for "free" without dealing with companies.
They aren't your servers and the server processes running your code are only active temporarily, usually with auto-scaling features.
This must be why they say programming is dead once you turn 40: You can no longer communicate with the young-ins.
No, it's even worse a misnomer when you are old enough to remember these days. They were CGI modules... running under a server. They were not "without a server". They didn't work without a server.
And in these days, we did have plenty of applications without any server. For instance, desktop applications using local in-process databases were very common, and plenty of what people nowadays do within their browser (connecting to a remote server on the other side of the world) was instead done using these local-only desktop applications. These applications are what could legitimately claim the moniker of "serverless". Not something which can only work when under the control of a server.
Not true at all. You can use CGI scripts from the shell just fine. And you almost certainly did to aid with testing! Per the CGI specification, communication is through environment variables, stdin, and stdout. There was not a server in the application like we saw later. Since around the mid-2000s, when CGI fell out of fashion, applications of this nature usually meant them serving on port 3000 (probably). "Serverless" sees removal of the server from the application again, moving back to a process-based concept similar to what we did when CGI was the thing to use, although the protocols may be different nowadays. It is not in reference to a specific technology like CGI, rather the broader idea.
> And in these days, we did have plenty of applications without any server.
"These types of applications", not "all applications"...
I understand both what you say and what "serverless" commonly means, I'm just saying it's essentially arbitrary. A symbol with no etymology that holds water.
Understandably, if you don't come from the software world you might think a server is a person who does work at your request, like serve you food at a restaurant. Is that where the problem lies? There are definitely still people, servers, serving the care to the systems that run the software. But that is clearly not the context in which it is used. It is very much used as a software term, and as a software term alone.
This might be why people are having trouble with it. "Cloud" and "serverless" both refer to hardware, not software.
"Cloud" was moving the hardware from something you managed, either in office or a datacenter, to using machines someone else managed, but it was still server-oriented (such as software in VMs or bare-metal that you managed).
"Serverless" drops even that, using ephemeral code that doesn't care what server it's running on, so the people managing the hardware can move your software as-needed.
Not really. "Cloud" refers to a software abstraction that tries to hide the existence of actual hardware namely to remove dependence on the availability of any specific hardware component (like, as in, being able to transparently move to another physical machine without the user ever knowing). It is clearly a software term. I can't go down to my local Walmart and buy a "Cloud". Amazon won't ship a "Cloud" to my place. There is nothing "hard" implied by the word as used in this context. I'll grant you that it more or less maintains some kind of "virtual" hardware concept. Perhaps that is what you mean?
There is no hardware association with "serverless". It refers to a pattern for developing a certain breed of applications that resemble servers, but without the server. "Server" is definitively a software term as used here. A server is an application that listens for requests from a client, typically on a network port if we are to dive into implementation territory, but could be something else like a unix domain socket. Much like CGI of yore, these "serverless" applications shed the server, relying on the runtime environment to fill in the missing pieces.
You are describing a thing that is not a foo, or does not do foo, not a thing that posesses no foo.
So, I say, this is just something you're saying and not a definition I ever heard or would have implied from context from others usage. And it's not a new term by now, so there has been several years for me to have gained this impression or understanding if anyone else were using it that way.
Exactly. "Serverless" lacks a server. Which, granted, wouldn't make sense with no context, but when you remember that the same types of applications were previously written to include a server and no longer include a server when written in a "serverless" fashion, that is exactly where the differentiation is found. It literally describes what it is.
> And it's not a new term by now, so there has been several years for me to have gained this impression or understanding
I have never, ever, seen "serverless" refer to anything else outside of the previous commenter who thinks it has something to do with hardware. But it clearly has nothing to do with hardware. There aren't warehouses full of "serverlesses" ready to be loaded onto trucks. It is not something physical. It is not in any way "hard", that much is obvious. It is undeniably a software term. So, what, exactly, is your impression?
"Server" does not solely refer to software, it is also a name used for hardware. Think along the lines of mainframe, host, hypervisor, and so on.
A computer that primarily runs a server (or multiple servers) is often colloquially also called a server in recognition of what it is doing, but server is still in reference to the software. If you repurposed that hardware to sit on someone's desk to run Excel, most wouldn't call it a server anymore.
> Think along the lines of mainframe
I am not sure that works. I expect a mainframe running Excel on someone's desk would still be considered a mainframe by most as mainframe usually refers to a hardware architecture. A server, in the colloquial hardware sense, could be of any kind of architecture, including a mainframe!
Regardless, serverless is not associated with hardware as it is usually used. It is, as virtually everyone uses it, about removing/not needing the server in your application, typically used in the context of a service like AWS Lamba which offers the aforementioned runtime environment that negates the need for your application to be a server. In fact, Lambda is specifically named in what looks like a majority of the sibling threads here. It is abundantly clear where the typical use lies. If you know of instances of people using it to refer to another concept, I would love to see it.
I don't think anyone is actually confused about that. We all know that server also can mean "computer that is being used to serve", and we all know that "serverless" does not mean that there is no computer that is being used to serve.
I mean that "thingless" means there is no thing. In "serverless" software, there is still a server. In both the hardware and software senses, but again forget the hardware part.
It's just that the software itself is not also it's own server for itself.
What doesn't make sense to me is it just seems weird to use a word like that to apply to that condition. "serverless", if it were anything other than "server", would mean there is no server, or does not use a server, or does not work by way of a server, etc. Like software that isn't client-server in the first place.
In this context of web apps, I would say that "serverless" would be impossible or meaningless, but the closest thing to a meaning would be "I don't need to worry about running the server".
Of course no matter what, you do need to run or at least use, some kind of server. If you program using all microservices in place of functions, you still have a piece of code somewhere that calls the microservices, and that code needs to be installed somewhere and run somewhere, and that is a server you need to run. Even if it's a fully managed service, you still need to subscribe to the service and manage your account, which is essentially "running the server". Fail to do it correctly and the app stops working.
I guess an "engineless" car is a car without an engine, and that maps exactly to what they're saying serverless means, software that doesn't include it's own server. But cars do generally include an engine, so an "engineless" car is a exceptional thing and so a meaningful term.
But software normally never includes it's own server. That is a recent thing and still only in the subset context of web apps. "serverless" in that sense is more like saying "roadless" car.
Sure, the car in fact doesn't include it's own road so it's true, but weird. Cars don't generally include their own road so it's weird to point out.
If you said "roadless car" out of the blue, just like "serverless" it wouldn't actually be quite meaningful at face value, but the closest thing to a meaning would be a car that does not require a road. An off-road vehicle. Not a car that doesn't include a road.
Back when the hype was virtualization (so probably mid-2000s, before my time at the company), a big project was run to try moving to virtual machines. After the research phase had been deemed a success, they were gearing up to go into production and put in a hardware order. This was supposedly rejected by an executive who complained that they should not need physical servers if they do everything on virtual machines now.
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.
In fact, the solution still used serverless afaik: https://www.youtube.com/watch?v=BcMm0aaqnnI
(take that u/UltraSane! https://news.ycombinator.com/item?id=42506205)
It likely could have been solved by serverless too, by using local storage and having the pipeline condensed into a single action...
FD: I'm not a fan of serverless for production anything.
But it's the python argument.
Python is super slow, inefficient and let's say that the build environment is not so nice.
However, it's so easy to write functioning software in python that the alternative sometimes is not more efficient code, it's no code.
Lambda, in theory, follows a similar paradigm, if you can click a button and have a service that scales to zero (with logging and monitoring) then you're more likely to make toy webhooks and tiny services. If I have to make a build pipeline and a docker container and wrangle some yaml, configure service accounts and a service definition with the right labels and annotations.
Well, that's a decent chunk of work that means I'm probably going to think a bit longer about even deploying my little toy service that might see one request a day.
Going to reiterate though: I do not advocate for serverless in production. If you seriously think you're building something that will scale, it's fiscally illiterate to use a managed serverless provider.
What’s the point then if its not easier?
Amazon runs both and serverless is a billing model. Many serverless runtimes consume containers.
Serverless, like microservices are a design philosophy.
Serverless is all about outsourcing the infrastructure for scaling a micro service. How you design the service itself, or the system its a part of, can vary widely.
There are definitely dedign constraints of going serverless, but I'd argue those are largely just the constraints of going with microservices rather than a monolith.
Technically, it is all about removing the server from your application. The name literally tells you so. It is true that removing the server can offer some benefits in the scaling realm. In particular, it allows you to scale to 0 now that you no longer have to keep the process alive to serve requests.
Of course, that is not tradeoff free. Scaling to 0 brings you right back to the old problem of slow initialization once a request does come in, which was the primary driver for why we moved to hosting the server in the application in the first place.
Technically its about removing the server from my list of responsibilities. There is still a server running my app, it just isn't managed by me and likely comes with auto-scaling features.
Not necessarily. Back in the serverless CGI days you would still typically manage Apache. What you say is probably why would you choose serverless in 2025, but not always. This is not the technical differentiation.
> There is still a server running my app
There may be a separate server (e.g. Apache) that runs your app, but that is someone else's app, not your app. Calling someone else's app your own would be rather silly. Your application is less a server, which is a change from how these applications had normally been written over the past couple of decades. At least since the death of CGI, you would traditionally see your application become the server (possibly proxied through another server, but that is ultimately immaterial to the discussion). That is what goes away with serverless.
Serverless doesn't have to be over engineered-garbage, even if some bored technologists looking for a promotion and/or to pad their resume try their best to make it so.
> Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%
> The move from a distributed microservices architecture to a monolith application helped achieve higher scale, resilience, and reduce costs.
You would think they would want to sell their expensive solution.
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.
* https://einaregilsson.com/serverless-15-percent-slower-and-e...
I worked for a company once whose entire product was built on hundreds of lambdas, it was a nightmare.
Any time AWS is mentioned I know it's going to be some huge expensive setup.
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.
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.
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).
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 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
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.
If you are lucky enough to have your company go viral and receive a sudden spike in traffic, will the rest of the infrastructure tolerate it? Will your database accept hundreds of concurrent connections, or will it tip over?
If you need to engineer and test the auto-scaling capabilities of the rest of your infrastructure, is there value in not needing to think about the scaling of your APIs?
These may sound snarky, but they are real questions -- I used to administer ~300k CPU cores, so I have some trouble imagining the use-cases for serverless
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..
My current employer standardized on serverless and for many things it works well enough, but from my standpoint it's just more expensive.
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.
Not really. Microservices normally refers to humans and how they work together, or, perhaps, don't work together. Microservices is the same service model found in the macro economy but applied to the micro economy of a single business, which was a novel idea at least to the general public, hence the name.
Due to Conway's law, the product ends up being a distributed system more often than not, but that is only a side effect. Theoretically you could have microservices without distributed systems, and we do see some instances of services found in the macro economy that are not offered as a distributed computing products, not to mention that services even predate the network. But distributed is definitely the way most things are going.
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!
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.
Separately, when you factor in data privacy, your decision making tree will certainly change quickly.