The Search for a better EOS Resource Model: Learning from AWS

This is the first in a 3 part series that seeks to derive feedback for the new EOS resource model proposed by block.one. We embarked on a quest to define the ideal EOS resource model by looking at the billing strucutres of successful comparables and formulated our stance on the model proposed by block one by comparing our final ideal resource model with the one proposed by block.one. Please read the introduction article before continuing.

Amazon Web Services EC2

In the world of leasing compute resources online, EC2 is the undisputed industry leader. When EC2 first launched in 2006, it took a radical departure from the monthly billing structure that dominated the VPS/Web Hosting markets of the time, offering $0.10 hourly billing for EC2 servers from the get go. This allowed for innovative new methods of compute resource scaling, as once could easily provision up extra servers in times of high demand and scale back when demand decreased. Later, AWS increased billing resolution even further and now bills by the second for Pay-as-you-go instances! While providing this innovative billing method for those who wanted it, AWS also had the foresight to support monthly and eventually yearly (AWS EC2 RI) billing for those with less elastic compute needs.

The billing methods were flexible, and crucially allowed developers to experience the service’s advantages for less than a dollar, without locking them into a monthly or yearly commitment.

In many cases, customers ultimately end up paying monthly for servers on servers because of the other advantages of the AWS platform, but from the developers we surveyed, the vast majority started with the free tier or per second billing.

People use EC2 primarily to host web powered APIs, and one of EOS’s core use cases is replacing traditional backends with decentralized blockchain APIs powered by smart contracts. When we try to onboard new developers for the EOS ecosystem, we are essentially trying to convince developers to build their next application’s backend using an EOS smart contract instead of a centralized EC2 powered API. This leads us to our conclusion that the ideal resource model should allow for new users to Pay-as-they-go in order to make it easy for users to experience the benefits of EOS dApps for the first time, while also offering cheaper monthly lock-ins for power users.

From our analysis, block.one’s proposal make huge progress towards decreasing onboarding friction by reducing the lock in schedule for resources from “Forever” to “Monthly”, but fails to offer a solution for cheaply onboarding users for a less than a dollar like AWS.

If we have anything to learn from AWS’s success, per transaction billing seems like a necessary component for any resource model that wants to grow developer adoption quickly.

TLDR:

• AWS offers innovative features for developers to deploy backends, and makes it easy for new users experience these benefits for less than a dollar by providing Pay-as-you-go pricing.
• AWS provides monthly billing for users that, after experiencing the benefits first hand with Pay-as-you-go, were comfortable locking into the platform.
• EOS is the best place to build decentralized backends, but we need to make it easier for them to experience the benefits if we want the EOS compute platform to be successful like AWS.
• Block.one’s proposal advocates monthly billing, but does not reduce the barrier to onboarding as much as per transaction billing would.