Web Applications Without Web Servers

Back in the 80’s, Fred Brooks wrote a wonderful paper “No Silver Bullet: Essence and Accident in Software Engineering”. Every software developer should read it, but not before you finish this essay, so I’m going to summarize: “The best way to improve programmer productivity is not to do things someone else can do for you.”

We’ve gone from owned servers in owned air-conditioned aquaria to virtual server images: we turn all the hardware over to companies like Amazon and Google. Similarly, we’ve moved from handwritten applications behind web servers to frameworks like Django and Ruby on Rails and JavaScript frameworks in the browser: we turn the common parts of all web applications over to the frameworks.

Until recently, though, even with cloud-based applications we’ve looked at the world in terms of servers that we managed more or less the same way we always have, even if they were now virtual machines running in Seattle or Mountain View.

The next step is “FaaS” — Function as a Service, for example with Amazon Lambda or Microsoft Azure’s Functions. You don’t manage, or pay for, even those virtual machines — instead, you provide code to perform your business functions and your provider launches that code for you, only charging you for the resources you use while it’s running.

In general, the basic requirement for this code is that it be ReSTful: it exposes its functions to the world through the HTTP(S) protocol, and it doesn’t preserve any session state between invocations. Web applications based on using FaaS are called serverless — which can be confusing, since there certainly are servers involved. The difference is, they’re someone else’s servers.

Serverless applications depend on what can be called the JAM stack: JavaScript, APIs, and static Markup. A sequence diagram for a serverless JAM application might look like this:

Pre-generated HTML, CSS, and Javascript are bundled as static files that can be stored on a cloud storage site or on a content-delivery network. When a user directs a browser to the URL, the bundle is delivered into the browser, and browser-side JavaScript takes control, and then interacts directly with FaaS services, like Auth0 for authentication, Amazon Lambdas for computation, or web-accessible databases like Amazon DynamoDB or mLab’sMongoDB instances. There is no longer a central server mediating the operations at all.

For the developer, this means not needing to write back-end code that is mere infrastructure so your functions can operate. It’s all still there, but it’s all someone else’s code. For the business, it means that the business only pays for the developer effort to build the pieces specific to the application, and it means only paying for the resources needed while the application is using them. Amazon has examples in which computation costs are reduced by 95 percent over maintaining an EC2 instance.

For a small business or startup, the advantage can be even greater, because Amazon will provide a significant amount of Lambda utilization for free.

The real advantage, however, beyond lower costs and less effort, is that you get much more business value delivered per development dollar. You’re letting Amazon, or Azure, or Google, or whoever do what they do best, while you concentrate on what only you can do: your application.