Serverless: an Attempt at a Definition
Jesus. I have struggled with the word 'Serverless' for YEARS. I find it to be an overly broad, poorly-applied piece of jargon that largely serves as a marketing catchall. BUT, the patterns and architectures behind the advent of this phrase are super interesting. Below, I will spitball a bit about what this word means, at least in my low-functioning brain.
What is a Web Application, Anyway?
My mental model has always been the ol' client and server. We have two machines running programs. The client program is directed by the user to ask the server program for some information. The server program attempts to respond if it can. The pipe that connects the two is the internet. Fair enough. There's plenty abstracted away here (databases, task queues, etc etc), but the principle remains. And it still remains today, despite the popularity of Serverless.
The "Cloud"
A company used to have a team of Sysadmins, and they'd maintain a rack of physical servers, on premise. They'd configure the servers to talk to the public internet, set up firewalls, etc. The developers would hand off their code and it would be loaded and run on these machines.
Then cloud computing came around, popularized and made widely available and accessible by AWS. Rather than having physical servers on premise, you'd use a server sitting in a data center somewhere. You didn't have to worry about their upkeep. And soon enough, scaling and durability problems were solved by technologies like application load balancers and elastic scaling groups. But in most cases, users/customers were still "managing" their servers. You still shelled into them and manually kicked off tasks, programs, etc.
Enter "Serverless"
I remember when the onslaught of Serverless Services (say that 5 times fast) hit. I'd pin it somewhere around 2015. The leadership of the team I was on became obsessed with the concept of breaking our monolithic REST API apart and distributing the business logic it performed across a bunch of AWS Lambda functions. We could take advantage of serverless patterns to help break apart our aging monorepo.
This broke my brain. I was relatively junior as a software engineer at the time, but all the education and training I had received up to that point had always revolved around a web server. And now we were supposed to just not use them anymore? But still somehow have web applications in which a client sent an HTTP request to a URL and received a response? How the hell was that supposed to work?
Don't Panic. There are Still Servers.
Over the years, I've come to modify and solidify my understanding of what Serverless really means. Or course, there is not one singular accepted definition. Serverless is a marketing term for the most part, but that won't stop annoying software engineers from having pedantic arguments over the term and its meaning and application.
Anyway, there are still servers. There are still programs behind all these serverless services that listen for HTTP requests on a given port and respond to them. These programs are still assigned IP addresses. DNS is alive and well.
Serverless isn't a binary or boolean value. It's a term applied to cloud computing services to paint them as being "more managed than you'd expect". Serverless means there is more abstraction around the service than there used to be, and computer science and programming are all about managing abstraction. Rather than managing a REST server and some kind of handling functionality, you can simply create a Lambda function and point it to an API Gateway. These things both scale as necessary. They are durable and won't fall over. And you don't need to manage them. You just worry about the business logic. And, at the end of the day, these are programs running on Amazon EC2 servers somewhere. But again, you don't have to manage that.
There are plenty of gotchas with my definition above. Serverless configurations can have some tradeoffs, especially around things like cold starts. Maybe more on that some other time.
But don't panic, there are still servers.