User Management: The Next Major Pillar in the *-as-a-Service Paradigm?

TL;DR: The answer is yes, it probably is. Here’s why:

It’s 2013, and user management has become an absolute must-have. Long gone are the days when web properties simply had visitors. Now, it’s essential to know with whom you’re interacting and to store that data and make it actionable. It’s a subtle art that involves leveraging technologies like social login, social profile storage, single sign-on capabilities, and more.

At the same time, the tech world is slowly becoming a web service API-driven world. IT departments have begun seeing the value of the SaaS model over the on-prem model. And yet user management still tends to follow the on-prem model. I think that this is about to change. Here’s why.

A Quick And Dirty History Of *-as-a-Service

Once upon a time, servers were expensive, hard to maintain, and always—always—on premise (after all, where else would they be?). Then, data centers came along and produced massive economies of scale in computing resources. People started calling it “cloud computing.” The world took notice and began to take advantage of the possibilities opened up by this new technological horizon.

Where IT departments once built most if not of all of their software stack from scratch—sometimes everything but the operating system (and sometimes even that!)—the rise of cloud computing meant that they began to externalize core elements of their tech stack and workflow by relying upon external vendors. The result, in short: the *-as-a-Service paradigm.

Okay, so that story might just gloss over a fair amount of detail (!), but I do think that it captures the basic thrust of the *-as-a-Service paradigm and how it has developed thus far.

Early on, critics contended that IT departments would never be willing to outsource core functions to third parties. The gut feeling of CTOs and other technological decision makers, this way of thinking goes, will always be to keep things in house. Control is the name of the game; technological trust stays within four walls.

But the critics are increasingly either changing their tune or simply being ignored. Why? Because the *-as-a-Service paradigm makes a very powerful thing possible: it enables companies to whittle away extraneous tasks and complexity in the name of a near-total focus on core business logic. This whittling away might ruffle the feathers of some old-guard decision makers—and yes, sometimes they have a point—but even they are increasingly seeing the writing on the wall.

And so if you could boil the *-as-a-Service paradigm down into a single core ethos, it would be this: have someone else build and manage the things that you don’t absolutely have to build and manage. This ethos amounts to a genuine passing of the baton to external parties. It’s a refusal to re-invent the wheel from scratch and an affirmation of buying a Firestone tire instead.

An Expanding Paradigm

Although it’s foolhardy to attempt to locate the historical origin of the *-as-a-Service paradigm, we can at least pinpoint a few major players that were crucial in its establishment: the Salesforce and eBay APIs in the early oughts (marking the birth of the Software-as-a-Service (SaaS) model), the surprising emergence of Amazon Web Services in 2006 (the first stirrings of the Infrastructure-as-a-Service (IaaS) model), and the AWS-driven Platform-as-a-Service (PaaS) Heroku, which came along in 2007 (now owned by Salesforce in an interesting twist of historical fate).

More recently, *-as-a-Service has expanded well beyond these initial pillars into a variety of other domains. Nowadays, you see a much broader landscape in SaaS (too many to mention), IaaS (Rackspace and others in the OpenStack ecosystem, Google Compute Engine), and PaaS (AppFog, OpenShift).

But you also see entirely new domains, from Database-as-a-Service (10gen, Cloudant, Heroku Postgres, Redis To Go), Backend-as-a-Service (Backendless, Parse), and Analytics-as-a-Service (New Relic, KeenIO), Email-as-a-Service (Mailchimp, Sendgrid), Telecommunications-as-a-Service (Twilio), and so on. This is merely a fraction of what’s actually going on in this space.

In all of the above cases, companies have come along and offered to do things that other companies could conceivably build in house. This is often what makes *aaS anything a tough sell. Companies always have to carefully weigh the costs of going DIY against the costs—not to mention risks—associated with delegating significant portions of their technology stacks to an external vendor.

The *-as-a-Service paradigm has been driven by CIOs, CTOs, and others putting their trust in external vendors. Granted, Plenty of major companies are not yet ready to deploy applications in production on Heroku or manage email campaigns through Sendgrid or let Stormpath handle their authentication and security.

Simply put, it’s going to take years and a lot of fundamental shifts in the cloud space for their decision-making process to shift in the direction of *aaS solutions. But the movement is well underway, and the techno-economic factors driving it are simply unstoppable.

Stop Building, Start Buying

Most companies can build and maintain just about anything they want, and many do a perfectly satisfactory job of building user management infrastructure. But remember that the *-as-a-Service paradigm is emphatically not about that. It’s about division of labor. I could grow, process, and prepare all of my own food—and here in Portland, that actually wouldn’t be all that weird—but that would detract from all of my other activities.

If I wanted to become a marathon runner or learn cello or crack open my high school French books, I’d be hindered in all of these pursuits by the need to constantly provide for my food intake. I’m quite happy to delegate that whole food acquisition thing to external vendors. The freedom I gain—the freedom to pursue activities like self-improvement and learning and exercising and making music and working at Janrain and so on—is well worth the cost and risk.

Analogously, if you’re building a SaaS product focused on, say, developing complex algorithms for targeted email marketing, the case for doing things like buying and managing your own servers or building your own in-house CRM for organizing your contact information or an in-browser product management tool is growing weaker and weaker every single day.

Why User Management

Making the case that user management is the next major star in the as-a-Service firmament is difficult because, to put it bluntly, there are far sexier things going on in the technological universe.

I recently co-organized a NodeJS conference here in Portland called NodePDX, and what I saw on display was a diverse set of dizzyingly cool new technologies, from HTML5 game engines to NodeJS running on Raspberry Pis to people running Node on temperature sensors. What we do at Janrain isn’t quite like that.

User management won’t get a lot of play at bleeding-edge conferences like RICON or Google I/O and it hasn’t spent much time climbing the ranks on Hacker News and Reddit. But that’s okay because the importance of user management lies not in the sexiness of the technology but rather in its proximity to both the business logic and core technology stacks of companies that want to remain in step with our current technological horizon.

What on Earth does that mean? At the risk of painting in overly broad strokes, I think it goes something like this: once upon a time, it was perfectly okay for major websites to have anonymous visitors. People would visit OmniCorp.com, see some static (and probably not very illuminating) content, and then leave. So-called Web 2.0 changed all of that—we all know this story—and now vastly more is demanded of the relationship between web properties and users.

Now that the world has become as device- and data-driven as it is, users demand the ability to see what others are up to, to share their experience with known others—not just the anonymous multitudes—and to have an experience that is tailored to their interests and particularities. The case for actually providing that kind of experience—not to mention for building rich datasets around selective targeting of users—is growing as quickly as demand.

Up until just a few years ago, everyone was simply building their own user management stack from scratch. This meant all of the following:

  • Any organization crafting a social login solution through a major social network or other identity provider—Facebook, Twitter, LinkedIn, Google+, Amazon, Instagram, etc.—would have to design all of those API interactions from scratch. Identity providers’ APIs tend to differ drastically from one another, which means that coding them from scratch within an application stack—not to mention designing a UI around them—can be very resource intensive on the engineering and design side. You’ll also need a globally distributed CDN to pump out lots and lots of JavaScript 24/7.

  • Social login is one thing, but social profile storage can be orders of magnitude more difficult. Not only do you have to enable social login to retrieve that data—given that users’ consent is necessary—but you have to either build and manage the resulting database or rely upon a Database-as-a-Service offering to fill the gap. Then, you need to produce some kind of data access layer that enables you to make use of it.

  • The same goes for single-sign on (the ability for users to be logged into multiple domains simultaneously without having to log into them one by one). On the server side, this involves lots of servers dealing with lots of concurrent connections. On the client side, it involves small dependency-free JavaScript widgets that do all the heavy lifting.

When lots and lots of organizations begin building things like this in a redundant fashion, it’s only a matter of time before a SaaS marketplace emerged ready to fill this gap. And this is precisely what we’ve seen and precisely the movement of which we are a part.

Might As Well JUMP

The Janrain User Management Platform (aka JUMP…you see, my lame Van Halen joke is actually not a complete non sequitur) was designed to solve the kinds of technological problems I listed above and to do so with aplomb.

Perhaps most importantly of all, JUMP provides an abstraction layer that keeps you from having to get your hands dirty with all of the above. We built a system with the following in mind:

  • Massive scalability. We are all AWS, all the time, which means that we have virtually unlimited resources for handling user traffic, back-end processing, and data storage. That’s one fewer set of sys admin or DevOps calamities to keep you awake at night.

  • API-driven architecture. Let’s face it: nowadays, it’s all about RESTful HTTP endpoints and JSON. That’s exactly how we roll. JUMP is completely agnostic toward the applications that use it. You’re free to use one of the runtime clients or mobile SDKs that we’ve built or not. As long as you you’re making the right HTTP requests and properly authenticating yourself, you’re good to go. No proprietary software or anything remotely like it need be involved.

  • Abstracting away underlying API and protocol changes. Let’s say you’ve designed an application that enables users to log in via, say, Facebook. Now let’s say that Facebook has gone and changed their already-maddeningly-mercurial API. Or let’s say that crucial changes in OpenID or OAuth or another protocol break portions of your application stack. “I can’t wait to invest engineering resources in keeping up with those changes!” said no one ever. Let us sink resources into that.

  • Integration with other SaaS products. Getting the most out of user management involves the ability to tie together a number of disparate services, such as Salesforce for CRM, LiveFyre for real-time interactivity, DISQUS for commenting, and so on. A user management platform worthy of the name will come with those integrations already built in. That’s what Janrain has done.

Again, skilled engineering teams absolutely can do most or all of the above. Some of them have even done it well. You, Dear Reader, might be a part of—or even leading—such a team.

But it’s important to bear in mind that the ones who have done it well in the past did it in the absence of a well-established User-Management-as-a-Service marketplace. This has begun to change dramatically, and I think it’s safe to say that we’re on the cusp of a day when the build-vs.-buy decision will push most companies, even technologically advanced ones, to trust the *-as-a-Service space to handle nearly everything outside of that ever-smaller space where companies actually should build from scratch. That space now includes user management, and the sector is full of win.