Serverless: Platform-as-a-Service done right?

about | archive


[ 2016-December-19 09:47 ]

The excitement around "Serverless Architectures" makes me a bit annoyed, but not because it is a bad idea. I think high-level managed services make it faster to deliver working solutions for most applications than managing hardware, VMs, or containers. I’m annoyed because it is hyped as a new concept. It’s not. Serverless is mostly just a new word for Platforms-as-a-Service. The main difference is market timing (and marketing: serverless is a more thought-provoking term than PaaS). Today, building on cloud platforms is normal, and everyone has realized, consciously or not, that they are "locked-in" to their provider. As a result, using a proprietary platform is no longer so scary. This is very different from nine years ago, when Heroku (released November 2007) and Google App Engine (released April 2008) were getting started. At the time, people were afraid of writing apps they couldn’t run anywhere else. Now, since our apps are already trapped on AWS, you might as well take advantage of whatever you can to make it easier.

The one potential technical difference is that Serverless means you don’t need to control the number of instances of an application you are running. In Adrian Cockcroft’s words, "If your PaaS can efficiently start instances in 20ms that run for half a second, then call it serverless." Mike Roberts argues that the definition of a Serverless platforms is one that manages scaling for you. With these definitions, Google App Engine is unquestionably a Serverless platform, as it is capable of rapid automatic scaling, but Heroku may not be. I’d argue that Heroku is close enough: adjusting a slider in a web interface, or executing a command line argument to change the configuration is basically managing scaling. The platform is still handling the mechanics, but is choosing not to make the decision about when to scale.

I've spent the last nine months working on an application that is primarily run on Google App Engine. I have lots of specific complaints about that platform, but it still feels like developing software in the future. We pay a premium for computing resources compared to "bare" VMs or co-location. However, we get a tightly integrated development platform that handles essentials like deployment and rollback, log collection and security. For a huge number of applications, it is simply a waste of time to configure these things yourselves, and using AWS Lambda, Heroku, or App Engine is going to reduce the "time to solution."

There will always be applications, or parts of applications, that consume large amounts of computing resources. For these pieces, a fully managed platform may not be appropriate. In order to implement "magical" scaling, these platforms impose a lot of limits that you may need to work around. Similarly, at a certain scale, the cost premium for computing resources may eventually outweigh the development cost advantage from these platforms. In either of these cases, you will want to move parts of your application to other environments. The good news is that with most of the large cloud providers, there are lots of other options. If you select the APIs you use carefully, it should always be possible to move chunks of your code to a more cost efficient environment.

In conclusion: write your apps using the highest-level platform you can. It will save you time and money. You can even call it serverless if you would like. Please, just don’t call it new.