Should You Treat CIAM Like A Library?
Hiya,
When you are integrating any critical component into an application, you have two options. You can delegate management of this functionality to a vendor, in which case you are consuming it as SaaS. Or you can use the solution like a library, in which case you are managing versions, upgrades and testing.
The right choice between these options depends on whether your application needs control over items like the data location or upgrade cadence.
There are more strengths and weaknesses with each approach, of course. I’m looking at this through the view of a customer facing authentication system, but the same choices apply to other critical architecture components such as:
Data storage
Caching
Authorization Services
Workflow tooling
Payments
All of these have SaaS solutions as well as solutions available as a library.
SaaS
A SaaS is usually integrated via an API or, in some cases, a higher level widget which contains UX and logic. With a SaaS, you have the following benefits.
Someone else manages the upgrades, security and performance of the system. You benefit from their expertise.
You can be up and running quickly. The SaaS provider already has all the infrastructure set up.
Upgrades happen automatically. This means parts of your application will just get better without any effort from you.
The downsides are:
You have to make requests over a network, typically the public internet (though there are tools like PrivateLink which can avoid this).
You have less control. Less control of the service, of the data locality, of the performance, of the reliability.
You have fewer options for remedying any issues. You can open support tickets and pressure the provider, or leave.
Upgrades happen on their timeline, not yours. If anything breaks, you may be unpleasantly surprised.
Library
With a library approach, the component is integrated into your system more deeply. While you may still use an API to interact with the component, you run it on your infrastructure with your team. There may still be support from a vendor, but the vendor isn’t operating the solution, you are.
With this approach, you have the following benefits:
You have control of the component, including the version it is on, the hardware it runs on, the performance monitoring tools, and the data locality. This last is more important for CIAM than for other types of components because of the PII stored there.
You can manage upgrades more gracefully, on your schedule.
If there is a performance or feature issue of the component, you can slot it into your development teams efforts the same as you would if there were an issue with the performance or features of your application.
Requests can be made over a network that you have control over.
The downsides are:
You have to manage upgrades as part of your development workflow. It can be easy to get many versions behind. Each version you fall behind, the work to get to the latest version becomes more painful.
You have to run the service on your infrastructure and have a team who can manage it.
Your ability to deliver features and functionality, both initially and over time, are more limited. They depend not only on the developers of the library delivering, but also on your team to test, deploy and integrate.
With this approach, you are now definitely responsible for the proper functioning of your application and its components. You were always responsible, because your users don’t care who is providing the login box if they can’t log in, but now you are clearly responsible.
Versioned SaaS
There’s a hybrid option. Versioned SaaS means that someone else maintains the infrastructure and is responsible for performance and monitoring, but you as the consumer of the service specify the version you want.
Many large SaaS options let you specify a certain version of an API, including AWS and Stripe. These typically allow clients to request a certain version of the API on each API call, which means you can control the upgrade process more than you can with a pure SaaS.
While this gives you more control, there are still many operational functions you delegate to the vendor.
What To Consider?
Things to consider to when making this choice:
How critical is this functionality? The more critical, the more it makes sense to treat it like a library because if it fails, you don’t want to be solely reliant on a vendor.
How much do you value time to market and ease of operations vs fine grained control? SaaS wins hands down at the former, whereas a library offers you more control.
How much time and slack do you have in your current team’s schedule? A library requires more care and feeding.
Do you have the skills to properly operate critical infrastructure? Are you outsourcing the operation of your main application to a PaaS like Heroku or Render? If so, this is a strong argument for using a SaaS solution.
There’s no answer that is applicable in all situations. If anyone tells you something is the best all the time, they're lying.
But thinking about these questions will help you determine if you should treat a critical application component, such as a CIAM system, as a SaaS or as a library.
Cheers,
Dan