Re:Infrastructure SaaS – a control plane first architecture
by infra_dev on Wednesday June 22, 2022 @06:28PM
(#31842663)
Hey smashah, this is Ram, the author of the post. Everything that you said is pretty spot on. It is a really hard problem and pretty repetitive in many of the companies including open source projects. We hope to build a platform that can help with this and over time cover all the use cases you mentioned.
Re:Infrastructure SaaS – a control plane first architecture
by gkapur on Wednesday June 22, 2022 @06:54PM
(#31842932)
How do you think about partner versus build? Usage based billing on its own is a pretty complex topic as an example with multiple startups that have tried to do it right. It is pretty data intensive as usage frequency increases, as well. It seems like you may be trying to do too much here. Just one opinion but something to think through (build versus partner.)
Re:Infrastructure SaaS – a control plane first architecture
by kisheemon on Thursday June 23, 2022 @12:33AM
(#31845189)
I saw a pretty good article the other day about the some of the difficulties on the build side. Might be worth taking a look https://www.getoctane.io/blog/usage-based-billing-complexity
Re:Infrastructure SaaS – a control plane first architecture
by nussbaum9696 on Wednesday June 22, 2022 @07:39PM
(#31843326)
Specifically for API, seems better to just partner, focus on building core product and getting users.I've seen tools out there to manage usage based billing and auth for APIs, archetype.dev is one. Seems like no brainer vs. trying to spend eng hours in house to figure out, thoughts ?
Re:Infrastructure SaaS – a control plane first architecture
by ibeckermayer on Wednesday June 22, 2022 @06:26PM
(#31842640)
Sounds insanely difficult to get right
Re:Infrastructure SaaS – a control plane first architecture
by smashah on Wednesday June 22, 2022 @06:44PM
(#31842840)
YES! Imagine trying to do all that while maintaining and growing the source project. This is why I've never been able to get there with my project. Instead I have to make deployment buttons where DO makes all the revenue and their broken referral system doesn't even give me anything back.
One shortcut with all this is just to allow maintainers to surcharge a premium with deploy buttons.
Unfortunately there are limited tools/resources out there to answer the question "how can i build a cloud deployment option for my open source project" without 25 layers of abstractions. This is why open-source projects end up raising millions of dollars (e.g strapi, appsmith just off the top of my head). All this money just for all these companies to essentially build the same thing.
Ideally, there should be a service/tool (maybe thenile will be it) where I answer a few questions.
Containerised? Stateful? Long lived? Keep alive? Allow end users to deploy many instances? % premium per instance over cloud costs? License per instance? Pricing (tiered, volume, stairstep?) On end customer's own infra? Min resources per instance. Airgapped per user/airgapped per instance/all instances running on same cloud? Instance management API? Update strategy? Big Green button to update all instances at once?
And it should spit out a ready to deploy setup where I can start monetising my open-source project while concentrating on maintaining the project.
If the above exists then congrats, you disrupted the main reason for open source projects raising millions of dollars.