Wrappers: staying portable and agile
As developers we build systems using components that other people write. This is the rational way to write software: trying to get the best result using the fewest possible resources. That said, it really pays off in the long run to not only use the best available components but to plan and design for portability. The art of the wrapper. Seeing Jonathan Weiss's simply_stored wrapper for CouchDB and SimpleDB this morning reminded me how important this effort is.
The trick is to spend an appropriate amount of time staying portable. In the last 12 years I have invested quite a lot of time and resources working on my own entity identification code (i.e., find people, product, place names in text, relationships between them, associating pronouns in text with names, etc.) Today, I almost always use Open Calais instead of my own code because it performs better, but, I do maintain and improve my code just so I maintain the flexibility of having my own NLP components.
I like using the commercial product AllegroGraph as an RDF store and reasoner but I also take the time to maintain my own code that also acts as an RDF store with geolocation and full text search. I use a simple wrapper so it is easy switching between either back end.
So, how much effort is appropriate to stay portable? I think that some real effort is worthwhile, especially when it is now common to heavily use other people's infrastructure (in addition to software components). In other words, it is always good to have an exit strategy when using AppEngine, AWS, etc. When I talk with customers, cloud platform exit strategies are not as important as deciding on components, language, and general software stack - but it is still a good conversation to have.
Open source, when appropriate business wise, is arguably the best protection for controlling the platform and components that you use to build systems.