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!
I do see the trend in corporates to push this agenda, not sure if it will survive though...becoming a developer again may sound like downsizing your career progression in many cultures.
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.
