Serverless Defines the Cost of Operations to Run Software Like a Starbucks
Google’s recent announcement that it was releasing a portable serverless-style scaling solution for containers (CloudRun) provides a missing link between containerized microservices and event-based serverless. Interestingly, though, it also highlights one of the basic value propositions of serverless: serverless applications “scale to zero,” meaning organizations are never paying for unused computing infrastructure.
Serverless functions are only billed for the time they’re running. Serverless storage charges per MB, databases that charge by reading and write request, and messaging services that cost per message. In all these cases, if you aren’t using the service you don’t pay for it, and they all scale in capacity.
Serverless is usually cheaper than buying or renting (cloud) servers which need maintenance, security updates and IT staff overhead, generating costs even when not being used. But it’s not always cheaper, especially if you include all the relevant services (functions, storage, API gateways…)
Very broadly, serverless architectures are usually cheaper for low-utilization workloads, including those that sometimes have big traffic spikes. Traditional server setups are cheaper for constant high utilization without any spikes, especially those that involve high CPU usage and lots of data IO and read/writes. The precise cost calculations are constantly changing, but for now, the broad principle stands. Another confounding variable here is the use of ‘pre-warmers’ that keep serverless functions loaded to prevent cold starts. With pre-warmers, these functions never actually scale to zero.
All this is nice to know, but the conceptual shift that serverless enables is much more than just cost-cutting. There’s nothing inherently revolutionary about cheaper computing. What serverless brings is the ability to attach a real cost to particular software operations.
Business strategy guru Simon Wardley has emphasized how being able to see the cost of operations radically changes the way in which businesses can think about software development.
Big, successful businesses know the cost of every aspect of their operations. Starbucks knows the cost to buy, ship and roast the coffee; it knows the cost of running each shop from rent to electricity to free WiFi. It knows the staffing costs and how much the milk and the paper cup contribute. In this way, Starbucks knows exactly how much a double espresso costs to make in New York City, Helsinki or Phnom Penh, and how much extra it costs to make a soy vanilla latte. On the one hand, this allows the company to set prices that account for real and marginal costs. Equally, it shows where processes can be improved or optimized to reduce costs.
Serverless brings this sort of supply-chain analysis to software. A company using serverless can know exactly how much it costs them when a customer sends a photo to their friends or asks a digital assistant to check the weather. Perhaps this explains why Starbucks itself was an early adopter of serverless!
Refactoring Will Have Financial Value
This quote from Simon Wardley captures one immediate consequence. A company can attach a real cost to, say, optimizing a particular function to make it faster or less memory-intensive.
Seeing that refactoring a function could save $5000 a month, a company could choose to prioritize that work. In extreme cases, a single badly-written piece of code could be contributing a big percentage of the total cloud computing bill.
On the other hand, once you know a function costs just $3 a month for a million executions, then spending two days of expensive developer time refactoring to get that cost down to $2 might never be worthwhile.
Intelligent Pricing Becomes Possible
Once a company can really see the costs of its software, all sorts of interesting pricing models become possible for consumers, too. Perhaps some customers use an app for loads of (cheap) photo sharing, while a small minority use that same app for (expensive) image enhancement and processing. There could be a business case for making image enhancement into a premium feature or releasing a free version of the app with only photo-sharing.
Another model could be fixed-margin use, where the real cost of a particular software operation is calculated and then end-users are charged whatever it costs plus a fixed $.02 markup per action.
Development, Operations and ‘the Business’
In order for companies to take full advantage of the powerful business uses of serverless, they’ll have to change. The DevOps revolution of the last decade has broken down the barriers between software developers who create software and new features, and IT Operations who keep the software running. In some ways, it was the shift to microservices that enabled DevOps, allowing interdisciplinary teams that jointly write and operate software components.
The move to serverless offers a new model, that Simon Wardley calls “FinDev”. This model acknowledges that development decisions are ultimately financial decisions. It includes people from the finance side inside developer/DevOps teams, able to help guide these decisions and factor them into broader business strategy.
FinDev will grow with serverless, though it will take time for companies to adapt their own structures to this new technology. Eventually, a sort of inverse Conway’s Law will force serverless companies to adapt to match the structure of their tech. Just as microservice infrastructures broke down developer and IT silos, serverless will break down the artificial division between the technical staff and “the business.” Perhaps that change will be the true serverless revolution.
Feature image by Dénnis Kendall from Pixabay.