What’s in a name? Server-less Architecture

Isn’t it amazing that you all you need to serve a rich, single page app on the browser is a public Dropbox URL? If you want user authentication and store some data, you could use Firebase. Then it gets an order of magnitude harder when you need an actual end-point which you can control to perform some authenticated service calls (hiding API key) or orchestrate some intensive computing process. From stage left, in comes AWS Lambda.

AWS Lambda lets you run code without provisioning or managing server.

Before we dive into this great marketing speak, how does this black magic work?

1. Uploads code (node.js, python, java) to AWS Lambda
2. Set up your code to trigger from other AWS services or HTTP endpoints
3. Lambda runs code when triggered
4. Pay just for compute time used (not for idle time!)

In theory, you have no servers to provision or manage. Teletext.io uses Amazon API Gateway to trigger events with AWS Lambda that stores the result into DynamoDB for a “server-less” content management service. FireEye uses it to save 80% on costs to process logs as required and not requiring a pool of idle machines, and then there’s Serverless SlackBot which allows everyone’s favorite communication tool to create your own SlackBot sans server.

How is this the same as PAAS?

So is this really server-less? No, it just passes the responsibility of who manages that headache. You can think back to the pre-historic age of Platform-As-A-Service (PAAS) with Heroku back in 2007. Servers were already virtualized, but you had to image them to run your specific code and maybe use something like Capistrano for deployments. Heroku did away with the provisioning/deployment with buildpacks and git push to heroku. You didn’t really run your application on any specific server, but a pool of dynos that you could allocate to do your bidding with a simple slider.

How is this different from PAAS?

“Server-less” becomes the idea that no explicit infrastructure is required, as in: no servers, no deployment onto servers, no installed software of any kind.

You can think of it as process/task management through the use of the latest innovations in container management services. Servers are being used, just brilliantly abstracted through docker containers and scheduling code to manage the workloads. A docker image can be provisioned, loaded with the code snippet, executed, and then torn down to free the resources for a different Lambda function in milliseconds.

There’s no need to worry about provisioning enough dynos or tuning scaling rules since each request is mapped to one AWS Lambda process. No instance ever stands idle or requires. It gets even better, you are only charged in increments of 100 ms instead of the second or in most cases by the hour. You get unlimited scaling at a fraction of the cost of existing models.

Is this PAAS+?

Greater flexibility, better pricing, is this the advent of PAAS+? Well, there are trade-offs:

• Maximum execution time is 300 seconds
• Currently, must be written in javascript, python, or java with constraints on language version and package support
• Code must be stateless, but can call a stateful service like DynamoDB or S3
• No logging into these compute instances, customizing the OS, or language runtimes.

Fortunately, this idea of server-less architecture or micro-services in a public cloud isn’t solely the domain of AWS Lambda. IronWorker has been around since 2011 and Webscript.io ran Lua scripts since 2012. Nor is AWS Lambda all that unique with Tutum, Stackhut, and WebTask innovating with on-demand containers. There’s even an interesting open-source alternative with hook.io. You could even say Google App Engine and Microsoft Azure WebJobs are pretty much the same thing with a bit more wrangling to get you cheap, unlimited scaling.

In the end, I do believe we are all winners here as it becomes easier to make your on-demand pony sharing service available to everyone faster and cheaper than ever before.

PS — While reading about using AWS Lambda, you may be trading hours spent getting your server or buildpack set up for dealing with language version differences and missing package dependencies.

PPS — Sam Koonenburg wrote up an excellent article “Serverless: The Future of Software Architecture” that has his take on this trend and the architecture of A Cloud Guru.

There is no silver bullet and frankly you probably don’t need one. It is far more important to be able to find the right kind of gun, be able to load the gun and perhaps most importantly, be able to figure out where the werewolf is.

— Matthew Oliphant