Serverless computing–otherwise known as FaaS (function as a service)–doesn’t mean there isn’t a server doing the heavy lifting; it’s about the user not seeing or maintaining the server and not caring where in the world it’s located. It’s all about getting the work processed in a timely manner somewhere where you aren’t watching.
The idea of “serverless” computing came upon the IT scene about nine years ago as an interesting buzzword and potential greenfield for new products for enterprises, developers and IT product makers. And, as is common when new buzzwords start circulating, not a lot of people understood what “serverless” means, and perhaps that’s why the idea kind of stalled in the marketplace for a few years.
In this eWEEK Data Point article, Adam Leventhal, co-founder and CEO of Transposit, explains the state of serverless computing here in the waning weeks of the second decade of the 21st century. Leventhal is the creator of popular performance analysis and troubleshooting tool DTrace and former CTO of Delphix, a database virtualization provider.
Data Point No. 1: Serverless is a way to ‘Set it and forget it’ – sort of
Serverless actually delivers on the promises the Docker or container movement has been making. Write your application and let someone else worry about infrastructure, patching, security and scalability. More generally it lets application builders build and not sweat a lot of undifferentiated but necessary complexity. Developers have so much to keep in their heads these days; serverless lets them focus.
The bargain is a pretty good one: If you can write your app just so, if you can make it fit in this box, then we’ll handle the rest. While Serverless is still gaining adoption, we’ve seen variants of this bargain in software’s history, from app servers and cgi-bin all the way back to the relational database–platforms reduce complexity for app developers.
Data Point No. 2: Serverless is applicable to many use cases
The clearest use cases are reactive, short-lived interactions: simple web APIs, chat bots, DevOps glue code. Amazon urges pervasive use of Lambda–their serverless offering–for lightweight customization; it’s the generic platform to wrangle other services or massage data. Integrations with platforms such as Slack, Github or Twilio are easy to conform to serverless constraints while developers get to hand off a bunch of distracting infrastructure.
Data Point No. 3: Serverless is still a work in progress
The most popular serverless platforms–AWS Lambda, Google Cloud Functions, Azure Functions–all present challenges once data gets involved. Want to talk to local AWS services? Dead simple. But once authenticated APIs get involved, it’s more of a pain. Where do you store tokens? How do you handle OAuth redirects? How do you manage users? Quickly that narrow use of serverless can snowball into a pile of other public cloud services … to the point that you’ve swapped the complexity developers know for some new piles of stuff to learn.
Data Point No. 4: Serverless is cost-effective and elastic
The best part of all these serverless offerings is that they’re very elastically priced. It costs almost nothing to get moving. Rather than reading docs from AWS, start with an opinionated take. Technologies such as Serverless.com, Zeit, and Pulumi all have different ways of curating the collection of options for developers. Many serverless platforms have great libraries of applications you can use and learn, fork and customize. Start from an example that’s close to what you want–or just sounds fun.
Data Point No. 5: Serverless is the new black
Serverless is a relatively new term, but we can apply it reasonably to older platforms such as Google App Engine, Heroku or even the defunct Facebook acquisition, Parse. That said, it’s 100% the future. There’s not going to be one serverless platform to rule them all, but it’s going to be the dominant programming paradigm. Containers are a stepping stone. Serverless lets you slice up the tech stack in a way that’s maximally focusing for developers and broadly applicable as long as your service isn’t doing deep differentiation at the level of infrastructure.
If you have a suggestion for an eWEEK Data Points article, email cpreimesberger@eweek.com.