What makes a solution a platform?
A Platform approach to Cloud Metering and Usage-Based Billing
The term Platform is widely used across the tech industry and liberally applied to describe various solutions. For us at Amberflo, it means something very specific. It is a set of well defined attributes by which we hold ourselves accountable, drive roadmap, and ultimately stake our claim to being a platform solution provider.
We would venture to say that the following must have attributes apply not just to a platform approach to Cloud Metering and Usage-Based Billing but broadly to all solutions that claim or are platform-centric.
Of course, this is not an industry-defined, let alone agreed upon, list of attributes on what makes a platform - platform. It is simply our playbook that helps us stay true to our vision - helping the world move to a more fair and transparent business model. We believe that achieving this vision requires a platform-centric technology approach and solution.
Below are the list of must-have attributes to meet the minimum bar for a platform solution.
What makes Amberflo solution a platform?
- It abstracts complexity
There are many parts to a platform solution and there is a lot that goes on behind the scenes. In our case, with a Cloud Metering and Usage-Based Billing Solution, there is a lot that goes on from the time a meter event is ingested. Each event is deduped, persisted, transformed, aggregated, trigger workflows, and more. All of this complexity is hidden from the developer. You simply interact with a set of APIs to send raw meter events and the service automatically turns them into intelligent, consumable usage insights data sets. There are no servers to manage, no logic to write, update, and maintain, and the system delivers enterprise grade durability, reliability, and scalability.
- It democratizes access and use
It is built on the principles of hardened APIs that also serve and demonstrate a contract of trust - that interface won't just randomly change. The APIs will be backward compatible and the system is designed with this in mind from the get-go. Allowing the user and developer to have confidence to build on top of it and propagate its use as a standardized interface and system.
- It has high fixed costs (costs a lot to build)
Building a system that meets the ten criteria outlined here, inevitably, requires a heavy lift and a sizable investment (time and resources) upfront. Additionally, guaranteed availability, durability, and scalability offered from the get-go require further upfront investment, resulting in a high overall fixed costs basis to bring the system to life.
- It has low marginal costs (once built, cost to use is low)
Conversely, once the high fixed costs investments have been made (point #3) and the system is made ready for use, because of cloud unit economics and elasticity, marginal costs are low. The low marginal costs lend themselves to providing better price-to-performance ratio to customers in the form of lower prices, and more.
- It is on demand
System must be available on-demand for increase or decrease in usage.
- It is offered on usage-based pricing
Point #4 directly lends itself to enabling customer facing usage-based pricing. Furthermore, point #5 can only truly be claimed as a feature if it is being offered on a usage-based pricing model.
- It has network effect
The more people use the system, it gets better for the next set of users. This can come in a variety of different ways - economies of scale (lower costs), performance metrics, SLAs, features, and more.
- It gets better with use (user input or user generated content)
It gets better at the individual user and use case level. Data drives insights. With more (historical) use features (particularly data driven, e.g. forecasting, AI/ML value added) improve and get better.
- It is programmable
It is an “API First” system designed to be accessessibly and operated upon programmatically via a rich set of APIs.
- It is self-service
Lowers friction to entry and is coupled with a free-tier or free-trial.