Genuine question, what’s the real value proposition of Stripe?
They do have a slick integration process for outside developers, but is that enough for to justify the financial values attached to them in the recent past?
As one of the earliest stripe customers, yes, that was the reason why we switched to them from Authorize.net.
Developer docs and easy API integration was, and is still, their "stickyness". But the eco-system of new products they've added have grown that moat to make it easy and cost-efficient to offload more and more of the financial and subscription stack onto Stripe. It's a virtuous cycle
As a SaaS veteran I can confidently say I would never put my entire company on the line for a remote API call before any request is served. Not just latency, but also - what the heck happens if you’re gone/down? The entire business operation grinds to a halt. This is such a huge non-starter. I reviewed Sync Agent and I doubt it is much help in case of an actual outage.
Very valid concern. We built the edge agent(https://github.com/warrant-dev/edge-agent) specifically for perf and reliability concerns. It's designed to run in customer infra with built-in storage (currently in-mem/redis) and can respond to all access checks even in the event that the Warrant cloud service is down. Writes would currently still be impacted if Warrant is down so this is definitely an area we're continuing to improve and expand.
Additionally, customers have also requested their own private Warrant service deployments/on-prem so that's something we may offer more broadly in the future.
This partially answers the previous post, but it doesn't answer all of the concerns he mentioned.
Even if you have an On-Prem deployment, if Warrant goes belly up, you're still hosed. Unsupported code is a recipe for disaster. What if it has a critical security vulnerability and it can't be patched? Is it legal to keep the code deployed once the contract expires and can't be renewed?
As a former Security Engineer that worked alongside the SRE team, we would never be able to justify this dependency for a production system. We'd rather build it ourselves or live with the crappier version than deal with a black box that can take down the business.
The flip side of this is an Open Source project. We regularly built around Open Source projects instead of starting from scratch when we could.
Have y'all considered moving to a license like BSL or AGPL for what you're building?
This is why 1 year ago we open sourced[0] SpiceDB[1] under Apache2 and have been leading the way for open source Zanzibar systems. SpiceDB has contributors and users from the likes of GitHub and Adobe in addition to Authzed; building in the open and making sure that we aren't the only ones supporting SpiceDB is critical to the long term success of our users and our business.
This is awesome, but it's also kind of wild that YC basically put closed-source and open-source competitors in the same space in virtually the same batch.
I'll definitely be looking at this for my current project.
We have thought about it but still evaluating. In general, our thought here is that in case we go out of business, customers should be able to continue using the software with access to source and some level of temp support. We'd codify these terms into contracts. From conversations with others, this seems similar to how companies like Plaid, Stripe and LaunchDarkly handled it, especially in the early days.
That being said, BSL/AGPL looks interesting but I'm not that well-versed in them so it's something we're going to look into more.
Be careful on licensing anything that gets linked/deployed in to the customers environment. There are many large and small enterprises with “strenuous review” policies, if not blanket bans, on licenses like AGPL. This is not to argue the morals or utility of those policies but it is fact.
Similarly it would behoove you to read on the “relicensing” issues of the last few years. Many companies start small with open source to drive adoption, then discover that business model also explicitly enables others to use the same work and compete in the same space. Much heartache ensues.
It's INSANE to me that this is a software service and not just a software product, like Microsoft Windows. It would be malpractice to use this at any company where security really matters.
If it were a a product you would only merely be at the mercy of the product's source code being securely written. But as a service, you are constantly at the mercy of the entire SaaS organization's security culture. Now you have to worry about every single employee with any access at the SaaS organization getting phished. About every sysadmin at the SaaS organization accidentally screwing up a config that opens up a door into their network. About how hardcore every support person at the SaaS organization is about resisting social engineering. Yeesh, it's exhausting to think about.
You've exploded exponentially the number of things that could go wrong resulting in a security hole. All for what? Nothing, because there's nothing about this product that inherently benefits from a service model technically. There's no large data in the cloud to crunch, nothing from other customers that could benefit a different customer somehow. It ain't napster, it's just authorization. It's a damn simple solved problem and you're making it harder just so you get subscription instead of one time revenue.
If promising your customers your service is secure and/or reliable is in no way a part of your value proposition, this is an ok option, but if it is, you're crazy to put yourself in such a vulnerable position like this
not sure if I'm understanding what you are comparing with. what is your alternative?
if we are taking authz as a need in your org and also a single point of failure for your entire services (as you said in your comment), are you suggesting you would instead build / host your own Zanzibar like authz service, and that your in-house solution would do better in terms of availability than this external solution?
leaving aside how much you'd lose on productivity, I would guess your in-house solution will break more unless you spend a lot of time making that a highly available service (and you'd depend on other SaaS for that as well, which may also break).
Also, if it's in house / on prem you can do a change freeze and actually mean it. With a SaaS that's a joke. You never know what the SaaS engineers might be doing. An in house system's downtime is more likey to be correlated with your other systems' downtime, so total downtime is going to be higher with a SaaS, especially since authz/authn is so critical to everything.
I don't understand why this is a SaaS and not just a software product you buy and run on prem. (In terms of business risk, buying this as an on prem product seems perfectly reasonable -- after this startup is bought by someone like Microsoft that can actually guarantee the features will stay around.)
yeah they'll probably offer some hybrid cloud/agent approach where the config lives in their cloud and syncs the config data down to an agent in your env with its own storage
Or what happens if they ban you because of pressure from wokemob Twitter or whatever policies?
This kind of business sort of makes sense for customers you know having a single sign on sort of like use Google to login but I agree there's big risks for companies.
I probably don't understand a whole lot about it or about how you mitigate those risks or about what people really value there.
