When talking about containers, most of us already know how to pack an application into a container as a deployment unit. Docker allows us to deploy applications in its de facto standard format to virtually everywhere, ranging from our laptop, a QA cluster, a customer site, or a public cloud, as shown in the following diagram:
Running Docker containers on public clouds is considered normal these days. We have already gained benefits such as starting cloud instances on demand with pay-as-you-go billing. Without the need to wait for hardware purchase, we can also move faster using an Agile method with a continuous delivery pipeline to optimize our resources.
According to a Docker report, the total cost of ownership (TCO) of one of their customers was cut by 66% when using Docker to migrate existing applications to the cloud. Not only can the TCO be dramatically reduced, the companies using Docker can also accelerate the time to market from months to days. This is a huge win.
Deploying containers to cloud infrastructures, such as AWS, Google Cloud, or Microsoft Azure, already makes things simpler. Cloud infrastructures eliminate the need for organizations to buy their own hardware and to have a dedicated team for maintaining it.
However, organizations still require the role, such as that of the architect, to take care of site reliability and scalability even when they use the public cloud infrastructure. Some of these people are known as SREs, the site reliability engineers.
In addition, organizations also need to take care of system-level packages and dependencies. They need to perform patching for application security and the OS kernel on their own because the software stack will be constantly changing. In many scenarios, the team in these organizations must scale the size of their clusters to unexpectedly serve requests when loads are peaking. Also, the engineers need to do their best to scale the clusters down, when possible, so as to reduce the cloud costs as it is a pay-as-you-go model.
Developers and engineering teams always work hard to deliver great user experience and site availability. While doing that, over provisioning on-demand instances or under utilizing them, can be costly. According to an AWS white paper, https://d0.awsstatic.com/whitepapers/optimizing-enterprise-economics-serverless-architectures.pdf, the amount of underutilized instances is as much as 85% of the provisioned machines.
Serverless computing platforms, such as AWS Lambda, Google Cloud Functions, Azure Functions, and IBM Cloud Functions, are designed to address these overprovisioning and underutilization problems.
The following topics will be covered in this chapter:
- Serverless
- The common architecture of a serverless FaaS
- Serverless/FaaS use cases
- Hello world, the FaaS/Docker way
