How Complex Can SaaS Offerings Get?

Feb 14, 2008 by Sinclair Schuller

It’s common place to equate Software as a Service with CRM, HR, or other “business function” style implementations. Although these implementations are not simple by any means, they generally do not require the computational rigor of an offering that performs complex mathematical analysis or photorealistic 3D rendering. In fact, it’s rare to hear that a company is pursuing this sort of “non-traditional” SaaS offering.

A recent discussion across two blog posts (this one and this one) sparked an interesting discussion about the viability of the SaaS model in the computer assisted design (CAD) space. The discussion revolved around issues like data access and security, but an important takeaway is to highlight that discussions are cropping up regarding application types that were traditionally considered “desktop only”. We see people discussing CAD, and even Adobe talking about bringing Photoshop online.

It’s my opinion that almost any application can be brought online these days, and that making those applications work well is a problem whose solution is rooted in good software engineering. SaaS offerings need not be restricted to applications that serve only horizontal business functions, but can branch out into non-traditional verticals such as CAD. I would even go as far as saying that in many cases, online versions may “out feature” and “out value” desktop counterparts. Take CAD for exampe: can every architecture and design firm afford servers that can perform photorealistic rendering? Probably not, but you can bet that a SaaS provider along with a massive render farm can give that sort of value to anyone on earth.

Do you feel my take on this is too agressive? Is it too early for traditional “heavy” client offerings to move to the SaaS model?

 

read more

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

Should You Scale-proof SaaS Offerings Early?

Dec 7, 2007 by Sinclair Schuller

A SaaSBlogs reader recently sent me a link to an article by Dharmesh Shah over at OnStartups. In a nutshell, the post articulated that building a highly scalable architecture when creating a new application is premature and creates a large resource tax on a startup’s already limited resources. This led to a vibrant thread of comments with people arguing both sides, but one comment by Dharmesh really stood out (and surprisingly wasn’t even acknowledged in the remaining comments) was the following:

“One point I didn’t make in the article, but probably should have: When making tradeoffs regarding scalability, you are at some level incurring technology debt. Debt is not always a bad thing — it can often help you grow. The key is to make sure that the “interest rate” on the debt does not outweigh the benefit of the tradeoff. So, if making a scalability tradeoff will likely cause you to rewrite the entire system, it’s probably not worth it. But, if it’s simply a matter of “Pay X now or 1.2X later”, it might be better in some cases to just pay 1.2 X later”.”

This comment provides sound rationale to the “should I scale-proof my offering early” question. From the standpoint of an entrepreneur, don’t waste your resources if scaling is not your core business (because some products have that as a core function) or if the cost massively outweighs the benefit since your immediate goals should include getting your first (or fifth, or tenth) customer, not worrying about your one-thousandth. That said, if you can scale proof your application at a low cost and avoid incurring technology debt, it’s generally wise to do so. Looking at the boundary cases, it becomes obvious. I offer you two choices: you can engineer your application for a cost of x and not be able to handle reasonably large scale or spend 1.02x and be able to deal with really large scale if and when it comes. Generally, you’ll choose 1.02x since the cost is negligible and the risk mitigation is high (this is why we pay for health, auto or any other insurance). Conversely, if I told you that the cost was x but that engineering for scale would be 1.2x or worse (say even 2x) you would most likely opt out and rightly so. After all, imagine that auto insurance personally cost you the amount of a car each year, you’d likely do everything possible to avoid getting it (granted, there are intricacies such as personal injury, etc. but work with me here! These non-tangible intricacies even exist in software – it’s one thing if you’re app doesn’t scale and you can’t take on new customers, but what if it grinds operations to a halt long enough that you lose existing customers or reduces the stability of the application to zero)

The goal of SaaSGrid, aside from providing an execution runtime and business services for SaaS offerings, is to allow for scale-proofing a SaaS offering at a negligible cost, biasing the cost/benefit analysis highlighted by Dharmesh toward choosing to scale rather than opting to incur debt. We strive to push for that trivial case of making the choice “obvious.”

If you’ve participated in building a SaaS offering, did you deal with the scale question early or late and how did your experience turn out? Have you ever had a “windfall”, a rare but possible scenario where you don’t experience organic growth but rather experience a large fluctuation in customer traffic due to some event?

 

read more