Benefits of Serverless

five benefits of infrastructural outsourcing:

Reduced labor cost

Reduced risk

Reduced resource cost

Increased flexibility of scaling

Shorter lead time

Reduced Labor Cost

Serverless was fundamentally about no longer needing to look after your own server processes

you care about your application’s business logic and state, and you let someone else look after whatever else is necessary for those to work.

You’re no longer managing operating systems, patch levels, database version upgrades, etc. If you’re using a BaaS database, message bus, or object store, then congratulations—that’s another piece of infrastructure you’re not operating anymore.

you have less logic to develop yourself.

here all of the HTTP-level request and response processing is done for us by the API Gateway

Deployment with FaaS is easier because we’re just uploading basic code units—zip files of source code in the case of Javascript or Python, and plain JAR files in the case of JVM-based languages. There are no Puppet, Chef, Ansible, or Docker configurations to manage. Other types of operational activity get more simple too, beyond just those we mentioned earlier in this section. For example, since we’re no longer looking after an “always on” server process, we can limit our monitoring to more application-oriented metrics. These are statistics such as execution duration and customer-oriented metrics, rather than free disk space or CPU usage.

Not NoOps

Support, monitoring, deployment, security, and networking are still considerations when building a Serverless app, and while they may require less and/or different work, they do still need to be approached carefully, and with expertise. Serverless is not “NoOps.”

Reduced Risk

A specific example here is managing a distributed NoSQL database. Once such a component is set up, it might be relatively rare that a failure in a node occurs, but when it does, what happens? Does your team have the expertise to quickly and efficiently diagnose, fix, and recover from the problem? Maybe, but oftentimes not. Instead, a team can opt to use a Serverless NoSQL database service, such as Amazon DynamoDB. While outages in DynamoDB do occasionally happen, they are both relatively rare and managed effectively since Amazon has entire teams dedicated to this specific service.

Reduced Resource Cost

Once we’ve figured out planning what hosts or resources we need we can then work on allocation—mapping out which parts of our application are going to run on which resources. And finally, once we’re ready to deploy our application, we need to actually obtain the hosts we wanted—this is provisioning.

This whole process is complicated, and it’s far from an exact science. We very rarely know ahead of time precisely what our resource requirements are, and so we overestimate our plan. This is known as over-provisioning. This is actually the right thing to do—it’s much better to have spare capacity and keep our application operating than for it to fall over under load. And for certain types of components, like databases, it may be hard to scale up later, so we might want to over-provision in anticipation of future load.

Over-provisioning means we’re always paying for the capacity necessary to handle our peak expected load, even when our application isn’t experiencing that load. The extreme case is when our application is sitting idle—at that point in time we’re paying for our servers to be running when in fact they aren’t doing anything useful. But even when our applications are active we don’t want our hosts to be fully utilized. Instead, we want to leave some headroom in order to cope with unexpected spikes in load.

service provide precisely the amount of capacity we need at any point in time

For instance, if our application is only running for 5 minutes of every hour, we only pay for 5 minutes of every hour, not the whole 60 minutes. Further, a good Serverless product will have very precise increments of use; for example, AWS Lambda is charged by the 100 milliseconds of use, 36,000 times more precise than the hourly billing of EC2.

In modern non-Serverless apps, we do see some of these benefits through techniques like auto-scaling; however, these approaches are often not nearly as precise as a Serverless product (see above our point of EC2 charging by the hour), and it’s still typically not possible to auto-scale a non-Serverless database.