What do developers mean when they say “serverless application framework”?   Is it truly serverless?  How is it achieved?

I believe the right way to look at serverless isn’t “no server” but “less server.”  The idea is that you focus on what’s unique (code) and let someone else manage the infrastructure.  Unlike Platform-as-a-Service (PaaS) that is basically a hosted runtime you can deploy projects on, serverless provides hooks into that runtime that you can leverage.  For example, instead of configuring a web server you might set up your serverless code to trigger when a route is accessed via HTTPS.  Instead of configuring a scheduling engine, you might trigger your code via a timer built into the serverless host.

Although there are many platforms that support serverless, they share some common traits:

  • You focus on your code and essentially get a method with some information injected to play around with
  • You’re only billed for what you use, so when your serverless code isn’t invoked, you aren’t paying for a virtual machine or web service
  • The serverless platform is designed to scale to whatever is needed, without you having to worry about the details

Sometimes examples are helpful, so here are a few that lend themselves nicely to serverless:

  • Jobs that run on a timer (i.e. clean up a database, remove old sessions, etc.)
  • Event-based processing
  • File triggers – build a thumbnail when an image is uploaded or import a CSV file
  • Web API endpoints
  • Webhooks
  • Data pipelines (ETL)
  • Event stream processing

At the end of the day, there is always a server.  The question is, do you have to go out and buy a box, hook it in, boot it up, install the OS, provide security patches, load the runtimes and install your app?  That’s metal.  You just write your code and deploy it, and the rest is managed for you?  That’s serverless.

Leave a Reply

Your email address will not be published. Required fields are marked *