“Severless”
Every time I use the word “serverless”, which is somewhat regularly lately, as we’ve had a few articles using the term lately and use the concept at CodePen for a variety of things, I get some version of:
CMON BRAH YOU’RE STILL USING “SERVERS”.
And they aren’t wrong. Yes, when you build things on the web, there are always servers involved. Always. Whether it’s some old computer in a church basement, a computer in a rack at some big hosting company, or “The Cloud”, it’s a server.
I rolled my eyes at the term the first few times I heard it too. But now I’m hesitant to call it a bad term, in part because it’s really stuck, and there is something to be said for new terms that catch on so strongly. Also in part because it signifies a dramatic change in how you can use servers. It’s different economically, different devops-wise, and different in how you code for them.
To many of us, we’re aware a server is a computer. There are various ways to buy them, but you buy them. Here’s some money, here’s your server. It might be virtual, but it’s still something you’re responsible for. You put software on it. You spin them up and spin them down. You load balance them. You make choices about how much memory and disk space they have. You’re in charge of provisioning and managing them.
What serverless is trying to mean, it seems to me, is a new way to manage and pay for servers. You don’t buy individual servers. You don’t manage them. You don’t scale them. You don’t balance them. You aren’t really responsible for them.
You just pay for what you use. For example, AWS Lambda is free for 1,000,000 requests and then costs $0.0000002 per request after that. Cheap. Just this week Firebase launched “functions” which are essentially a serverless concept, and their $25 a month plan has 2,000,000 requests (along with all the rest of the stuff Firebase gets you).
That doesn’t work for all applications. It works for things in which you can write some code that is designed to take some stuff, do some work, and return some new stuff. You write an API.
You don’t have to go all in with the “serverless” idea. You can, and I imagine most people do, use it for things that make sense to use it for, and use traditional servers for the rest.
“Severless” is a post from CSS-Tricks
