Software has changed from something you run to something you consume as a service, and with this evolution, the landscape for large enterprises has fundamentally shifted.
Software-as-a-service (SaaS) products bring obvious benefits, especially for enterprise applications that employees use. However, with the growing number of services that an enterprise supplies to its end users, it becomes more and more complex to maintain a hodgepodge of building blocks that, in combination, make up the final product.
When starting new projects, it’s quite the timesaver to be able to use an existing service; it’s relatively easy to introduce SaaS early on before intricate requirements present themselves. This is especially true for identity.
The benefit of modern identity systems is that they all follow the OAuth and OpenID Connect standards. These core projects are lean and often sufficient during development. But what starts simple can quickly become complex and span multiple clouds. And as a project grows, using traditional SaaS for identity can turn out to be a poor decision.
Build and Buy
These days, companies typically develop cloud native applications. Kubernetes has presented itself as the clear winner for running systems in a cloud-agnostic way, enabling entire networks of services to be moved from one cloud to another with minimal effort.
This makes it possible for enterprises to hedge against infrastructure outages that, though rare, can be devastating. All cloud vendors suffer outages from time to time, and by having a deployment in more than one provider, these can be mitigated. Not to mention, multicloud provides the option to scale where price is appropriate, which can be equally beneficial.
So, while building for the cloud is the obvious choice, buying cloud components is not. Suppliers of commercial off-the-shelf software can still be divided into two main categories: SaaS and on-premise.
Putting an on-premise solution in a Kubernetes environment is not always possible or easy to implement. Problems relating to disk persistence, configuration as code, monitoring and elastic scalability are quite apparent when containerizing software that’s not designed for this era.
SaaS, on the other hand, reintroduces the infrastructure vendor dependency that organizations try to avoid. Thus, each SaaS service must be vetted to also have infrastructure vendor redundancy to maintain the hedge. On top of that, organizations must deal with geopolitical aspects such as region-specific data regulations, both for their own systems and any SaaS they procure.
Thinking Components
There are really only two solutions to this pickle. The first is to build your own. This might work for simplistic services, but supporting advanced services such as an identity system can rarely be considered core business. The second is to buy components instead of services.
Components built for cloud native deployments leave the power of choice and scale within the enterprise and let the component vendor focus on what they do best: developing complex software. A component should have a clear integration interface and focus on one thing and doing it really well.
Identity systems lend themselves extremely well to this approach as they implement a known set of standards, as noted earlier. A well-architected identity system is already split by concern (see the neo-security architecture). The purpose, a bit simplified, of the identity system is threefold:
- Authenticate users
- Produce a verifiable token with the result
- Manage users
These three purposes can be split into separate components if desired, but all three are often needed. For example, it’s hard to produce tokens if the user isn’t authenticated. It’s also hard to authenticate if the user doesn’t exist. But no rules are without exceptions.
The Power of Control
If microservices could breathe, the identity system is the lungs that support an organization’s published applications. A few services out there do not require a user to be authenticated to use it. That, together with the fact that the only way to secure an API on the identity layer is using OAuth, results in almost all transactions being routed through the identity system. As tempting as it may sound to outsource the management of the identity system, it’s a risky move. A cloud native component approach to software selection and procurement keeps the control in-house.
Kubernetes has proven itself the superior way to run software and ensure high availability. We are now entering the phase where the platform is mature, but the market is still emerging. It is time to require all software added to the stack to be cloud native components. If identity platforms can be components, so can all services.
