Indeed, I have been burned by personal data loss before, and I guess I should really look into their back-up strategy (non-existent?), or implementing our own.
Maybe we can upload to Nirvanix, and transcode there, but then transfer it to S3 for long-term storage & public delivery.
Also, Tom, the email address you used for this comment is now “undeliverable”. Remote host said: 554 delivery error: dd This user doesn’t have a yahoo.com account (firstname.lastname@example.org) [-5] - mta160.mail.ac4.yahoo.com [BODY] at 2008-12-05 16:38:33
(Zakir)[http://blog.zakirhemraj.com] said: You’re right, we have split the application and db into two servers… and yes, it was really easy.
If you’re looking for other cheep grid hosting solutions, Slicehost (recently acquired by Rackspace) is awesome..
I’ll be using them for my personal projects. at 2008-12-06 12:45:55
- Prefer in-house servers for mission-critical applications.
- Prefer portable data.
- 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 :)
Comments from my old blog:
(Joshua Briley)[http://www.para-diddledesign.com] said: Derek,
This is very interesting. I followed you here from the Sitepoint blog about the reliance on SaaS apps. Google Apps is my main concern… email backup, primarily.
Like you mention, Google Docs is exportable, though it’d be a big pain in the “you know what” to do so with a lot of documents (unless I’m missing something). This is precisely why we use Docs only for collaboration. at 2008-12-07 14:37:45
(Google Maps, Buscador de Numeros Celulares)[http://www.idmovil.com.ar/blog/archives/101] said: […] What if a SaaS You Depend on Dies? | geek.derekmartin.ca […] at 2009-03-21 22:29:21