Click here to Skip to main content
15,908,776 members
Articles / Hosted Services / AWS

What is Serverless, and Why Should You Care?

Rate me:
Please Sign up or sign in to vote.
4.92/5 (8 votes)
4 Mar 2019CPOL5 min read 9.4K   3   1
A brief overview of what Serverless is, and why giving it a try is worth your time.

This introductory article is part of CodeProject's Server Functions Challenge.

Serverless is a term that many developers love to hate.

“Blasphemy!”, they cry. “My code is clearly running on a server somewhere, so it can’t actually be serverless!” And they’re technically correct which is, of course, the best kind of correct.

But it’s possible to be technically correct and still entirely miss the point. While it does indeed run on servers, this fancy technology that trendy developers are calling serverless is actually pretty neat. Even better, it’s built on solid engineering practices that can deliver a huge amount of ROI when used appropriately.

Efficiency Matters Again

If you’re still not sold, here’s one last thing that might grab your attention: serverless makes efficiency cool again. For years, we’ve been told that the efficiency of our code no longer matters all that much, because the world is awash in CPU cycles, so we may as well use them!

Notwithstanding the fact that we’re usually told this by hipsters sitting in Starbucks churning out totally awesome Ruby apps while the 27 Electron apps they’re running are draining their MacBook batteries to zero in under an hour, the argument does have some merit. Developer time tends to be expensive, and over the past two decades, CPU time has become increasingly cheap. So it has made sense to be willing to sacrifice some code efficiency to improve developer efficiency.

The cloud has been a great equalizer, however. Companies large and small have been unable to resist the allure of cloud computing. In many ways, it’s nice to be able to outsource all of the headaches involved in procuring, administering, and maintaining your own hardware. Even the company accountants love it! No more time wasted accounting for the depreciation of servers that start out costing as much as a car but quickly turn into oversized paperweights.

There’s a drawback to this convenience, however. The cloud isn’t magic. It’s just someone else’s computer. And all of those somebody elses who offer up their computers via the cloud aren’t bashful about asking you to fork over large sums of money in exchange for you using their CPU time. And they ask you to fork over even larger sums of money in exchange for using their RAM!

Lest I seem like a grumpy old curmudgeon, I think that this is usually a good tradeoff for startups and large enterprises alike. Being able to spin virtual machines, databases and a huge number of other services up and down at will is amazing. Not having to deal with the headaches associated with owning server hardware is even better.

Cost Efficiency

Since cloud services are relatively expensive, ideally you’d like to use as little as possible. This brings us back around to software efficiency. If you write efficient applications, you’ll need to use fewer computing resources to run them. In traditional cloud hosted VMs, this translates into being able to run fewer VMs, with less CPU power and RAM assigned to them. If you’ve looked at the price of cloud VMs, especially those with lots of RAM, you’ll know how expensive they are.

Even if you write efficient code and therefore need fewer cloud VMs, there’s still lots of waste. To a certain extent, you can scale the number of VMs up and down depending on load. But those VMs aren’t all at 100% utilization all of the time, so you’re paying for resources you aren’t actually using.

Serverless computing takes efficient cloud computing to its logical conclusion: you pay only for the time your code spends executing, and the memory it actually uses. So although it’s technically running on a server, you never need to actually think about the server. You write individual “serverless” functions and deploy them to the cloud. You set up triggers that determine when your functions need to run.

The cloud provider handles all of the logistics of getting your code onto the hardware that runs it with no work needed from you. It could end up running on a quantum computer, a high-end blade server, or a 386 that Jeff Bezos picked up at the Fremont Sunday Street Market. So long as the cloud provider offers you consistent billing based on the amount of computational power used, and your functions execute in a reasonable amount of time, you don’t have to care about what it is running on.

Serverless computing is serverless in the same sense that Uber is “carless”. When you take an Uber, a car is technically involved. But you don’t have to worry about any of the headaches typically associated with a car: loan payments, gasoline, maintenance, or dealing with overcaffeinated road-raging drivers. Serverless and Uber have the same value proposition: you sit back and enjoy the ride while outsourcing the hassles of ownership.

Serverless has typically been used to describe a specific technology: functions-as-a-service. This technology manifests in the form of AWS Lambda, Azure Functions, and Google Cloud Functions.

In the technology world, when something new takes off and becomes a buzzword that every marketer and pointy-haired boss in the world falls in love with, companies tend to start re-branding and re-working existing technologies to fit under the trendy new buzzword.

Serverless is no exception. Amazon now offers a serverless database. Google includes its decade-old App Engine under the serverless umbrella, along with several types of cloud storage and machine learning services.

This is all well and good, but we’re going to avoid playing buzzword bingo and limit our look at serverless to its original definition of functions-as-a-service. Otherwise, the tutorial series we’re about to embark on would be 800 articles long.

Although we’ll only be looking at functions-as-a-service, keep in mind one important property of nearly every service that describes itself as serverless: they’re all pushing us away from DevOps and toward NoOps - or at least WayLessThanBeforeOps. You’ll probably still want some DevOps systems in place to automatically test and deploy your serverless apps.

The common thread among serverless offerings is that they don’t require any thought or work on your part to create or scale infrastructure. Serverless is like the Ronco Rotisserie Oven of the computing world - you just set it and forget it.

Let’s Get Started

Try your hand at our tutorial, which involves creating a serverless geocoder on Azure: An Introduction to Serverless Functions on Azure.



This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Written By
Software Developer My House
Canada Canada
I spent 5 years working for Ottawa startups before returning home to Toronto. During Covid I decided to escape the big city and moved north to Penetanguishene, Ontario.

I'm a .NET/JavaScript/TypeScript developer and technical writer by day, but in the evening you'll often find me cooking up projects in Ruby, Haskell, Clojure, Elixir, and F#.

Comments and Discussions

QuestionSecurity is also an issue with this technology. Pin
AnotherKen6-Mar-19 16:40
professionalAnotherKen6-Mar-19 16:40 
The main problem I have with serverless code is simply it's distinct lack of security for the end-users. This is fine if all the users trust each other. But for something that almost anyone could be logging into, the last thing anyone should want is having their ip-address exposed to a hacker. Even using cloud servers has been proven to be insecure (for some time now).

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.