Vendor lock-in is a common concern for many customers when they need to choose the software platform for their application. One way to address this concern is to agree on a standard API/Interface. However, as we have all seen on many occasions, that model has many drawbacks. I'll name a few of them:
- Standards usually lag behind market needs
- The market requires a certain maturity, which can sometime takes years to get to the point where standard can even be discussed
- Standards tend to "kill" innovation, as we've witnessed with J2EE, where everyone wanted to stick to the least common denominator (not necessarily the vendors, but the customers)
- Standards need standards bodies, which tend to be highly politicized and consequently do a poor job of representing the best interests of the end user.
As a result, we need to accept the fact that most new technologies will be non-standard (at least up to a certain degree). That means that we need to manage the risk of lock-in without relying on standard APIs to do the job for us. Interestingly enough, this question is less common with open source frameworks. A good example is Hibernate and the Spring Framework. Both frameworks were very rapidly adopted although they were not open standards. Hibernate later evolved to become a standard (JPA). Many ideas from Spring made their way through to EJB3 in the same way. What can we learn from this?
We can't rely entirely on standards to manage our lock-in risks. Open source can reduce the risk from a different angle: the fact that it's open and used by others through an open community makes it very close to a standard effort, except that it's done by a specific group that we "choose" to rely on to do a good job representing the interests of the larger community. Open source projects that will do a good job of that, will most likely become a de-facto standard.
Abstractions - the new "standards"
Abstractions are a well-known approach for separation between our application and the underlying implementation. Having said that, achieving the right level of abstraction, without scarifying functionality, is an art form. Spring taught us several lessons on how to do abstractions right through the introduction of the dependency injection and declarative approach. Using this model we can handle the logic of how to get an event and which method to call when an event arrives outside our code through a declarative set of configurations, and keep our code completely independent of the underlying event delivery implementation, whether it is JMS, JavaSpaces, a Data Grid and so on. One of the nice things about abstraction is that it is loosely coupled to the API, as it happens outside of the code, i.e., as part of our configuration. This means that our code can work with different messaging systems, even if they don't implement the same API. Mule is a very good example of how this can be achieved with different and many messaging protocols.
In summary:
- You can't entirely avoid lock-in risk; you can only manage it
- You can reduce and control lock-in risk in the following ways:
- Through abstraction
- Using open source
The ideal solution is to use open source as the abstraction framework -- and then you are free to use sophisticated commercial platforms underneath, without lock-in. That's what GigaSpaces' OpenSpaces framework is all about.
You can read more about it here:
