This is part three in a three-part series. Read part one here, and part two here.
Avoid the Hijack; Own Your Auth
What if you could download a lightweight piece of software that is a full-featured auth platform? And what if this platform was just for you? And you could deploy the auth platform anywhere? What if you could host it yourself or let someone else operate it for you? And what if that platform was API first and your developers loved it? What if it had an easy way to configure throwaway instances for testing or dev setup and integrated with tools like Terraform for full featured configuration management? And whether it was deployed on–premises or in the cloud, the architecture was always single-tenant? And what if using it didn’t cost an arm and a leg and in fact costs less than other solutions? And what if, in addition to everything above, it had completely transparent pricing with no nickel and diming for every feature?
At FusionAuth, we built such an auth platform. We believe this is how technical teams should be able to outsource authentication.
We believe technical teams should be able to:
- Get their data whenever they want it
- Protect themselves from noisy neighbors
- Comply with data residency requirements
- Embed auth into a satellite
- Run auth from their basement
- Code with auth on an airplane without wifi
- Avoid mocking
- Dev locally
- Have the ultimate say when it comes to latency and system architecture
- Scale without issue
Local Development and Testing is More Efficient
When a developer owns the infrastructure their application runs on, and has it available locally, they can develop online or offline without relying on a SaaS provider’s uptime or worrying about rate limits.
The isolation of having software available locally is just as important, because developers can tweak configurations freely without impacting other engineers. They can wipe the infrastructure clean for testing, spin up multiple instances for different branches, or test version compatibilities and upgrades without affecting anyone else—or needing a separate “test” account. Plus, running a component locally doesn’t come with extra costs like a dev SaaS account might.
When developers use the exact same architectural components across dev, CI/CD, staging, UAT, and production, the risks of bugs caused by environment inconsistencies decrease. Unlike mocks, a common workaround for testing external dependencies, a self-hosted approach reduces the risk of incompatibilities introducing bugs in production while still maintaining speedy tests in other environments. While production might have more compute power, using the same underlying product across environments eliminates a major risk factor.
Auth Should Compliment Your Architecture, not Dictate it
With a single-tenant, ‘owned’ model, either in the cloud or self-hosted, you have a lot more control over the deployment of this key architectural component:
- Migrating data: if you want to move providers, you can migrate everything, including password hashes. This allows you to move your identity data where you want it, not be tied to a specific provider or force your users to reset their passwords.
- Availability: during a SaaS provider outage all a team can do is file a ticket and rely on the SaaS provider’s team and SLA. This is not enough when auth is a key component of an application (which is typically always).
- Upgrades: changes in the underlying component, such as a version upgrade or infrastructure improvement, happen on the team’s schedule, not on a SaaS provider’s.
- Cost savings: if applications are already running in an organization’s data center or cloud account, other components can be added and take advantage of existing fixed infrastructure costs.
- Better performance: colocating key architectural components together reduces network hops; with self-hosted solutions, teams can control other aspects of performance such as datastore sizing, autoscaling, and proxy or WAF tuning
- Compliance and legal requirements:: if the data held in a system needs to be located in a certain country, have prescribed, audited access, or stored for legal minimum durations, these requirements can all be easier with self-hosting.
- Extreme customization: custom application topologies such as air gapped or intermittently connected networks can be supported.
- Security: controls are easier to apply and verify when a system is running in an environment that you have total control of.
- Deployment flexibility: you can start in a hosted solution to get started quickly and then later migrate to self-hosting for more control, or vice versa.
Doesn’t Multi-Tenant SaaS Keep Costs Low?
We sometimes get asked, “but won’t you eventually be forced to go the SaaS route because of increased costs for dedicated architecture? Wouldn’t everybody provide a dedicated, single-tenant set-up if they could?”
There is no 1:1 tenancy to price ratio that automatically increases a vendor’s costs for dedicated architecture. The mental connection made in the industry between multi-tenancy and costs passed on to the customer is a fallacy. It’s like saying fast food is cheaper because all restaurants should use a single giant table instead of individual ones. Sure, it might seem more “efficient” at first glance, but in reality, it just creates ill-defined messes, reduces privacy, and makes it hard to organize multiple, larger groups reliably. And all jokes aside, more individual tables are not necessarily more expensive than one big table.
What You’re Exposed to at One Big ‘Multi-Tenant SaaS’ Table
There is much more to the cost calculation than just whether it’s single or multi-tenant. Take, for example, these examples, where the customer is bearing less overall cost & headache with a dedicated model than they would with a multi-tenant SaaS solution:
- A self hosting customer can treat FusionAuth as just another application with an SLA and error budget, amongst their entire suite of applications their dev, ops or SRE team supports. Versus having an outlier that has to be accounted for along the way, with a different SLA and error budget.
- A FusionAuth Cloud customer benefits from the operational expertise of the FusionAuth team amortized across many cloud customers, and can even do a multi-tenant set-up within a dedicated architecture, so their privacy and data residency are never at risk.
If you don’t believe that providing single-tenant VIP suites for customers can actually be offered at a more competitive price, believe a month-to-month customer that was quoted a much larger price by the competition before switching over to FusionAuth. Or a different customer who saved 50% by moving off a multi-tenant solution.
There are other organizations offering single tenant solutions as well, like Ghost. From this podcast transcript, they are running “26 and a half 1000 individual databases” and have built a substantial business doing so.
We built auth with developers and engineering teams always in mind. We built as developers and engineers ourselves. We built FusionAuth asking how we would prefer authentication to be architected if we were to outsource it.
Authentication is a critical path for your application and handles very sensitive data. It is the front door to your application and any downtime affects every user. So it needs to be architected in the most secure, scalable way. It’s that simple. And let’s face it; nobody wants to eat from the same giant table at a restaurant (can you imagine?).
Conclusion
The choice is yours—give up control with multi-tenant SaaS and hope for the best, or truly own your authentication even when you outsource the fiddly parts.
Multi-tenant SaaS prioritizes vendor efficiency over your needs, but FusionAuth lets you develop locally, secure your data, and test without friction.
Take back control of your auth, it’s as easy as guaranteeing your own table at a restaurant. Get started with FusionAuth for free in the way that works best for you, or connect with us at Authcon, the first-ever event focused only on Customer Identity.
