SaaS Provider Buckle Risk

Jan 30, 2007 by Sinclair Schuller

Alarmist titles are great, aren’t they? In all seriousness, I don’t intend to take an alarmist position in this post. However, I do want to highlight something that we discuss at Apprenda as the “buckle risk” that SaaS providers must deal with.

Rapid growth, when used as a blanket term, tends to be associated with success due to the positive connotation of growth and the generally accepted positive implications of something growing from smaller to bigger. For example, rapid revenue growth is good for a company, correct? Not always. A classic problem is burning through cash to match the operational needs of rapid revenue growth, and not giving time for the bottom line to “sink in.” Have any of you ever read the story of the sports apparel company 180s? If you’re in any type of business, you should read this story if you haven’t. Outside of the business world, rapid growth can have negative effects as well: dogs that grow too rapidly as puppies frequently develop hip dysplasia, or cities and towns (or any populace structure) that grow too fast frequently experience difficulty maintaining quality of life for residents. Generally, all of these had one thing in common: the unchecked growth severely taxed available or existing resources leading to unexpected or unintended consequences. So what does this have to do with SaaS providers and what in the world is “buckle risk”?

“Buckle risk” is best understood as the risk a SaaS provider takes on when planning for growth of their subscriber base on an unproven/untested technical architecture and infrastructure. Growing your subscriber base creates a “double edged sword” scenario, particularly if you’re building and deploying an enterprise SaaS application. You need a large and growing subscriber base to attract larger customers, but if your base grows too big too quickly, you could end up with service hiccups that alienate (and shrink) your existing base. Worse yet, your hiccup turns into an all out “buckling” of your infrastructure that takes a couple of days to get working again. Enterprise customers don’t like this very much, and are much less forgiving than consumers. This forces you to ask many questions. Did you make the right data partitioning choices? The right architectural choices when factoring in scalability? How about your hardware infrastructure? If it’s in house, did you set it up well? If it’s outsourced, what sort of SLA do you have from your provider and can they handle your load? How large of a subscriber base can you support before you “buckle” and have to spend time and money adjusting: 5 thousand users, 10 thousand users, 20 thousand users? In the best case scenario, these problems affect your economies of scale and reduce your margins (which is not too good of a best case scenario, since SaaS is very much a margins game for the provider).

You’ll here responses on this topic of “We’d be happy to have that problem” or “We’ll figure it out when we get there.” Traditionally, this approach has worked; we’re all guilty of sacrificing load capability early on in a project for on-premise software because we can release a patch or tell the customer to cluster some servers together when it becomes a problem. With a SaaS architecture, releasing a patch of a certain magnitude can be far too expensive and risky, at least much more so than distributing a patch one-by-one to on-premise customers. Relying strictly on hardware scale-out/up can be pricey in the short term. Planning around this problem early, however, is the best solution. Look for ways to build or deploy SaaS applications that reduce “buckle risk.” If you’re a SaaS provider, is this something you’ve dealt with or are concerned about?