January 2004 – These Dirty Colors

Microsoft .Net Is Bad for Your Enterprise

By jason | January 26, 2004

Microsoft’s .Net is quickly becoming, if it is not already, the dominant development tool, for lack of a better word, for the Windows platform. For the uninitiated, "Microsoft® .NET is a set of software technologies for connecting information, people, systems, and devices. This new generation of technology is based on Web services-small building-block applications that can connect to each other as well as to other, larger applications over the Internet." It is MS’s answer to Java. Where Java has byte code, .Net has Intermediate Language. Where Java has a JVM (Java Virtual Machine), .Net has the CLR (common language runtime). There are numerous organizations migrating to .Net, some even from the Java world. But is this a good choice? On the surface, you gain a good degree of security from the built-in garbage collection and memory management, reusable components that will reduce the amount of coding necessary for a given project, and a great development tool. But are these pluses worth it? I would posit that they are not.

Those of you who know me know where I currently work. In order to avoid associating them with ideas with which they may not agree, I won’t name them. Instead, we’ll say I work for Widgets, Inc. Here at Widgets, we rely heavily on IBM’s iSeries machines. We have a plethora of legacy RPG code and seemingly innumerable files, tables, spool files, CLs, and so on. Fifteen or twenty years ago, the decision was made to run the enterprise of the iSeries (then known as the AS/400). At the time, the dominant language on the iSeries was RPG (for reasons that I don’t know), so all of the custom coding was RPG code. At the time, it made perfect sense.

Let’s fast forward, now, to 2002. RPG programmers are hard to find, and can tend to be expensive. That being so, the management of Widgets, Inc. decide to do all new coding in Java instead of .Net. This gave us access to modern technologies, and hordes of developers. A year and a half later, though, after some small- to medium-sized projects, we reversed our decision because user interfaces are easier in .Net. Choosing ease of development (an edge that Java will soon remove with JavaServer Faces), we have set the ball in motion for RPG, episode two.

How, one might ask, does .Net compare to RPG? For the longest time, companies making investments in iSeries and RPG-based technologies could rest assured that they were making a wise investment, one that would continue to make business sense for a long time. Over the years, however, the iSeries began to decline in popularity (for a variety of reasons I won’t cover here). As it became more expensive, in terms of developers and long term risk, to invest in the iSeries, companies moved more and more to other technologies, such as Windows. This made the iSeries less attractive to others, and so the cycle repeats. Now, those companies, such as Widgets, Inc. that have a substantial investment in the iSeries, have hardware and software that is becoming increasingly difficult to maintain. Among their options are to maintain where they are and hope for the best, which is probably suicidal, or migrate to another platform, a path fraught with new bugs and lost opportunities, but probably one of the wisest options.

Now, let’s fast forward fifteen to twenty years in the future. While Windows is the dominant desktop operating system in 2004, while also holding a respectable position (in terms of numbers) in the server market, no one can know what 2019 will look like. With Microsoft under increasing pressure from rivals such as Linux and MacOS X (don’t laugh, more and more people are turning to Apple), that dominance can not be assumed to run ad infinitum (anyone remember the once proud and invincible big blue of the 60’s, 70’s and 80’s?). In fifteen years, we very well may find ourselves running systems predominantly based on Linux, or maybe even some other OS that currently exists only in some company’s R&D labs. Should that day come (and I feel it will. It’s just a matter of when), what are we to do with all of this .Net code?

Those on top of the .Net "community" will probably be quick to point out the Mono project or DotGNU, claiming that a cross platform .Net is on its way. To that, I would point to this article that talks about how Microsoft is patenting their Office XML file formats, so that they can restrict who and can do what with Office files. MS is patenting something that is standards-based as part of the business-as-normal process of blocking competition. Time will most likely show the heavy hammer of the Microsoft legal department falling on the efforts to the Mono and DotGNU groups as well. Even if that never happens, as long as Microsoft is not actively helping to port .Net to other platforms, these porting efforts will always lag behind the official product.

So where does that leave us? A whole bunch of nice, modular, object-oriented, garbage-collected code that runs on only one platform, but at least GUIs are easier to write. Every language has its problems. While there are things that are easier in .Net than Java, the inverse is also true. All that being said, though, if the decision to use .Net over Java is simply because UIs are easier, then the decision making process was extremely short-sighted. In fact, in my mind, it’s not really even a .Net vs. Java question. It’s a question of portability. Given the speed of modern languages and systems and what we’ve learned over the past 40+ years in this industry, there’s no reason why we should let any vendor tie us to their platform, whether that vendor is Microsoft, Sun, Apple, or Red Hat. With regards to .Net vs. Java, since their capabilities are so similar and run time benchmarks show that they run about as fast as each other, there must be something to tip the scales. If you ask me, IT managers should lean toward platform independence, and leave their enterprise room to maneuver should its vendor of choice start making decisions adverse to the enterprise’s goals and capabilities. If you’re not tied to your vendor’s platform, you can’t be strong armed into making decisions you don’t want to make. With .Net, though, you’re tying your own hands.

Black Thursday

By jason | January 15, 2004

Black Thursday has arrived. It’s a day I was expecting, yet hoping could be avoided. Oh, I didn’t know what day of the week it would be — it could just as easily have been Black Wednesday — but I knew it was coming. Management kept dropping hints. Licensing costs, alternative pilots, architectural changes. And, tragically, the day has arrived. The announcement has been made. The death knell rung. The wake cancelled. What might this tragic news be? My management (if you know who I work for you, you can fill in the details yourself) announced today that we are reversing our original decision to proceed with all new development in Java, with our new direction to be tied to Microsoft’s .Net. "What’s wrong with that?" one might ask. Allow me to expound.

Those of you in the technology field may look at my distaste for Microsoft products and write me off as a Linux zealot. After all, Microsoft puts out a quality product, right? Wrong, I think, on both counts. First off, I’m not a Linux zealot. I am, though, a huge fan. I have installed and run Linux boxes at my current job, as well as my last one. I also run it almost exclusively at home. Personally, I find Linux to be much more fun and rewarding than a Windows experience. Professionally, I feel you should select the best tool for the job (which can be a difficult metric to define and evaluate), and I have seen precious few scenarios where a Microsoft solution makes better sense.

As far as the quality of Microsoft’s products goes, I think the facts speak for themselves. For those who have used MS offering exclusively, you’re probably pretty happy and impressed with the current crop. They’re more powerful and more stable than past versions. Your assessment, I think, is correct. However, when you compare what MS offers to what other vendors, not just Linux (which isn’t actually a vendor, but work with me here), have to offer, and you’ll begin to see a vast disparity in terms of quality, security, stability, and reliability. Microsoft got where it was by being first. With the leg up that Big Blue gave them, they were the first to offer an operating system for the PC platform, which was cheaper (and still is) than the possibly superior offerings from Apple, among others. They maintain where they are by sheer monopoly force. Windows needs regular reboots to maintain sanity, and is prone to viruses and worms. Exchange and Outlook are high-priced vectors for "email" viruses (which should be termed Outlook viruses, as no other mail clients are affected). Office is over-priced and bloated, and has its own demons to fight with regards to viruses. While no software package is 100% secure or perfect, but Microsoft products, as a general rule, trail the pack.

So what does this have to do with my current employer? The decision was made to upgrade to Exchange 2003, but to do that, we need to upgrade to Active Directory. To do that, we either go through severe pain and anguish in trying to migrate our Win2K domains to AD, or install Windows Server 2003. The result of that decision is left as an exercise for the reader. This highlights the Microsoft business model nicely. "If you want to run the new version of Foo, you have to upgrade to the latest version Bar." With the level of integration Microsoft demands, which apologists applaud, installing the latest version of a Windows product strengthens the stranglehold Microsoft has on said enterprise. Being beholden to any one company, whether it’s Microsoft, IBM, Novell, or Red Hat, is not a good business decision, as now your enterprises are tied to the whims of your provider of choice.

Furthermore, too much from one company produces a monoculture, a scenario that security experts decry as dangerous. For example, with Microsoft sharing so much code (as well as tying non-essential systems like web browsers to the operating system) a flaw in a given piece of code will affect every product that uses that code. Let’s say, for example, that there’s a remotely exploitable bug in the authentication code in SQL Server that allows an attacker to gain system privileges. Now, for the sake of argument (as we have no real way of knowing) that Windows, Exchange, ISA, and every other Microsoft product uses the same piece of code to handle authentication. What does that get us if your shop is Microsoft-bound? A vulnerability on every server and desktop in the enterprise. On the other hand, if your web server is Apache, your directory server is Novell and your email server is Oracle Collaboration Suite, you have limited your exposure significantly. Granted, such and extreme mix of vendors can make managing an IT shop more difficult as you have to maintain a wider variety of skill sets, but security is not, nor will it probably ever be, easy or cheap.

So where does this leave my shop? In my opinion, heading down the road toward a life of constant updating and patching, forever running the Microsoft upgrade treadmill. Since it’s usually cheaper to upgrade than migrate, once you make a commitment the size we are making now, you are most likely forever tied to that vendor, and that will spell problems at some point. Will we be bitten by this? Time will tell, but if I were a betting man, it’s going to take just one new virus or exploit to sneak behind the firewall, and we’re going to rue this day.