Friday, 25 October 2013

The Myth of Code Portability and "lack of vendor lock-in"

This is a Friday-style essay looking at something that is mentioned time and time again in articles about, "how we moved from .Net to Scala" or, "breaking free from the Microsoft stack". What I see time and time again is that people seem to say that they prefer one language or framework over another simply because it is open source/non-commercial. Naturally, open source can mean many things but the basics of the argument are that locking into a single vendor is a mistake that cannot be undone later but I don't agree with this for various reasons, described below.

The reality of virtually every system I have ever worked on or heard about is either, they only live for perhaps 5-10 years or otherwise they reach a point where they are left alone and not maintained unless absolutely necessary. From the customer point-of-view, this is fine because once it basically works, they want it left alone. By and large, if that customer decided, 10 years later, that they wanted a load more functionality, they would almost certainly get a completely new system based on completely different components and also, very possibly from a new supplier (because most customers get fed up with suppliers over time!).

So let us consider "product lock in" against this background. Scenario 1: Supplier creates a product based on a full Microsoft Stack, which gets installed at a customer site.

Issue 1: Maintenance.
No problems here, the .Net stack hasn't fundamentally changes in the past 15 years. C# looks pretty similar, albeit with some new functionality in later releases. Updating server OSs to new versions of Windows hasn't caused many headaches as far as I know, in fact, getting software and OS from the same vendor is good in terms of compatibility testing and support from that supplier. Consider what would happen if your open source product didn't work properly on Red Hat any more - you might be able to fix it but contributing to open source projects is not as easy as it sounds on paper and that assumes that you have the skills to even know how to fix it - you probably don't!

Issue 2: Major update. Again, no real issues here. This will be a new system that may or may not be Microsoft-based. If this is big enough, the customer is probably comfortable with the idea of replacing servers or hosting or OSs to suit whatever technology you decide to use for the new system.

Issue 3: A change is required (perhaps major) to a piece of your software - a module or service perhaps. Well, on the one hand, If you use the MS stack, it is likely that it either all works well or if it doesn't, it is a problem with the implementation, in which case, a technology change is not the issue, just a rewrite of that part of the code. On the other hand, many important customers are not comfortable with major changes anyway and the supplier certainly wouldn't want to do this unless they were paid for it. Using the MS stack doesn't actually preclude any of these things. The Vendor lock-in is not really in play and after all (God forbid) you can call PHP web services and MySQL databases from .Net if that was your core problem.

So what is the lock-in that people are concerned about? I think people are often talking about money rather than lock-in. I don't like the idea that because my software runs on Windows, MS have some kind of financial grip on me. But do they really? If you pay your licences up-front for Windows Server, how often do you have to upgrade and how much does it cost in the scheme of it? People still run 10 year old servers and even if licences are £500 a pop, compare that to the rest of the IT costs in an organisation and it really is peanuts.

What would using Linux, PHP, MySQL etc. actually give you? Really? Free updates - amazing, they are free from MS too except for major upgrades (which are hardly deadly expensive). A database engine that is still not as mature as SQL Server - again, if that's what you want, fine, but I am happy to pay a few hundred quid more for something that won't easily spill my user details over my web app. The same goes for .Net and Visual Studio with Azure. The cheapest? Nope but in my opinion, well worth the money.

If you want to use PHP - great. MySQL? Fine, Scala - do whatever floats your boat, but the decision, in my opinion, should be very heavily weighted towards the skillsets you have or can easily come-by and not some idealistic opinion about the latest and greatest languages, whether they are open-source or not. If your software is tested correctly, you should already know if the language/framework/database is suitable for the scale of work that the application needs to do.

Much debate is centred around endemic and often thinly veiled hating of corporations. It is easy to hate a company that makes lots of money but in most cases, they have lots of money because they produce something that people want. Some of the assumptions about the motivations of these companies are also out-dated (and might not have been true in the first place) - again, it is easy to assume that the only thing that a large company cares about is money but I think MS (I don't know much about Apple and Oracle etc) have made large improvements over the past 5 years which many haters still don't even know.

The moral? Don't change your system just to be "free", wait for it to need an upgrade and make changes then, based on what you need for your system at that point in time.
Post a Comment