Every self-respecting framework or service always claim there is "no vendor lock-in" if you use their technology. I think there's no such thing.
What is a vendor lock-in? Can you measure that?
I think the best way to measure vendor lock-in is to estimate the amount of work it would take to switch from one vendor to its competitor or alternative.
For instance, switching from Tomcat to Jetty involves changing a few deployment descriptors. So vendor lock-in is not that big. What about the tweaking and tuning you did for your Tomcat, can you immediately do that for Jetty? I guess not. It will take some time before you fluently "speak" the Jetty language, so vendor lock-in is bigger. What about QA? your software was tested and working perfectly on Tomcat, how much time do you need to spend to make sure everything works on Jetty? So vendor lock-in is even bigger.
Another good example is the Spring framework or Hibernate. They both claim that your code is not dependent on their frameworks - it's true, you can write a Spring backed application with very little dependency on Spring in your code (unless you use annotations of course) but can you pull out Spring and replace it with something else? Can you replace Hibernate with another ORM solution that easily? No way - you're very strongly locked into Spring and Hibernate. In Spring they call it "dependency injection" - you can read it as "You don't have to write any code and we inject the dependency on the Spring framework automatically" :-)
No metter what frameworks you choose you're locked into it. So the only course of action is to make sure you choose the right ones that will not disappear any time soon.
What is a vendor lock-in? Can you measure that?
I think the best way to measure vendor lock-in is to estimate the amount of work it would take to switch from one vendor to its competitor or alternative.
For instance, switching from Tomcat to Jetty involves changing a few deployment descriptors. So vendor lock-in is not that big. What about the tweaking and tuning you did for your Tomcat, can you immediately do that for Jetty? I guess not. It will take some time before you fluently "speak" the Jetty language, so vendor lock-in is bigger. What about QA? your software was tested and working perfectly on Tomcat, how much time do you need to spend to make sure everything works on Jetty? So vendor lock-in is even bigger.
Another good example is the Spring framework or Hibernate. They both claim that your code is not dependent on their frameworks - it's true, you can write a Spring backed application with very little dependency on Spring in your code (unless you use annotations of course) but can you pull out Spring and replace it with something else? Can you replace Hibernate with another ORM solution that easily? No way - you're very strongly locked into Spring and Hibernate. In Spring they call it "dependency injection" - you can read it as "You don't have to write any code and we inject the dependency on the Spring framework automatically" :-)
No metter what frameworks you choose you're locked into it. So the only course of action is to make sure you choose the right ones that will not disappear any time soon.
Posts
No comments:
Post a Comment