News for hackers. Stuff that matters.

hekike

Open Source Is Ready for the Application Layer

Open source has always been a big part of my career. I worked and maintained multiple Node.js libraries, joined the Node.js Diagnostics WG, and am now building OpenMeter. So I'm probably biased, but I think we reached a new inflection point with open source. The infrastructure layer, coding languages, and frameworks are all de facto open - what's next? Services that help teams build...

( Read More... | no comments | 2 points | on HN )
Re:The Two Types of Future Developer on Saturday February 08, 2025 @01:47PM (#42985145)
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!

The Two Types of Future Developer

AI is transforming software engineering, and many people wonder if developer jobs are going away or just changing. Here are my two cents:For context, my journey as a developer over the years followed the path of many others: during university, I started as an intern in Eastern Europe at a small company, 100% of my time writing code, and later became a staff engineer at big tech (Netflix,...

( Read More... | 3 comments | 4 points | on HN )
Re:Ask HN: How to offer AI services with my H100? on Thursday January 02, 2025 @02:37AM (#42572534)
You can check https://openmeter.io for usage metering and billing.
Re:Ask HN: How did you set up usage-based billing? on Tuesday November 14, 2023 @10:11AM (#38264189)
I wrote an article this year about how to setup UBP with Stripe. I hope it helps: https://openmeter.io/blog/implementing-usage-based-pricing-w...
Re:Robust Usage Reporting with Stripe on Wednesday September 20, 2023 @11:07AM (#37585160)
This is a great insight; thanks for sharing!

ClickHouse for usage metering with Kafka Connect

Hi HN, at OpenMeter, we switched to using ClickHouse as our database to pre-aggregate and query usage.Additionally, our initial choice of the streaming processor, ksqlDB, revealed limitations when scaling for small to medium-sized producers. The constraint was around ksqlDB's limited capacity to run persisted queries per instance (20 on Confluent Cloud) and its lack of support for...

( Read More... | no comments | 5 points | on HN )

Robust Usage Reporting with Stripe

I recently looked into how to build out robust usage reporting with Stripe. This comes basically from the set of challenges around:- Workaround Stripe API Rate Limits- Handle billing cycles and minimize usage drift into the next billing cycle- Deliver usage exactly once to avoid under and over-billing- Stripe requires to report usage on Subscription ItemsYou can read the full blog post...

( Read More... | 2 comments | 3 points | on HN )

How do you meter execution duration for billing?

I'm researching the best ways to collect the execution duration of containers/serverless workloads for billing and chargeback use cases. Per second granularity, like AWS CPU-Hours. I'm finding that most engineers' journeys start with listening to start/stop events and calculating the delta between those lifecycle events. But over time, they find it challenging to handle lost events or...

( Read More... | no comments | on HN )
In the meantime, we looked more into metering and metrics and shared some thoughts here: Usage Data: Auditable or Operational https://news.ycombinator.com/item?id=36616364
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.
Cool, thanks for sharing it. Would you use SaaS usage for cost analysis or to charge your own customers for shared resources?
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.

Thank you. Do you have learnings or use-case you can share and you want to see OpenMeter to cover?
Thanks for letting us know! We fixed it, also here is the link to join: https://discord.com/invite/nYH3ZQ3Xzq See you on Discord ;)

Launch HN: OpenMeter (YC W23) – Real-Time, Open Source Usage Metering

Hi HN! I’m Peter, the co-founder of OpenMeter (http://openmeter.io). We are building an open-source project to help engineers to meter and attribute AI and compute usage for billing and analytics use cases. Our GitHub is at https://github.com/openmeterio/openmeter, and there’s a demo video here: https://www.loom.com/share/bc1cfa1b7ed94e65bd3a82f9f0334d04.Why? Companies are increasingly adopting...

( Read More... | 44 comments | 3 points | on HN )

Older »