In this excerpt from Serverless as a Game Changer, you will learn several different definitions of the term Serverless, from its use in generating business value to its technical criteria.
The term Serverless describes a way to develop, build, deliver, and maintain software. Many people hate the term, for various reasons. There are, of course, still servers somewhere, much as there are still wires involved when you use wireless technology. Furthermore, most original Serverless applications used a very narrow set of the full range of Serverless tools—Functions as a Service—so that original narrow view has incorrectly carried into many people's current understandings of Serverless. Ultimately, the term itself is fine, but different people learn different ways; the book thus presents several different definitions of Serverless, from strategic to technically detailed, so that all readers can pick their own preferred choice.
Serverless Is a Focus on Business Value
Ben Kehoe, an AWS Serverless Hero and formerly a cloud robotics research scientist at iRobot, writes and speaks about the Serverless Mindset, which he summarizes in this way:
"Serverless is a way to focus on business value.
How [does writing Serverless applications] help you deliver value? [It] lets you focus on writing business logic, not coding supporting infrastructure for your business logic.
Managed services let you focus on writing your functions. Having [fewer] operations resources frees up people and money to be applied to creating new value for your customers.
You should go Serverless because you want to focus on creating value—and at your company, you endeavor to apply technology toward the creation of business value."
Ben's definition is a nice addition to the first two because it supplies the motivation for Serverless. In building a Serverless application, the outcome should be a much greater focus on business value and a reduction in distractions (especially undifferentiated heavy lifting). The Serverless Mindset, as he describes it, is one that is constantly seeking for ways to increase focus on what matters.
Serverless Means Not Our Uptime
One of the simplest definitions of Serverless, and the principal way I think about fully Serverless applications, is that the responsibility for keeping applications running is not the responsibility of the organization that developed the applications. Managed service providers handle all infrastructure, operating system, and system software planning, procurement, deployment, patching, failover, and scaling. An organization develops and configures its application and then provides the necessary code, binaries, and configuration to managed service providers to handle everything else.
Note that standard cloud Infrastructure-as-a-Service (IaaS) and Platform-as-a-Service (PaaS) services are not Serverless by the "not our uptime" definition because organizations have to own failure scenarios with those cloud infrastructure options. For example, even managed database services that have some level of automated failover don't have ways of automatically handling problems from running out of disk space or being overwhelmed by too much traffic. One good way to tell whether an organization is still responsible for some uptime is to walk through disaster recovery and business continuity plans and see where technical skills are required; anything that involves DNS, load balancers, or run books indicates that an essential part of uptime is still managed within the organization.
Sometimes executives think about Serverless as being just one step further on a path to outsource more to managed-service providers. To some extent, this is true, but Serverless is also the last step, and that is significant.
Think about vaccinations as an approach to mitigating disease risk: Perhaps being vaccinated in round 1 reduces the risk of contracting a particular disease from a 2% likelihood to a 1% likelihood. Now contrast that with how you would feel if you could further take that risk from 1% to 0% with perhaps a second round of vaccination, and you get a sense of how Serverless differs from the cloud outsourcing that came before it. In both the 2–1% reduction and 1–0% reduction, exactly the same absolute risk reduction is achieved. But after the second step, you are freed in a way that you never were before, to the point that you no longer face any risk of getting the disease. In the case of Serverless, the "disease" is having to maintain skills and staff to handle infrastructure management, including continuous monitoring and failure handling, which are all now undifferentiated tasks.
One of the simplest examples of a Serverless application from a "not our uptime" perspective is any store built on Shopify (which, as with major cloud providers, does not run on a Serverless architecture but enables others to run Serverlessly). Shopify allows anyone to build a complete, customized e-commerce web application that Shopify runs entirely. A much more complex one is the software that runs the full-stack insurance company Branch; it is explained in detail in Chapter 5, "Introducing Branch."