You raise some valid points here Baz.
What you highlight below, isn't necessarily vendor lockin, but what i
call architectural lockin -- you've made decisions to utilize a given
service to the point where you have left yourself with no other alternative.
Our company, aw2.0 Ltd, make our real money on cloud architecture and
building extremely high availability/volume solutions that are
transportable. We do not lock in any of our clients to Amazon/RackSpace
and make sure they can easily deploy from their own in-house bare-metal
systems to the cloud and back again without even thinking about it.
You can do it, but you have to be aware to not lock yourself in
architecturally.
Baz wrote:
Good points Alan. About Facebook, they do have their own
infrastructure, but it was all built using new-fangled "cloud"
technologies that weren't adequately baked just a few years back.
Anyway I'm just ripping off Marc Andreessen in an article he wrote
recently, I don't know too much more about the details :)
Vendor lock-in is a very important issue - there's no doubt about
that. What I've noticed though, is whatever technology you use, be it
open-source, closed-source, standards-compliant etc. there is always a
relatively high degree of lock-in once the app starts getting medium
complex. Let's take SQL for example, you can stick to the
lowest-common-denominator syntax, but how long does that last before
you you need full-text search, stored procedures, nested queries,
custom functions, and so on. I've almost never worked on an app that
wasn't married to its DB.
Now what about open-source - how many people do you know can reliably
fix a bug in Linux or MySQL or Apache, at a reasonable cost? It would
often be cheaper/easier/safer to just move to Windows, Oracle or IIS
to solve the problem. Not to mention writing the patch is only the
beginning, it starts getting real hairy managing that patch, testing
for regression when the core is updated, etc. It's a costly,
complicated and delicate endeavor to maintain your own branch of a
complex open-source software.
As for GAE, it's Java! Or should I say it's OpenBD! Yes, there are
many custom aspects to it, especially if you have a lot of datastore
logic - but I think you'd be able to re-use 70%-80% of your code on a
standard Java platform if you needed to. In my experience, that's
about exactly the same as if you moved from SQL Server to MySQL, or
ACF to OpenBD.
Amazon, Rackspace and GoGrid aren't that portable either. Before you
know it you will start having complex scripts to build/setup your
AMI's, you'll use SQS, SimpleDB, and so on. Even S3 is kind-of
a weird beast. None of that is insurmountable of course, but I'd be
leery about how much easier it is to switch a complex AWS app to
GoGrid, than GAE to Tomcat.
--
official tag/function reference: http://openbd.org/manual/
mailing list - http://groups.google.com/group/openbd?hl=en
