FinDev and Serverless Microeconomics: Part 1

by Aleksandar Simovic

Introduction by Mark Schwartz, AWS Enterprise Strategist

In a post a few months ago titled Micro-Optimization: Activity-Based Costing for Digital Services, I pointed out that serverless computing in the cloud raises the possibility for us to optimize our costs at an extremely granular level, the level of individual functions within an application. Essentially, it is a way of doing activity-based costing, where the “activities” are all within a single digital user transaction. Of course, we were always able to find the cost of developing a system in the aggregate and the cost of operating it in the aggregate. But now we can see our operational costs within a single transaction, gaining both the ability to optimize them—which can have a large financial impact at scale—and to gain transparency into customer and transaction profitability.

In that blog post I mentioned some fine work being done in this area by Aleksandar Simovic. In this guest blog post, Aleksandar describes the potential of micro-optimization.

FinDev and Serverless Microeconomics: Part 1

by Aleksandar Simovic

Serverless brings a new economic paradigm in software that helps you better understand your software’s business value, revenue, cost, and the relationships between them on an operation-by-operation basis.

In case you haven’t heard before, serverless is an abstraction level over a company’s IT infrastructure, enabling product and engineering to focus significantly more on delivering software business value. It’s about thinking less about the infrastructure capacity, scaling, and server management, as those are handled “under-the-hood” by AWS. But that’s not the whole story. The real reason that serverless represents such a revolution is the business value it brings, and it is much deeper than what we might initially realize.

At first, serverless does seem to be a simple abstraction extension of the cloud and managed services as we know them today. But beside that abstraction, serverless comes with a powerful “pay-per-use” native business model that can bill consumers precisely by their usage on a digital operation-by-operation basis. While the major serverless cloud providers have not yet introduced the functional billing that will inevitably underpin this system, we can anticipate it and think about its enormous implications. Many of you may have already read about it in one of Mark Schwartz’s, Enterprise Strategist at AWS, posts from his series on finance and IT. If you haven’t read them yet, I encourage you to take a look. Serverless represents not only a revolution in cloud computing, but a revolution in the microeconomics of technology-enabled business itself.

Serverless as a New Economic Paradigm in Software

 First and foremost, the serverless pay-per-use model enables businesses to use activity-based costing on a digital operation-by-operation basis. To explain, think of each digital operation or small component as a “cell of functionality” that interacts with other “cells.” Serverless enables businesses to track the cost of each cell-like service they are using, enabling them to track the combined cost of those cell-like services as transaction costs within their application. Businesses can even track the transaction-per-user cost or even entire software modules.

To demonstrate, 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 customers. The most simple one, a user registration transaction, consists of:

• A user opening your web application and filling in their information.
• Your software processing and storing that user’s information to a database.
• And the software sending an email to confirm the registration.

These are all features within that transaction. Each of these features consists of small cell-like services and associated invisible infrastructure, which combined enable that feature. If we took a look at the feature of “processing and storing user information to a database,” you can see how it consists of smaller components. You can visualize their cost in the following figure.

In the figure, you can see three small cell-like services:

• The first is the entry point for user information, called API Gateway. When information comes, it calls the next processing cell.
• The second’s only duty is to process that information. In the AWS ecosystem, this is called a Lambda.
• The last stores that user information; it is a database service. In this case, its Amazon DynamoDB.

The cost per one million services calls is represented in the red rectangles next to each service. The large red rectangle on the right represents the total feature cost for one million transactions. You can do lots of useful things with that cost information, but hold that thought. When you are able to view cost from a business-type component, you can also look at the revenue and value standpoint of that component, which is even more important.

Almost every transaction within a company brings a certain business value, whether its direct or indirect. From the above transaction example, the value that this transaction brings is a new registered customer. You may think it’s hard to calculate its value—or more precisely, the revenue a new customer brings—but there are simple metrics, such as average revenue-per-customer and even per-customer profit contribution over some time horizon, that can be applied to discover the business value. In the analytics and growth marketing world, such metrics are commonplace today. For the sake of the example, let’s black box the methodology you use to get this number. Let’s assume that this feature’s average revenue is $0.05 per new registered customer. On one million new registered customers, the revenue should be $50,000. By applying those changes and updating the previous figure, the figure should now look like the following.

This updated figure shows both the cost of the customer registration transaction per one million (red rectangles), the revenue it brings (green rectangles), and the profit contribution (dark blue rectangle). Not only that, but you are able to track the operational cost of every cell-like service within that transaction. You can also track how frequently each one of those transactions is used.

This means that you can now better understand, on a marginal basis, the relationship of a given cell-like service or workflow to its cost and value each time it runs. Both figures in this text were made using a capital management tool called capitalflow.ai.

Understanding and calculating that relationship to revenue, cost, and ultimately the business value within applications is also called capital flow management. Serverless brings a number of benefits repeated many times by Simon Wardley, the founder of Wardley Maps, and described by Mark Schwartz in his article on Micro-Optimization and Activity Based Costing.

Managing the capital flow within your software may be crucial for your company’s survival, market share, and may even make the difference between a company that’s barely surviving and a company that comes to dominate the market. Finance and development skills and knowledge, nicknamed FinDev, are necessary to capitalize on this potential. It’s also known as “Worth Based Development,” that is software development driven by its calculated business value or worth.

The complete definition of FinDev is that it represents a set of finance and development practices around serverless and capital flow management, including the consequences of this serverless pay-per-use model and introducing potentially new software financial models.

Introducing the Serverless Pay-Per-Use Variable Business Model

The most interesting impact of serverless and FinDev is also the most unexplored one. The serverless pay-per-use (or pay-per-transaction) model has brought a new operating model—the variable business model effectively enables any business building on top of serverless to apply the same pay-per-use model for its provided software.

For example, a company billing its customers for a monthly subscription could now charge their customers only for the cost of the services they use. That cost would comprise the used service operating costs combined with the related fixed costs of development, maintenance, and the company margin. You could enable your customers to pay only for used services in the same way they paying for used electricity, as a commodity. This variable business model might not be applicable in many cases, but it is definitely an approach worth thinking about.

Imagine yourself as the customer, starting a small business and having access to one of the best CRM applications. Since you’ve just started your business, you’d be paying only $1 a month, as you have just a few or zero clients, instead of paying upfront $15–$20 per user/per month. You would also have access to all of the features, as you aren’t adhering to a pricing plan that provides limited features. How big of a leverage can it be over your competitors?

Of course, this approach isn’t applicable in every case, but there are some where it might be worth looking at, for example if:

• You are an enterprise and are launching new, additional software products in an existing market. You are seeking less business risk while increasing your volume and gaining market share.
• Your company is a small new SaaS entrant without significant assets in an existing market. The variable business model might give you the edge over other entrants. Your margins would be lower because your pricing model would be significantly lower as well. And as operating costs will be variable, you will break even very quickly.

On the other hand, there are many other cases where it isn’t applicable, if you are:

• An existing enterprise with lots of assets, one main software product, and you’re heavily relying on the existing licensing fees or monthly subscriptions.
• You’re building an innovative, new product requiring lots of fixed costs, much higher than the variable ones.
• Your software services are simply support services for your other non-software products
• And, most of the cases where your fixed costs are higher than the variable ones by multiple orders of magnitude.

This variable business model is novel, but it has a potential to flesh out a new generation of asset-light companies built on serverless that might disrupt the markets dominated by fixed-price pricing models or with high licensing fees.

Worth-Driven Outsourcing

Another compelling model of serverless pay-per-use is “worth driven outsourcing.” It was recently mentioned in an interview of Simon Wardley, conducted by Forrest Brazeal:

“Companies building a system for others, for free, but taking a metric of the value they generate.”

Imagine having a great idea for a new software product, but instead of seeking investment for your software development, with long feature delivery cycles, you give a small measurable margin percentage to the company that delivers that software for you in a matter of weeks. Yours and the partner company’s goals align perfectly. Both will seek to increase revenue and increase value with a steady delivery of new features and new customers. Some of you may think that there are already such existing models; unfortunately, operating and development costs were previously mostly semi-variable and fixed, respectively. This has changed with serverless and FinDev, since there is now a direct, calculable relationship between operating costs and revenue.

Worth driven outsourcing is just an example of how the serverless variable business model might impact our traditional software models, even only within IT. 

Conclusion

Serverless does indeed bring a new economic paradigm in software. By helping you better understand the business value, revenue, cost, and the relationships between them, it touches nearly every aspect of the way technology-enabled businesses work.

In the next post we will cover, in detail, the aspects and benefits of going serverless from a company perspective. More specifically, we’ll explore how serverless benefits each of its departments, not only product and engineering, but also finance, accounting, and even business strategy.

*****

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.