User:Shawndouglas/sandbox/sublevel45

As a service model, platform as a service or PaaS uses both the infrastructure layer and the platform layer of cloud computing. Hosted on the infrastructure are platform components like development tools, operating systems, database management tools, middleware, and more, which are useful for application design, development, testing, and deployment, as well as web service integration, database integration, state management, application versioning, and application instrumentation. In that regard, the user of the PaaS need not think about the backend processes.

Similarly, serverless computing or FaaS largely abstracts away (think "out of sight, out of mind") the servers running any software or code the user chooses to run on the cloud provider's infrastructure. The user practically doesn't need to know anything about the underlying hardware and operating system, or how that hardware and software handles the computational load of running your software or code, as the cloud provider ends up completely responsible for that. However, this is where the similarities stop.

Let's use Amazon's AWS Lambda serverless computing service as an example for comparison with PaaS. Imagine you have some code you want performed on your website when an internet of things (IoT) device in the field takes a reading for your environmental laboratory. From your AWS Lambda account, you can "stage and invoke" the code you've written (it can be in any programming language) "from within one of the support languages in the AWS Lambda runtime environment." In turn, that runtime environment runs on top of Amazon Linux 2, an Amazon-developed version of Red Hat Enterprise running as a Linux server operating system. This can then be packaged into a container image that runs on Amazon's servers. When a designated event occurs (in this example, the internet-connected device taking a reading), a message is communicated—typically via an API—to the serverless code, which is then triggered, and Amazon Lambda provisions only the necessary resources to see the code to completion. Then the AWS server spins down those resources afterwards. Yes, there are servers still involved, but the critical point is the customer need only to properly package their code up, without any concern whatsoever of how the AWS server manages its use and performance. In that regard, the code is said to be run in a "serverless" fashion, not because the servers aren't involved but because the code developer is effectively abstracted from the servers running and managing the code; the developer is left to only worry about the code itself.

PaaS is not serverless, however. First, a truly serverless model is significantly different in its scalability. The serverless model is meant to instantly provide computing resources based upon a "trigger" or programmed element, and then wind down those resources. This is perfect for the environmental lab wanting to upload remote sensor data to the cloud after each collection time; only the resources required for performing the action to completion are required, minimizing cost. However, this doesn't work well for a PaaS solution, which doesn't scale up automatically unless specifically programmed to. Sure, the developer using PaaS has more control over the development environment, but resources must be scaled up manually and left continuously running, making it less agile than serverless. This makes PaaS more suitable for more prescriptive and deliberate application development, though its usage-based pricing is a bit less precise than serverless. Additionally, serverless models aren't typically offered with development tools, as usually is the case with PaaS, so the serverless code developer must turn to their own development tools.