Urban Planning in the Datacenter?

Jan 31, 2007 by Matt Ammerman

It was written only a month ago, but Robert Mitchell’s article ‘Virtual machines: the new ghetto in the data center’ is a classic in my book. Mitchell’s article draws up the similarities between data center engineering and urban planning. Like city planners, service providers must be careful that the efficiencies they introduce to their load-bearing technologies don’t harm the quality of service to their end users. It seems like a no-brainer… but immediately driving down that cost-to-service pain is so very tempting nonetheless.

When you scale an infrastructure to handle the load of more tenants, you can scale out – add more machines (a la Google) and harness the power of clustered computing, or scale up – add more power to existing hardware, or replace it with more powerful hardware to shoulder the load. Similar urban planning scenarios dictate that to accommodate more tenants you either build more houses (scale out) which results in urban sprawl, or you build high rise apartment structures (scale up) and end up with super-expensive maintenance costs. Either tactic has a beneficial short term outcome, but problems arise because with success come more tenants moving in. You could scale up or out forever, the problem is that both lose efficiency over time.

 

 

But then there’s virtualization. Mitchell’s metaphor is that virtualization is the ghetto of datacenters – that is, virtualization is the high density housing of more tenants in the same physical structure. Don’t scale up, don’t scale out – instead, build partitioning elements and use the same space for more tenants. The metaphor is dead on. Mitchell ‘s case, though, is that improper use of virtualization leads to terrible inefficiencies when it comes to per tenant load. One of the more interesting comparisons that Mitchell makes is the way that virtualization causes tenant processes to ‘fight’ for computing time.

“Unfortunately, some organizations may be stepping back into a world more familiar to mainframe users in the ’60s and ’70s. In that era of timesharing, applications got a slice of the mainframe.”

The use of virtualization technologies may lead to increased overall efficiencies for the provider, but slow response times and lowered service levels for the end user due to sharing the same computing resources with other tenants. Mitchell’s metaphor calls virtualization a compromise – a way to cram more tenants into the same space.

As SaaS becomes more prevalent and the number of SaaS providers grows, more companies will be exploring the various techniques for balancing cost-to-service efficiency with load-bearing capability. Scaling becomes a major concern, and any of the above mentioned approaches to scaling costs a good deal of money – hence the added costs of starting a SaaS company and imminent concern of provider buckle risk.

To complete the metaphor… new SaaS providers will need to build cities, when traditional software packages are dealt with more like prefab homes.

I’m curious to hear some stories about scaling in data centers.  I think we all know of Google’s approach, but what has your experience been?  Have you had better luck taking up more real estate with commodity boxes, or paying for high-end raw processing power?  If you are using virtualization technologies, what have the net effects been on the end user experience?   

(Note: I purposely left ‘computing in the cloud’, like Amazon’s EC2, out of this conversation because I want to discuss the burdens of scaling as they pertain to providers who build, instead of buy, their hosting solutions)

read more

A Different Angle on Platform Flavors

Jan 30, 2007 by Sinclair Schuller

Phil Wainewright just posted a breakdown on SaaS platform/ecosystem flavors titled “What flavor is your ecosystem?” His breakdown is at a slightly different angle and a finer grain than my article categorizing platforms. The categorization seems to classify ecosystems and platforms based on implementation mechanism, which is an excellent categorization in its own right. At the end of the article, he states that “The most successful ecosystems will be those that offer the most popular balance between convenience and flexibility” which is a distilled and parallel version of an article I wrote awhile back regarding SaaS enablement selection and flexibility vs. transparency (It seems that according to Wainewright, convenience comes at a price, namely loss of transparency and a higher lock-in/coupling flavor with the enablement technology). I agree with Wainewright 100%. My bets are on flexibility. Although convenience can be a powerful thing, our industry has learned (I hope) from the effects of unnatural lock-in and random introduction of technologies that “go against the grain” already defined by the industry. The best solutions are those that get the job done with no added baggage. This does not, however, mean that convenience needs to be abandoned. Convenience can be delivered in a fashion that maximizes flexibility.

[poll=3]

read more

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?

read more

Quick Note: SaaSBlogs.com Redesign

Jan 30, 2007 by Matt Ammerman

SaaSBlog.com’s over-the-weekend redesign is complete.  A few left over pieces were worked today and I think we’re operational on all fronts.  Let us know if something’s not working right.

The purpose of this redesign is to easily facilitate the spread of SaaS-related discussion in the blogosphere stemming from this site.  You’ll notice we’ve added tons of tools for aggregating our articles to bookmarking sites.  We hope you’ll use them.  There’s widgets that allow you to rate the articles you read on SaaSBlogs.com.  This helps us to know which content is most valuable to you.  We’ve also got some great polls lined up, and we’ll share the results with you so that we can all get an idea of how the SaaS world is shaping up.

We’ve also made it easier for you to discuss SaaS with us here by adding comment spam filtering so that we can open comments to unauthenticated visitors.  Yes, that means you lurkers… time to speak up!

We’ve seen steady growth in readership over the past couple of months and our goal is to continually provide valuable SaaS-related commentary to the industry.  As always, thanks for reading – 2007 ought to be an interesting year for Software as a Service and our goal is, as always, to make sense of this massive revolution that is reshaping the software industry.

 

read more

Is a Drop in Satisfaction Among SaaS Users a Concern?

Jan 26, 2007 by Sinclair Schuller

I bumped into an article at Computer World titled Survey: SAAS satisfaction dropping as customer interest expands. The article highlights a report by the Cutter Consortium and Jeffrey Kaplan of THINKstrategies. In summary, the report discusses an interesting trend in a drop in customer satisfaction among SaaS users despite the fact that interest in the delivery model continues to grow as does the user base. Kaplan “hit the nail on the head” so to speak when it comes to the why; user expectation in a growing market doesn’t synch up with what is provided, hence the drop in satisfaction. As Kaplan noted, this is a side effect of a growing market but did offer a cautious warning to both users and vendors when it comes to expectation. This notion of expectation vs. deliverable is something I wrote about earlier (in a sense). If you look at the diagram, you’ll notice a center piece that defines value. That can be drastically skewed and misinterpreted based on expectation and perception, that’s the SaaS ‘minefield’. I think there is more to this reduced satisfaction, however, than just gaps in deliverables and expectations.

read more