3 ms·

Maybe this is a naive question, at what point does an organisation decide to build a framework or a product internally than buying? Sure there was no opensource

Maybe this is a naive question, at what point does an organisation decide to build a framework or a product internally than buying? Sure there was no opensource solution available but why not buy a product from other security companies. Just wondering.

spockz 5y ago
Integration into your own systems for example. Or specific requirements for which it is not clear they can be met by the product. Or unawareness. Or a combination of the above.
gneray 5y ago
It's a fair question, but in fairness to Carta, until recently, there have been ~zero commercial or open source solutions to building application authorization (beyond limited helper libraries or things like Active Directory, which solve only a portion of the problem). Developers have typically figured out the models on their own and implemented them in application code with IF statements, etc. and/or by building separate authorization services. Other publicly documented examples include teams at Slack (https://slack.engineering/role-management-at-slack/ https://slack.engineering/role-management-at-slack/) and Gusto (https://engineering.gusto.com/layering-authorization-into-a-web-application/ https://engineering.gusto.com/layering-authorization-into-a-...) OPA is one solution that's emerged in recent years. The author describes his team's point of view after evaluating it for their purposes. Oso (https://www.osohq.com/ https://www.osohq.com/) is a framework for application authorization. Disclosure: I'm a cofounder. Based on the post, the Carta team started their work in 2019, but we only open sourced Oso mid-2020, so they wouldn't have known about it. And in the last few months, a few other companies have announced offerings to address this problem too. So it's understandable why Carta chose to build. Now/soon other teams like them should have more options to choose from when they encounter similar challenges too.
simonw 5y ago
Build v.s. buy is genuinely one of the harder problems in software engineering strategy. You'll often hear people say "you should never, ever build something if you can buy a solution instead" (where buy also includes using an open source package) - but there are actually a bunch of other things to consider: - Is the solution you're considering well maintained and likely to keep working? Open source projects sometimes stop being updated. Vendors go out of business. - What's your escape strategy if the vendor DOES go out of business, or massively increases their pricing? - Integrating with a vendor / package is often a non-trivial amount of development work. Have you considered this relative to building your own, custom solution? - Do you have specific requirements that go beyond what's available off-the-shelf? It's absolutely true that your engineering efforts should be spent on the things that make your organization unique: time spent on your customer's problems is more valuable than time spent reinventing a wheel. But sometimes, the available wheels really aren't fit for your purposes. I've built when I should have bought, and I've bought when I should have built. Getting it right is hard! Often it doesn't become clear if you made the right decision until several years after you've made it.
- ex_amazon_sde 5y ago
  Ex-Amazon here. One thing than Amazon really understands is that if you build you also create the opportunity to develop skill and knowledge. Also you avoid vendor lock-in. Even Open source projects cause lock-in especially if they are overcomplex and fast moving.
somethingAlex 5y ago
One point I haven't seen covered is complexity. Carta seems to have an extremely complex authorization scheme but I wouldn't say that's the common case. Many organizations can get by using simple role + account based permissions. If you are a member of this account then you have access to the resources this account owns minus anything you can't access because you don't have role X or Y. Oftentimes the account based permissions boil down to where clauses in SQL statements. The role based permissions can be mapped to scopes in a JWT or similar. Anything beyond that can be done with if statements in your "parse user input" function or simply caught later on resulting in a 4XX error. I know at my particular organization, even when we have cross-account sharing, it's heuristic based. It's simple enough to just apply it in the application code. Stuff like "did this user's organization receive this shipment?" I feel like you have to be either a very large organization trying to make sure people do things consistently or have a very, very granular permissions model to even embark on making the decision of "build a whole authorization product in house or outsource it?"
- somethingAlex 5y ago
  EDIT: the last sentence refers to the context of authorization systems. Not completely in general.

spockz 5y ago

Integration into your own systems for example. Or specific requirements for which it is not clear they can be met by the product. Or unawareness. Or a combination of the above.

gneray 5y ago

It's a fair question, but in fairness to Carta, until recently, there have been ~zero commercial or open source solutions to building application authorization (beyond limited helper libraries or things like Active Directory, which solve only a portion of the problem). Developers have typically figured out the models on their own and implemented them in application code with IF statements, etc. and/or by building separate authorization services. Other publicly documented examples include teams at Slack (https://slack.engineering/role-management-at-slack/ https://slack.engineering/role-management-at-slack/) and Gusto (https://engineering.gusto.com/layering-authorization-into-a-web-application/ https://engineering.gusto.com/layering-authorization-into-a-...) OPA is one solution that's emerged in recent years. The author describes his team's point of view after evaluating it for their purposes. Oso (https://www.osohq.com/ https://www.osohq.com/) is a framework for application authorization. Disclosure: I'm a cofounder. Based on the post, the Carta team started their work in 2019, but we only open sourced Oso mid-2020, so they wouldn't have known about it. And in the last few months, a few other companies have announced offerings to address this problem too. So it's understandable why Carta chose to build. Now/soon other teams like them should have more options to choose from when they encounter similar challenges too.

simonw 5y ago

Build v.s. buy is genuinely one of the harder problems in software engineering strategy. You'll often hear people say "you should never, ever build something if you can buy a solution instead" (where buy also includes using an open source package) - but there are actually a bunch of other things to consider: - Is the solution you're considering well maintained and likely to keep working? Open source projects sometimes stop being updated. Vendors go out of business. - What's your escape strategy if the vendor DOES go out of business, or massively increases their pricing? - Integrating with a vendor / package is often a non-trivial amount of development work. Have you considered this relative to building your own, custom solution? - Do you have specific requirements that go beyond what's available off-the-shelf? It's absolutely true that your engineering efforts should be spent on the things that make your organization unique: time spent on your customer's problems is more valuable than time spent reinventing a wheel. But sometimes, the available wheels really aren't fit for your purposes. I've built when I should have bought, and I've bought when I should have built. Getting it right is hard! Often it doesn't become clear if you made the right decision until several years after you've made it.

ex_amazon_sde 5y ago
Ex-Amazon here. One thing than Amazon really understands is that if you build you also create the opportunity to develop skill and knowledge. Also you avoid vendor lock-in. Even Open source projects cause lock-in especially if they are overcomplex and fast moving.

somethingAlex 5y ago

One point I haven't seen covered is complexity. Carta seems to have an extremely complex authorization scheme but I wouldn't say that's the common case. Many organizations can get by using simple role + account based permissions. If you are a member of this account then you have access to the resources this account owns minus anything you can't access because you don't have role X or Y. Oftentimes the account based permissions boil down to where clauses in SQL statements. The role based permissions can be mapped to scopes in a JWT or similar. Anything beyond that can be done with if statements in your "parse user input" function or simply caught later on resulting in a 4XX error. I know at my particular organization, even when we have cross-account sharing, it's heuristic based. It's simple enough to just apply it in the application code. Stuff like "did this user's organization receive this shipment?" I feel like you have to be either a very large organization trying to make sure people do things consistently or have a very, very granular permissions model to even embark on making the decision of "build a whole authorization product in house or outsource it?"

somethingAlex 5y ago
EDIT: the last sentence refers to the context of authorization systems. Not completely in general.