DerekMartin.ca web development, spirituality, UFOs & the occult

What if a SaaS You Depend on Dies?

Sitepoint just published an article about the Perils of Software as a Service. They basically just said “in an economic downturn, companies will start axing their free services, and if you depend on their free services, that might have a big impact on you and your business model”. Then they offered three pieces of advice for mitigating these risks:

1. Prefer in-house servers for mission-critical applications.
2. Prefer portable data.
3. Prefer backed-up services.

Yep, that’s a great list… but there are some issues:

1. In-house servers require in-house experts, and those cost money. If the economic downturn is the problem, you probably have less money, too. Further, if you’re a start-up, doing stuff in-house may increase your time-to-market, which means you’ll be eating away more of your cash reserves faster.
2. They argue that using Google Documents could be a bad thing, because Google could decide it’s not worth developing further, and then your stuff is stuck in their service. Well, yeah, except that a) you can export to Microsoft Word & PDF format; and b) Microsoft Word uses a proprietary non-portable format in its own right. The fact that it has majority marketshare is what makes people feel safe about it.
3. You should *always* only use backed-up services, not just in times of crisis. Never trust your data to people who don’t do back-ups. AND if you store your data somewhere ‘else’, you should always take the time to write a bit of code that will retrieve a copy for you ‘on-demand’. Hear they’re going down? Hit the Big Red Button. Even if you just store it in a big compressed archive for now, at least you still have it!

So, those are a few short rebuttals, but I think they missed a key strategy altogether:

• Implement abstraction layers

The best way to reduce the risk of losing access to a service is to write your code in such a way that it doesn’t know where the data lives.

1. Prefer names that refer to the type of data being handled, not the source of the data.
   Example: Location->getLatitude() is better than Gmap->getGlat()
   You can still use Gmaps, of course, but use them inside a Location wrapper so you can swap it out for Yahoo Maps, or (god forbid) MapQuest Maps if need be.
2. Prefer accessing & manipulating data through getters & setters, not directly.
   Example: echo $person->getFullName() beats echo $person->first_name.$person->last_name;
   Directly accessing the properties assumes they’re stored locally, when they could just as easily be living out on a web-service. Also, if you use a getter and your data provider decided to re-name the “last_name” property to “sur_name”, you only have to make the change once, in the getter, instead of throughout your code.
3. Prefer libraries that abstract away dependencies
   Example: The type of SQL you write changes depending on the type of SQL Server you’re using (MS-SQL Server, MySQL, DB2, Oracle, etc). Propel is a PHP ORM that removes SQL from your daily life as a developer. It replaces SQL with Criterion objects. To get a list of users with last name Jenkins, you do:
   $c = new Criterion();
   $c->add(UserPeer::last_name, ‘Jenkins’);
   $users = UserPeer::doSelect($c);
   Now if you need to switch from MS-SQL to MySQL to save money, it’s no problem. You just tell Propel you’re now using MySQL, and you don’t have to change your code. Can’t wait till ORMs start supporting Google’s “BigTable“, and Amazon’s “SimpleDB“.
   You could even abstract it a bit more, and have a UserManager object which wraps your data-access-layer of choice. Your new code would simply be:
   $users = UserManager::getUsersByLastName(’Jenkins’);

All of these solutions require that you sit down and think about what you’re going to do before you do it. That is, they require a Design Phase. Don’t knock it ’till you’ve tried it

That’s all I can think of right now. It’s still before 8am, so don’t expect too much from me. Anyway, if you have more ideas, I’d love to hear them in the comments