The first edition was published in 2020, and with the pace of change being as brutal and unforgiving as it is, I started making notes for the second edition within a month of finishing the manuscript. The overall structure has remained the same, but I go far deeper into the different topics in the 2nd edition. There are also more visuals and a couple of new topics. This series of articles provides a summary of each of the chapters with some personal afterthoughts. Serverless Beyond the Buzzword 2nd edition can be purchased here: https://link.springer.com/book/10.1007/978-1-4842-8761-3
Written article continues below the video
Chapter 3 starts with a Total Cost of Ownership and covers why this is an important tool for a fair comparison between different architectures. It includes both short-term/one-off costs and long-term/recurring costs, providing a multi-year view of the total cost of a given application. When comparing server-based applications, which typically have low up-front cost but high recurring cost, with serverless applications, which typically have a high up-front cost but low recurring cost, this total view over multiple years is key to ensuring a fair comparison.
The research from the first edition about the cost of developing serverless has been included again, with some minor updates, though the comparison is still valid today. Quality Serverless development remains slightly more expensive, both with vendors and when hiring talent, especially in the enterprise space where Serverless is still rare.
Serverless operational cost estimation
Like the first edition, a big part of this chapter is about estimating the operational cost of serverless applications, which remains a challenge for many. In this second edition, I delve much deeper into this topic with more examples and background. Estimating cloud operational cost is a challenge soon encountered when considering or experimenting with Serverless architecture for projects. The many components in Serverless architecture are far more complex to estimate than a few application servers. However, with the right input data, Serverless estimates can be considerably more accurate and even include per-user granularity.
For accurate estimates, there are three categories of parameters that need to be collected for an application.
Business parameters
The product owner or similar business role typically provides business parameters. They can be defined based on statistics from existing applications or market research. The main difference with Serverless is that details are far more important. A simple ‘total expected users’ is usually insufficient to get accurate estimates; instead, we need to create personas of the different types of users and their behaviour and establish the ratio between those types.
Technical parameters
The application team provides the technical parameters. This can be difficult, especially for teams with limited Serverless experience. It can also be challenging to establish technical parameters when it’s still early in the project timeline and when there are no detailed requirements available yet. Three approaches can be taken to find the technical parameters, ranging from low-effort–low-accuracy to high-effort–high-accuracy.
Option 1 is to have reference architectures similar to the planned application that can be used to determine the most likely parameters to include. Such architectures may be found internally if Serverless projects have been delivered in the past or externally from public sources, AWS, or cloud consultants.
In Option 2, experienced teams can usually mock up a quick high-level architecture based on a limited project description. This should be sufficient to provide the technical inputs needed for an approximate initial estimate.
Option 3 concerns less experienced teams or highly complex applications. In this case, it will be unavoidable to first design the detailed architecture diagram. This can be a time-consuming process, including creating proof of concepts if any of the requirements are unclear.
Once the technical parameters are identified, we link the persona behaviours to the parameters to determine the most likely values.
Pricing parameters
The last parameter type is pricing. Documented on the cloud provider’s service pages or provided by their pricing API, these parameters are relatively easy to find once the relevant technical parameters have been identified.
It is important to note any free tiers mentioned on the pricing pages. Free tiers can apply either to all accounts or just to new ones for up to 1 year. For example, many services include some free storage or requests before they start billing. It is not uncommon for these free tiers to cancel out most or even all of the cloud bill in the early days of a new application.
Cost management and optimisation
Two other big topics for this chapter are about managing costs effectively and cost optimisation. AWS provides a suite of cost management services that can help us organise and track cost and usage data, enhance control through consolidated billing and access permission, enable better planning through budgeting and forecasts, and further reduce cost with resource and pricing optimisations.
Where Serverless is concerned, there are two key services where we should start optimising cost: the storage service S3 and our microservices host, Lambda. With services such as DynamoDB, there is a consideration as to which billing model to pick and where the break-even point is.
For S3, clearly understanding the different storage classes will help decide on the right one for the data.
For Lambda, memory rightsizing is important to manage cost and performance. To do so, the application team should monitor the published CloudWatch metrics to understand the usage pattern of the microservice and ensure that it is not underutilised. A common misconception is that having a lower memory configuration always results in a lower cost, but this is not always true. The memory configuration and the execution time determine the cost of a Lambda microservice. Having more memory could reduce execution time, potentially providing better performance at the same or lower cost.
Check out the book's mini site for more information and ordering here: https://serverlessbook.co