Defensively Architecting a SaaS Implementation

Feb 7, 2008 by Sinclair Schuller

If you’re a SaaSBlogs regular, you’re probably a big fan of the SaaS delivery model. One thing you also probably know is that one of the downfalls of the delivery model stems from the fact that it increases overall cost of failure and cost of downtime since it moves usage from a decentralized (aka on-premise) delivery mechanism to a centralized one. Although this is a downfall, it’s not a good enough reason to avoid the model; SaaS’ pros significantly outweigh its cons. The value afforded by SaaS outweighs centralization issues. That doesn’t mean, however, that an ISV should ignore problems posed by centralization. After all, if architected poorly, downtime may affect all of your customers, which would in turn clog your support lines and negatively impact your growth rate. So what can an ISV do to alleviate the pitfalls of centralization? Focus on defensive architectures.

As a discipline, SaaS architecture can take lessons from ship building. Normally, small vessels (let’s say one that carries 8 passengers) have a single compartment hull; that is, the hull is a single volume of air designed to keep the vessel afloat. One strategy to move 4,000 people from port A to port B is to put them on 500 such small vessels. If a vessel were to hit an iceberg, it would most definitely sink since a hull breach would open that single compartment up to water logging. However, the problem would be localized and isolated, with a high degree of probability that the other 399 vessels will make it to port B without a problem. Consider this to be representative of the on-premise model.

Much like the on-premise model, however, this mechanism for moving people is grossly inefficient at best since it requires separate crew and supplies for each vessel. A more efficient way to move 4,000 people would be on one massive vessel, exploiting obvious economies. Despite any achieved economies, an ugly facet rears its head: a poorly engineered mega-vessel could lead to the deaths of all 4,000 aboard in one fell swoop! What happens if it hits an iceberg? Consider this to be representative of the SaaS model.

So back to the iceberg question: fortunately, engineers architect mega-vessels defensively; rather than a single compartment, single volume hull, mega vessels are divided into multiple airtight compartments (for example, the Titanic had 16). A hull breach may cause any single compartment to flood, but the system as a whole remains resilient. Any load borne by the breached compartment is implicitly offloaded to the remaining compartments of the hull, keeping all 4,000 passengers alive despite a massive system failure! This sort of defensive model is absolutely necessary in ship design, and is something that SaaS architects and engineers should adopt in their design approach. Your software now becomes a single, centralized heap that is “carrying” thousands of customers. Focus on compartmentalizing resources and supporting system failure, but try to keep any one compartment from being dedicated to some subset of your customers (i.e. when a compartment on a multi-compartment vessel is breached, some subset of the 4,000 passengers did not sink as a result!). Of course we all know how things turned out for the Titanic which confirms that if the breach is big enough it can still take down the entire system but the idea is to minimize the risk and realize all you can do is reduce the probability that an unforeseeable event will have significant negative impact.

 

read more

Enterprise SaaS != Web 2.0: A Quick Hosting Perspective

Sep 10, 2007 by Matt Ammerman

I like a good mystery just as much as the next guy, and this story’s got it all.  If you haven’t got the time or interest to read the whole forum thread, here’s the synopsis:  Jatol.com (no hyperlink provided because of said mystery), a notable web hosting company seemingly popular with development crowds has simply vanished.  Literally.  Websites down. Domain missing. Phones disconnected. Believe it or not, even the owner is missing! 

At this point, there’s not even a support number to call and Jatol.com users aren’t even able to retrieve their stored data or web site files. As I read further down the discussion chain, I started thinking about how awful it would be if I were running a web-based business in a situation like this – the mere thought of surmounting catastrophic shutdown such as this is mind boggling.

While it may seem obvious to some, this story specifically highlights a very important part of what enterprise SaaS ISVs should look for in managed services: providers that can assert serious service level agreements and back them with real ramifications.  For instance: transparent multi-tiered redundancy, consistent and thorough backups and archives, potentially even software and hardware escrow services (see ‘catastrophic shutdown’ above). The bottom line is that hobbyist devs hosting websites or even working applications with reliable hosting companies count downtime in minutes, while enterprise count downtime in thousands of dollars.

The tricky thing about SaaS is that it fundamentally requires the ISV to at least purport to be the ‘provider’ of software.  While hosting may be outsourced and ISVs become at least the ‘P’ in ‘MSP’, it is vitally important that the backing ‘MS’ be up to par.  If you’ve dealt with an MSP (without naming names) and had service level ‘experiences’, what are your thoughts on MSP preparedness for SaaS?  Are MSPs ready to host enterprise SaaS applications that generate the aggregate load of potentially millions of ISVs’ users?

[poll=6]

 

read more

Is SaaS About Maximum Profit for the Provider?

Jul 16, 2007 by Sinclair Schuller

I recently read and commented on a good post over at Unreasonablemen.net titled “How Do SaaS companies make money“. In summary, the article highlights the fact that SaaS companies have an alarmingly low EBIT, high marketing spend rate, and no mechanism for getting “upgrade fees.” While this is all true, I wouldn’t use the word alarming. In the comments I state that the low EBIT is a result of immaturity within the space, and that it will change.

 To further the conversation, however, I also want to point out that SaaS is inherently not an early, maximized profit model. Instead, the tradeoff is reduced profit for increased stability. The software industry has done excellent with the traditional model, but as business consumers look for more and more choice as well as a way to reduce IT budgets, SaaS becomes a natural outcropping. SaaS providers need to recognize that while huge margins are gone, as are “upgrade fees”, they will see revenue stability and predictability. The SaaS business model is about reaping the benefits of this predictability. As for funding R&D via EBIT, one needs to recognize that SaaS (from the technical perspective) is about incremental and rapid improvement rather than “fell swoop” R&D and releases. Can a SaaS company pursue large scale R&D? Sure they can, but they have to hit scale first, and as we’ve seen via the Netsuite example in the referenced post, this could take some time.

 

read more