Serverless

Executive summary
The next big thing that's been happening since 2011. Manage less infrastructure, less ops and concentrate on your product.

Serverless means no operating systems, no patches, no orchestration and less scaling concern.

Serverless has been available for simple websites since 2011 when amazon announced you could host a website directly on an S3 bucket. This immediately took away the need to deal with virtual machines and operating systems. Suddenly you could deploy a static website to an S3 bucket and it scaled all the way from free to millions of visitors. More recently, the term serverless is being used when moving more complex and interactive applications to a service that elevates you above the tasks of dealing with the OS, patching, or VMs.

A simplified future with concentrated focus on the application layer sounds like a win-win to me.

To adopt serverless, there's a few things you will need to change. No servers means no containers, no os patching/upgrading. No on site staging environments (you have this in cloud already though, right?) and less work for your devops. Serverless technology has limitations that you need to be aware of and some applications cannot yet be migrated. For starters, AWS has a 3GB ceiling on memory usage and a 300 second limit on execution time. This makes it great for web apps, but terrible for long running tasks. Over time, the bar will continue to rise.

Latest industry developments
Feb 2011 AWS announces full static website hosting on S3.Nov 2017 AWS announces the first serverless database service. This takes advantage of AWS Aurora having separate compute and storage layers (really aurora is two services under the hood). You pay for the storage in GB hours and Compute/ram capacity time in per second increments.
Nov 2014 AWS announces lambda. Event driven containers billed per 100ms.
Sep 2016 Microsoft announces Azure Functions to compete with AWS Lambda.
Sep 2016 Google announces Google Cloud Functions to compete with AWS Lambda.
Nov 2016 AWS launches Athena. Run SQL on data stored in S3.
Nov 2017 AWS announces fargate. Manage containers without the orchestration.
Nov 2017 AWS announces the first serverless database service. This takes advantage of AWS Aurora having separate compute and storage layers (really aurora is two services under the hood). You pay for the storage in GB hours and Compute/ram capacity time in per second increments.

Technical FAQ
I don't trust serverless

• If you trust the entire service/supply chain of your chosen cloud provider, one more service in the chain is going to make very little difference to the sum.

Should we use software X to host our own serverless service?

• The main attraction of serverless is not having to worry about the OS layer. This benefit is immediately lost if you pay people to create, maintain and scale a serverless service. Unless your business model is to provide a serverless service to your customers i.e. you are a cloud, please don't do this.

We don't have great test coverage, will this be a problem?

• Yes, and not just for serverless. If you have poor test coverage, the cost of change puts you at a competitive disadvantage.

Our app doesn't work in serverless

• If your app doesn't work in a serverless architecture then it's either very specialised or much more likely, it's a legacy application that needs replacing.

Docker allows us to ship the OS and the app layer as a single immutable deployment. How do we know that our app that is working in dev, will also work in live?
There are a few options here.

1. Run dev, staging and live in the cloud provider. Don't run anything locally. This ensures identical behaviour in those environments.
2. Run just staging and live in the cloud provider. Accept that your local dev environment might pass tests that don't pass when they hit staging.