Defining Serverless
This is the second in a multi-part overview of serverless and native cloud technologies for beginners. This series looks at the origins of the PAAS model, at what defines serverless, what you can build with it, and what benefits it offers.
The first post in this series outlined the PAAS model in broad strokes. In this second post we're going to drill into what specifically defines "serverless" services.
The Key Serverless Features
To start, let's itemize the key features that we're looking for in a service to consider it to be serverless. First, obviously, we expect serverless technologies to abstract away the underlying layers of infrastructure on which they run. These layers include system and application software, server hardware, and networking. We also expect them to (mostly, as we'll get into below) shield you from their implementation details.
Second, we expect serverless technologies to offer the option to pay for usage rather than capacity. Of course, cloud services of all kinds are generally elastic, meaning that for low-volume scenarios they can be scaled down to some minimum size. But large-scale solutions built on serverless have essentially no minimum provisioned capacity, making them almost free to deploy for development or test environments.
Lastly, we expect serverless technologies to be native to their cloud platforms. Currently, the price paid for being native is that these are almost always proprietary technologies. So you need to structure your solutions to mitigate against lock-in (a topic that's covered in detail here). The benefit of being native, however, is that serverless services are full participants in their hosting cloud ecosystems.
To illustrate, let's say you're thinking about incorporating a third-party identity service such as Okta in an AWS-hosted cloud solution. In a number of ways Okta is a more full-featured product than the native Cognito identity service provided by AWS. However, unlike Okta, with Cognito you can define your resources in detail in native CloudFormation build templates. As a result, your identity service can be included as an integral part of your solution. With a third-party service like Okta, you would have to incorporate a separate deployment process to run alongside the main one. Sticking with native cloud services simplifies the deployment and monitoring parts of your solutions.
To summarize, the key features that matter with serverless technologies are:
- They abstract away the underlying infrastructure.
- They support usage-based pricing.
- They run natively in its cloud environment.
The Catalog of Serverless Building Blocks
If you look at the range of services available on the major cloud providers, you'll find that the services in these categories incorporate these serverless features:
- API management services that bridge application frontends and backends, with support for identity service integration and use of OpenAPI definitions.
- Identity services that act as providers for internal users and brokers for external users, with support for OAuth 2.0 flows and OIDC- and SAML-based federation.
- Compute services for stateless request/response functions and for container hosting.
- SQL and NoSQL database services.
- Integration services equivalent to those available in traditional middleware, such as messaging, event-routing, and orchestration.
- Object storage, with support for identity service integration, and features like versioning.
This is not, mind you, an exhaustive list of native services available in the cloud. There are also services for running build pipelines, for performing data analytics and AI-based services for things like translation. But this is the catalog of services that gives you the building blocks you need for building software solutions.
The Exception Cases
Most serverless services fully meet this criteria, but there are some exceptions that are important to understand.
First, both functions and NoSQL database services have specific limitations that are a product of how they're implemented. With functions, for example, compute resources are allocated dynamically as requests are processed, and then cached for some period thereafter. As a result, used out-of-the-box, functions have an inherent issue with cold starts. As I cover in the Learning AWS Serverless course, there are techniques to mitigate this, or you can eliminate the problem entirely by provisioning capacity. But it is something you have to take into account when using this technology.
Similarly, serverless NoSQL databases achieve their high performance by dynamically partitioning and distributing their storage and compute loads across multiple nodes. This partitioning process is dependent on the distribution of table key values stored in your tables for effective hashing. The distributed nature of the service also means that by default data updates take time to propagate across all the nodes, making the data "eventually" consistent. So, once again, these are things that you need to understand and take into account when designing solutions.
Managed container hosting is another exception case, at least in the form provided by the Fargate option with the AWS Elastic Container Service. The Fargate option does spare you the task of setting up servers, and subsequently doing things like applying security updates. But unlike most serverless services, with ECS you do have to set up a fair amount of network and autoscaling infrastructure. Managed container hosting on AWS and Azure both also require the provisioning of a minimum level of capacity. So although this capacity can be scaled down when inactive, there is a minimum cost to a deployment that isn't the case with the fully serverless services on our list.
Another set of exception cases are the restrictions in the native deployment tools that exist for some services, such as for the identity services on both AWS and Azure. With AWS Cognito there are some properties, such as the case-sensitivity of user names, that can't be updated once deployed. This limits your ability to perform updates in place, either manually, or using CloudFormation templates. With Azure AD B2C, the service doesn't support the use of native deployment tools, like Bicep, for updates at all. So in this case, changes to an already deployed tenant have to be performed manually in the web portal.
Finally, Azure sometimes uses premium tiers to unlock advanced features on services. This applies to the de-duplication feature for Service Bus messaging, for example. This means that, effectively, you have a fixed cost for these features rather than one that's tied only to usage, making the deployment of low-volume environments slightly more expensive.
What this all Means
When you zoom out and look at the big picture, you can see how the PAAS model and its associated serverless and native cloud services are a big part of the future of software development.
Having said that, this is still the world of software, where there are no silver bullets. So there are some caveats, as outlined, about which you need to be aware. The key serverless features, like simplified deployment and usage pricing, provide a lot of benefits. But, these are still technologies that require skill and knowledge to properly use.