Exactly! And as the boundaries between specializations like backend, frontend, embedded, and data science are going away, developers can express their creativity on an entirely new level. Generalists will thrive in the future!
Internal usage is basically Cloud Unit Economics: https://www.finops.org/wg/introduction-cloud-unit-economics You treat infra teams as providers and price-in their services. For example you may price Compute team by "selling" vCPUs, DB team by selling GB stored per month and product team per business transactions. Each team builds on top of each other and buys a service from their downstream provider. Like product team buys DB storage, DB team buys vCPU to run DB etc. If you price in these internal resources (rate cards) and track usage you can attribute cost to each team based on their consumption. These internal bills together equals to the total company wide AWS bill. This not just creates accountability for teams but you can also do margin analysis and tell if certain team's product is profitable. Engineers can also plan future services and architecture by estimating cost like, new service will store 1TB/day which will cost X and then business/PMs can make decision based on it. It's a also a great way to optimize cloud cost beyond obvious isolated things like upgrading instance types as it tells you where optimization needs to happen, which provider need to lower their cost to increase margins.
Very cool, thanks for sharing. I like this reporting approach, once you have the usage data aggregated somewhere a state machine is a great way to report usage to Stripe. Do you trigger the Inngest billing fan out end of the month CRON style or when Stripe changes billing period and triggers a webhook to Inngest?
I think it's substantial risk for the core business. To be able to glue usage to invoice, Orb has to become the source of truth and billing engine top of Stripe, while Stripe is still the payment gateway. This creates a fragmented world where the customer has to use both systems simultaneously; this is challenging especially that Stripe ships features fast and frequently, leaving the customer exposed and vendor locked.
Thank you for the honest feedback on the landing, appreciate it. Yes, we should make it more informative. Maybe docs is more useful in the meantime: https://openmeter.io/docs
Great question. It has two components for OpenMeter:
1. My personal frustration when I had to do usage-metering at Stripe and wanting to have a standard for it, like how we have it for metrics. I also find it silly that every company trying to figure this out on their own.
2. We want to build usage collectors for common cloud components and third-party APIs and I think it's going to be easier to do it together as a community instead of working in silos.
But yes I agree, it's more challenging to build in open but I think it benefits the customer, the quality has to be there.
It depends on your use-case. On a higher-level OpenMeter focuses on the data challenge to collecting usage data from infrastructure components on scale, and providing aggregated meters real-time.
The other platforms you mentioned focuses more on billing with some metering component. For example Lago looks like writes all events to a relational database first than aggregates usage at query time when they do billing. Metering with a database has some limitation when it comes to scale or when you need to monitor meteres real-time and trigger actions based on them. I can see for example some combining OpenMeter with other billing platforms to have a scalable usage-based billing.
Those are all solid products for billing. Tough none of them are both open-source and have the scalability of streaming aggregation. Even Lago is AGPL which can be challenging for some.
That's a great insight, thanks for sharing. Would it be the ideal solution code / config driven, something like:
SELECT user, SUM(runtime) FROM usage => invoice_template(Z) Wdyt?
Btw how do you handle idempotency with time series? I think replays and least-once delivery in distributed systems can be challenging around usage collection if you don't have a key to deduplicate by.
I like the idea of meter all primary business executions by default and pick what you want to use later. This is useful if you want to do cost analysis, iterate on pricing, etc.
Would you track API calls by default like a usage-based third-party (OpenAI API, Twilio, etc.)? Or your own web server (Lambda, Next.js etc)? Or both.