FinDev and Serverless Microeconomics: Part 2 – Impacts

By Aleksandar Simovic

Introduction by Mark Schwartz

Serverless computing (for example, the capabilities offered by AWS Lambda) is not just a new technology. Its implications—not yet widely understood—include a deep impact on enterprise strategy. Essentially, serverless computing completes the transformation of IT platforms to a utility, something like electricity: whenever you need a little bit of “compute,” you use what you need and pay only for what you used. “Compute” power is omnipresent, available to you whenever you need it. When electric power became available through standardized wall outlets it made possible all of the innovation we have seen in electrical appliances. Now that computing is available in a similar on-off model, who can even foresee the implications?

In this follow-up to his previous blog post FinDev and Serverless Microeconomics: Part 1, Aleksandar Simovic elaborates on some of the consequences serverless computing will have on business models and strategy.

Mark

FinDev and Serverless Microeconomics: Part 2 – Impacts

By Aleksandar Simovic

In my previous post I covered how serverless is changing the financial model—with a new combination of financial and development skills appearing, called FinDev—and why it all matters. The game changer is the serverless pay-per-use business model and its transformational impacts, which are enabling any company to adopt the same variable business model and also introducing new financial models built on top, such as the “worth-driven outsourcing”.

Even though initially serverless seems to be a technical change, it doesn’t only impact the product and engineering departments, but also finance and accounting. And it can significantly affect certain strategic business decisions.

To keep this post brief, I’ll only cover the most important implications of going serverless in the next few sections, classified by department. I’ll start with the changes to finance and accounting, as a continuation from the previous post.

1. Finance and Accounting

The big picture here is that serverless will switch your software operating costs from fixed to variable. This is the natural extension of cloud computing, where the infrastructure layer first made the jump from fixed to variable. Now, that same dynamic is playing out, up higher, with the software operations layer, enabling your software operating cost to be completely variable. This was first mentioned to me a few years ago by Gojko Adzic—the author of Specification by Example and Impact Mapping. Gojko argues that when talking about the impact of serverless, the impact most people miss is the change of variability of software operating cost. Consequently, there are several important implications for finance that result from this change.

Better Understanding of Business Value and Profitability for Transactions and Features

With serverless and FinDev, businesses are gaining insight into the financial specifics of each transaction and feature. Understanding a transaction’s revenue, cost, and their relationship helps businesses understand how profitable and, consequently, how valuable that feature is to your customers. You can then combine this information with how often the feature is used to learn how that feature and those transactions are relative to your overall operating costs and revenue. Then you’re able to make appropriate decisions regarding which transaction the business should invest in, or, even better, which one you should eliminate.

Minimizing Business Risk

If you’re not familiar, one of the ways to ascertain the degree of business risk within a company, also known as operational risk, is by calculating the degree of operating leverage (or DOL, in short). The DOL helps us determine how changes in the sales volume impact company profits,  or simpler, the ratio of fixed to variable costs. The higher the DOL, the more your profits are reliant upon fixed costs and the risker the company is, and vice versa. As the cost switch moves a significant portion of previously fixed costs to variable ones, the business risk decreases, both on paper (by recalculating the DOL) and in reality (less fixed cost and less waste). You can read more about operating leverage and its value in anticipating changes in earnings in a published research paper by Credit Suisse.

Lowering the Break-Even Point

As costs become more variable, your company’s break-even point lowers too! Simply, serverless companies are more likely to be profitable and sustainable than traditional non-serverless ones. A recent study by IDC on “Generating Value Through IT Agility and Business Scalability with AWS Serverless” has shown that the business impact of serverless has lowered five-year operating costs by 60% and includes an average 409% five year ROI.

Forecasting Revenue and Cost on a Transaction and Feature Level

With cost, revenue, and profitability numbers for each feature and transaction, you can easily forecast their future values and rate of growth. This allows you to anticipate future change and understand what area of your business is growing. You will also be able to focus on a transaction that will see a substantial increase in value and usage, hire more people for it, and fulfill all of your customers’ expectations. While you’re at it, you can even start using the recently announced Amazon Forecast for predicting future feature profitability.

Understand the Profitability per Customer

Gaining insight on cost and revenue is not limited to transactions or features. Since serverless bills on a digital operation-by-operation level, you can also track both of those values for each customer. This brings quite a number of possible analytics to mind, but with customer segmentation, you will be able to precisely understand which customer type is the most profitable and know the profitability per feature per customer type. Cross analyze that with feature usage information and you will know which feature is being used the most by which customer type.

Optimizing Underperforming Features and Transactions

By combining segmented customer churn rate with how often a feature is used and its profitability, you can also understand what features are failing to serve your customers and gain evidence on the source of their underperformance. You will know which transaction you should be fixing in order to reduce customer churn and you will understand which features and transactions are the cause of underserved customer needs.

Minimizing Idle Capacity Cost and Cost Remanence

Another impact is that the serverless pay-per-use model significantly reduces the idle capacity cost from your budget. Previously, especially with company-owned datacenters, each machine could only handle a specific volume. You had to plan capacity upfront, have a certain amount above the expected usage available, and increase or decrease your capacity by following your business activity — calculated as step costs. In the past, businesses always had to accept a certain amount of loss, amounting to the difference between the provisioned and used capacity. Let’s look at a simplified example of a single server capacity, usage and their relationship. The  following chart represents a very simplified view on capacity planning and expected usage of one server for a duration of one day.

If we simply reverse the chart, the idle capacity represents its incurred loss.

Serverless pay-per-use model changes this graph, as the cost strictly follows your usage.

Minimizing Remanence Costs

The serverless pay-per-use approach also tackles a specific characteristic of capacity costs: cost remanence. Whenever your software services experience a slowdown or a reduced activity (summer holidays, for instance) the provisioned server capacity would remain the same for a brief period of time before your DevOps team downsized it to the estimated need. The cost difference between the previous and the actual planned capacity represents the trait called cost remanence.

Below are example graphs of two companies experiencing a slowdown: one displaying the cost remanence of services operating on company-owned datacenters, and the other showing the cost remanence of services operating on serverless. The graphs’ y-axes represent costs (in dollars), while the x-axes represents duration (in number of days) in the situation of a reduced service workload.

The first graph represents the movement of actual and remnant costs in the case of a company-owned datacenter.

This next graph represents the movement of actual costs and cost remanence in the case of services operating on serverless.

Consider the absurd difference between the remnant costs in the case of services operating on serverless versus the services operating on company-owned datacenters. The difference lies in the way serverless operates, as it provides the ability to almost immediately identify when certain resources are not being used, allowing you to shut them down.

2. Product and Engineering

Increasing the Speed of Delivery, Quicker Time to Market

 One of the most obvious benefits of serverless from an engineering point-of-view is that your development department will no longer be spending time on operational tasks (like setting up your infrastructure to run your software); instead, they can focus their attention on delivering your core business value.

Since the majority of development operations are run “under-the-hood” by AWS, your engineering department will be able to focus on the business logic, and will be able to deliver features faster, reducing your time to market. Consider the cost of capacity planning, resources, infrastructure set-up, and developer time required to deploy software. In most cases, the biggest cost is the time spent by your developers to deploy software and the opportunity cost of those developers not working on your core business logic. Serverless significantly shifts the focus of your product and engineering departments to solving your core business.

Spurring Innovation and Experimentation

First cars were used mainly to transport people and goods from one place to another. As they became more affordable and commoditized, people started experimenting and using them for more tasks, including plowing fields, leading to the invention of the first tractor by John Froelich. What is interesting here is, as steam and gas engines became more available, and people didn’t have to construct them from scratch, some people started experimenting and trying to use the engines to solve other potential use cases, leading to new inventions that we rely on even today.

Going back to serverless, beside the benefits of increased speed of delivery (of your core business logic), its complete and managed services also provide engineering and product departments the ability to experiment more and faster, because they no longer need to construct such services from scratch. Enabling product and engineering departments of technology-enabled businesses to try and discover their potential future sources of worth increasing their competitiveness in the market.

Deciding What to Optimize

Another interesting implication of serverless for product and engineering departments is that with the pay-per-use model your service efficiency directly influences your service operating cost. If your services are not efficient enough, they will cost you proportionally more; vice versa, efficient services will be more profitable for your business.

What this means is that your engineering department’s decision to optimize and restructure a transaction is now measurable and has a financial incentive! Before, you could only make a choice to optimize a certain transaction if there were obvious performance issues or by simply trusting your technical officers. This notion was stated hundreds of times by Simon Wardley, author of Wardley Maps and a researcher at Leading Edge Forum.

To demonstrate what this means, let’s take an overly simplistic example of a single transaction occurring one million times on a daily basis. (A transaction is a combination of several smaller features delivering business value to your customer.) Due to one inefficient feature, this transaction is costing you an extra $0.0001. One hundredth of a cent. Ridiculously cheap, right? Though cost-wise that inefficiency is $1,000 dollars lost, daily. (It’s important to state that there can be many such transactions across your company’s systems amounting to a rather big number).

Some may think “Well, in that case, why not optimize this transaction?” And that would be a good reaction, but that decision has a cost on its own: an opportunity cost, that it might be better for you to work on a new feature for your customers or execute another business activity that brings more value to your business. You will need to properly measure both alternatives and make a good call, but this brings us back to the point that with serverless you’re now able to do transparent activity-based costing. Enabling you to assign costs to these “build a new feature” versus “optimize and reduce technical debt” decisions (also known as “Build versus Refactor”) — enabling all company divisions to be equal partners when making them.

Assigning Revenue, Operating, and Development Costs to the Team Responsible for the Feature

Currently, product and engineering departments are, at most, aware of their development costs. With the serverless pay-per-use model, you will be able to also assign operating costs and, most importantly, the revenue and profitability of features, bringing more ownership, responsibility, and business value transparency to your product and engineering teams.

Determining Time per Request or “What are Your Company Bottlenecks?”

Beside tracking your costs in a pay-per-use manner, there is another valuable metric worth tracking: “time-per-request.” This dimension can show time and cost bottlenecks in your transactions that are impacting you and your customer. If you’re interested in this, there are already tools like Epsagon that are able to give you transaction-wise time.

Discovering and really understanding your bottlenecks requires much more than one paragraph or even an blog post, so I would recommend a rather old book: The Goal: A Process of Ongoing Improvement by Eliyahu Goldratt and Jeff Cox.

3. Strategy

Making Sense of Build versus Buy

Whether to build your own or buy an off-the-shelf product is another topic of on-going heated discussions. With the serverless model, being able to track business value, revenue, and costs on a transaction level gives you transparency when deciding if you should build a feature in-house or out-source it. It will provide a proper comparison of:

• development costs of building a feature or application service with your in-house team,
• the future service revenue and its operating cost,
• the opportunity cost of building another feature that might bring more value,

versus:

• the costs of a third-party product or out-sourcing it to an external provider, along with its future licensing and operating costs and revenue

There’s much more to this comparison. If you’re interested to learn more, I would really recommend a great video “Mapping Your Stack” by Adrian Cockroft, VP of Cloud Architecture Strategy at AWS.

Lowering Startup Costs

If your company is in a startup phase, making a strategic decision to utilize serverless enables your company services to operate on almost zero operating costs until you acquire a certain number of customers. That is because many of the major serverless platforms provide a significant “Free Tier” for their services, where you’re able to use their serverless services free of charge up to a certain number. In recent encounters with startups embracing serverless, the ability to start with zero operating costs is of immense value. Not only is going serverless removing the needed work on software operations, scaling, and planning capacity, it is actually enabling them to focus more on the new business value they want to provide.

Conclusion

All of serverless’s implications can be summarized by stating that serverless is bringing business value back into the focus of software. Serverless is indeed much more than a simple “abstraction level over a company’s IT infrastructure with an increased speed of delivery.” It’s the focus on business value, the serverless pay-per-use business model, FinDev practices, “Build vs Outsource,” “Build vs Optimize,” lower business risk, and a lower break-even point, along with the variable business model, that might change the tide of business software.

I shall finish this short series with a “less is more” wordplay that I heard from Rebecca Marshburn, the Senior Product Marketing Manager for Serverless at AWS.

“Serverless is more.”

Thank you!

If you are interested in learning or reading more on this topic, either by going in depth on each of these implications of serverless microeconomics or writing about the ones not mentioned here, please contact Mark Schwartz or Aleksandar Simovic.

*****

Aleksandar Simovic is a senior software engineer at ScienceExchange and one of the authors of “Serverless Applications with Node.js.” If you’d like to learn more about capitalflow.ai, contact him at alexander.simovic@gmail.com.