Re: why .NET is platform dependent ???

n here comes the reply...
-------------------------------
Hi Sachin

I am not sure if I am the right person either :-) So CCing two friends of mine who are perhaps better qualified. My personal opinion on the matter is below. Note that it is personal, and may not reflect Microsoft thinking on this issue.

thanks
Vineet

1. First what is a platform?

Platform is something one stands on. The reason we talk about platforms in IT is because, like all in engineerings, we have in computer-science a case of building things using existing components. So your code stands-on / targets / leverages a platform. What actually is the platform? Let's see:

a) At one time the platform was the hardware. People used to code in assembler. So there were mainframe programmers, x86 programmers, DEC Alpha programmers, etc. The big question mark was how to make one programmer work on another hardware platform without learning it bottoms up. This led to the arrival of languages like C / Pascal / COBOL / Fortran that were hardware-independent by providing a set of primitives that could be translated by a compiler into the specific instructions for a hardware platform. For the same programming language, multiple compilers would support multiple platforms. This also gave an opportunity to raise the level of abstraction and the notion of user-defined types was introduced. The portability was at the source-code level. Source code written on one platform (read hardware) could be taken to another hardware platform and it would typically compile without change, atleast as long as you were using the same compiler.

b) Times changed, and programs got larger and more complex. A new generation of programming languages evolved to introduce higher-level abstractions, namely: objects. Meanwhile, Operating systems were evolving at a tremendous pace, adding more capabiltity for programmers to take advantage of. Naturally, programmers did take advantage of the OS, and started writing code specific to an OS. The platform got changed, it was now the operating system. So we had Windows programmers, Solaris programmers, AIX programmers, etc. However, while the language-compilers of yesteryears had been able to abstract differences between instructions of various hardware platforms, there was nothing to abstract the differences between the operating systems.

The other interesting trend of this time was that the the std. library could not keep pace with Operating systems. The typical areas in which the std-libraries were left behind were: threading support, graphics, distributed stacks, dynamic linking, etc. In order to address these areas, programmers had to link external libraries which provided solutions to address these areas.

Java was created for this time: it provided a runtime environment to abstract differences between OS, and by providing a modern class-library it eliminated the need for most external libraries. The promise of WORA (Write Once Run Anywhere) was born.

c) Times have once again changed. Operating Systems have (more or less) matured now, atleast on traditional hardware; Hand-held devices are still seeing a lot of innovation. What is still evolving is the application environment. Programmers now target application platforms / servers. So we have .Net programmers, J2EE programmers, etc. The platform is now the application server. However, there does not seem to be agreement on what app-server should look like. So we see various vendors coming up with interesting innovation on app-serves to distinguish their offerings from one another. Platform independence today would mean writing code that can run on all application-serves.



2. But do we need Platform Independence?

Ok, so I don't care about how do you define platforms. I just want my code to run across multiple operating systems. But why? Let's see three scenarios:

a) Small, Standalone, Desktop Application: Let's suppose I am writing an app like WinZip. I want it to run on Windows, Linux and Unix. Which technology do I use? .Net? No - won't run on Unix. J2EE? Sure. In fact, I don't need J2EE. I can use the basic Java SDK from Sun. And my compiled binary would run on all operating systems. C++? Yes, but, I would have to compile for different operating systems and produce different binaries. Java seems to be the best choice.

b) Medium - Large-scale Product: I am an ISV building an ERP, or a Dealer-management product, or any large-scale product. This would typically involve mutliple components - App-Server, Database-Server, Web-Server. Let's think of the .Net Solution: SQL, ASP.Net, IIS, Windows. I test it, perf-tune it, etc. - its a single integrated stack. No chance of porting it to another OS. Not cool

J2EE? Well, let's go for the IBM route. Let's use DB2, WebSphere, AIX. I do my coding, perf-tune it, test it, whatever. Does this take more time / effort on J2EE as compared to .Net? Yes, it does. But let's ignore that as being typical Microsoft marketing. Let' assume that we have to spend the same time and effort on both sides.

Now I want to deploy it. My customer is not ok with AIX, he wants Hp-UX. Would the solution work? Sure! We are on J2EE, after all - WORA, remember!! So let's get started. First thing - I need a build of WebSphere for Hp-UX, and a build of DB2 for HP-UX. Typically, that would mean that I would have to go for different version of these products (Not the same version of WebSphere is available for all OS!). Let's assume that reality is sweeter than that, and I get the same versions on which I built my product. Now I would deploy the system again. Would I not run into any OS issues? Unlikely. There are always operational issues dependent on the OS. But let's assume that there are no OS specific issues also. Now, just to make sure that everything does work the way it's supposed to, wouldn't I again do integration testing? Perf-testing? Security / Penetration testing? Sure, I would! That's extra effort!! Is the cost of this effort more / less than the cost of the OS? Or the extra effort required for the customer to run a heterogeneous enviroment? (Ultimately the customer would pay for the cost of my extra testing, anyway!). Forget the value of time lost while doing all this. Platform Independence does not seem to gain us a lot!

Ok, so the customer is ok with AIX. He however wants WebLogic. Now things are bound to break! Why? Can't I write code just to target the core J2EE, without the IBM specific extensions of WebSphere? Sure? But is that easy? I guess I would need to be very careful to ensure that code runs across any app-server from any vendor. At least that's what the analysts seem to say. Assume I do accomplish it. I will still need that extra testing effort! And this time, the effort is much bigger. That means more cost. And loss of time. Again, what is platform independence gaining us?

Hold on, why are we doing all this testing on a per customer basis? Can't I just test my product across let's say five / six reference implementations, and support just these? Sure we can. That would spread out the cost of supporting multiple platforms across several customers and also we would not waste time in deployment. There is after all a benefit of platform independence! But while this does seem to help the customer meet his deployment timeline, it does means that for every iteration on my product, as an ISV, I have to now do all that testing on integration, perf, security, etc etc. That means longer iteration cycles. That's bad - that means my product delivery lifecycle is now much longer. The other option is that I deliver lesser incremental value / iteration. I hate that. Either way, I have a much bigger effort / iteration. I really really hate that, coz thats more money! My customer hates that too. Because his competitor bought a .Net based product, whose next version came much earlier, and because of which he was able to launch a business initative earlier as compared to my customer.

Supporting multiple platforms as an ISV means higher cost and longer timelines. Our customers hate that. And so do we. Platform Independence is not helping us in our busines as an ISV.

c) Custom Solution: So for a product, platform independence may not look like such a great idea. But what about a custom solution? Let's see. Suppose I am a medium-sized company who has a team of six developers for in-house development. This team builds a Payroll application using Oracle / Websphere / Linux. We now want to move from Linux to AIX. What's the cost? First, get a build of WebSphere for AIX. Is that an extra cost? I am not sure. There should be. Next, get a build of Oracle for AIX. Probable extra cost again. Then the testing effort required. More effort, more time lost, more money. Effort, time and money that could have been spent delivering the next set of users requirement on the same solution, or in hardware to improve perf, or in integration (there is always an integration need!). Is this more money / effort / time than the cost / effort / time required to maintain two different operating systems? Absolutely!! And then the risk of breaking things ... the more mission critical, the less do you want to change platforms. I would never migrate a mission-critical solution from one platform to another.



3. But why not give a choice?
Fine, Vineet, all the reasons you have given do stand true for a port / migration. But I am not interested in a migration / port. I am not interested in the platform independence of the code that I write so that I can migrate / port it later. I am looking for a choice. Why not give me the choice of running .Net on Unix / Linux? I want to run my code on .Net on Linux. And I am not going to move it to another platform later on. Why not give me that choice?

Well, there are two options Microsoft has: a) Spend time / money / effort on making .Net platform-indpendent, b) Spend resources on making .Net on Windows real solid and keep innovating there. Microsoft thinks that its customers and partners get more value in the latter as compared to the former. The reason is simple: there are lot of hard problems which are higher priotity for technology decision makers:

a) Businesses want Higher Agility: Business is changing faster than ever. Across the globe. And getting increasingly reliant on IT, which is not keeping pace. Since my reliance as a business on IT is high, I typically want best of breed solutions. Or at least, best of what I can afford. Best of breed typically means that I don't care about underlying technology / platforms as long as it functionally delivers what I need. And I want the solution to be easily modifiable as my business-needs change very fast. Bottomline: as a business decision maker, underlying platforms / tech are not important. Business functionality is.

b) Integration is a bigger Imperative every day: Best of breed also means that business-solutions would typically come from multiple vendors. That means integration would not be built-in. That means integration would need to be done. And the underlying individual solution pieces would change as we just discussed while our integration continues. And the business process along which the integration is being built would change too. Oh, and let's not forget, the team who deployed / built the solutions is no longer around. Bottomline: I want solutions to work together no matter what platforms they are on.

c) System Complexity is Increasing: Points a) and b) obviously lead to high system complexity. The dream of ever having a homogeneous environment would remain just that - a dream. Meanwhile, increasing reliance on IT would mean that you would want self-monitoring, self-healing systems, automated capacity planning, data-center modeling, etc. Apps would increasingly have to listen to instrumentation data coming up from lower layers before taking decisions, and make instrumentation available to higher layers, monitoring environments to enable a much deeper play with the operational side of affairs.

d) Computing is Changing Rapidly: And while all this is happening, hardware is getting cheaper - computing cost, network cost and storage cost are falling rapidly. That means that the mission critical, ultra-sophsitcated app of yesterday would be common-place tomorrow. Moreover, these apps would still need to be developed by someone like me - an average developer, and not the re-incarnation of Donald Knuth. Unless we innovate in the plumbing, developers would not be able to take advantage of the easily available cheaper hardware. Then there is a giant new wave of hardware coming our way that is dramatically going to change how software is written. An example of this is multi-core. Chip manufacturers are only going to add more cores. To take advantage of these cores, software would have to be heavily parallelized. Writing parallelized software is not easy. Very few people get it right. Plumbing needs to be built to address this. There are several other interesting things, and they all need innovation. Lots of innovation.

So what do we have: I don't care about underlying platfroms, I want things to work together irrespective of their platform, I want apps that lend themselves to being managed well, and I want innovation to leverage the cheaper / next gen of hardware. Seems to be the innovation choice. Not the multiple platform choice.


4. Summary
The choice Microsoft has made is simple - focus on innovation and integrate its own stack as far as possible - and it has solid reasoning. There are other companies who have not made that choice. These companies depend on people for integration. Their revenue-model is highly services driven. This model allows them to outsource their customer's IT and that means predictable revenue. This revenue hopefully, can fuel the innovation required in their products over the next five years. Time would tell which model succeeds better. For myself, my own money is on Microsoft!