Wednesday, December 10, 2008

No such thing: "no vendor lock-in"

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.



Thursday, December 04, 2008

R&D Lab - You pay for your mistakes

I made a big mistake a few months ago. I bought a few servers for us to use in our office - you know, it's important to have a few machines at your disposal so you can run intensive tasks on them or run all kind of different tests you couldn't otherwise do on your single development machine.

Makes sense right? Well, not in term of ROI and here is why:

I bought a fairly good machine with 4GB of RAM and an AMD 6400+ X2 CPU - that cost me about $1000. Let's assume the machine is utilized for about 8 hours a day (in reality I guess most lab machines are used much less). Assuming 250 work days a year that's 2000 CPU hours a year. Let's say the life expectancy of this machine is 3 years so for 6000 hours I paid $1000. That's about $0.16 a machine hour.

Now let's compare this to a machine I can rent from Amazon EC2 (prices). Assuming Moore's law will hold true for the next three years (limits of Moore's law) today's EC2 large instance (m1.large) will be equivalent to two of the machines I bought for my office (I'm assuming that Amazon are nice enough to lower prices for a given hardware configuration as it becomes older). Add to my in-house investment the electricity / cooling / management (as in personnel) and it will make my (already) bad investment even worse. Oh, and for my in-house machine I had to put the money upfront and not "pay as I go".

Now what happens If I need more machines at one time (for isntance, to do some tests before a release) and none at another time (like every night). Having these machines hosted on EC2 gives me the flexibility to use as many machines as I need and then don't pay for the time they sit idle.

The bottom line - If you're a small startup - don't buy lab machine. If you're a big company you could probably save thousands of dollars every month by hosting your lab on EC2.