Usage Based Pricing For Code Execution
I’ve been thinking about Amazon’s Lambda service which I mentioned in the Hacking Echo post last week. Lambda is not new, but last week was the first time I saw it in action. I need to see things in action to understand them.
Business model innovation is interesting to me, maybe more than technology innovation. Because new business models open up new use cases and new markets. And new markets create a lot of new value. And I am in the new value business.
Think about this value proposition:
AWS Lambda lets you run code without provisioning or managing servers. You pay only for the compute time you consume – there is no charge when your code is not running. With Lambda, you can run code for virtually any type of application or backend service – all with zero administration. Just upload your code and Lambda takes care of everything required to run and scale your code with high availability. You can set up your code to automatically trigger from other AWS services or call it directly from any web or mobile app.
“You pay only for the compute time you consume, there is no charge when your code is not running”
So we have gone from “you have to buy a server, put it in a rack, connect it to the internet, and manage it” to “you can run your code on a server in the cloud” to “you can run your code on a shared server in the cloud” to “you can pay for code execution as you use it”. And we have done that in something like ten years, maybe less. That’s a crazy reduction in price and complexity.
But we also have put a ton of code in an open repository that anyone can access and copy from.
So, like we did in the Hacking Echo situation, you can now browse GitHub, find some code, use it as is or modify it as needed, and then put it up on Lambda and pay only when you execute it.
I think this is going to make for a lot more hacking, experimentation, and trying new things.
And that is going to result in new use cases and new markets. It may already have.