Thursday, November 10, 2005

 

Why enterprises may never adopt LAMP

Last week, I was at the Open Source Business Conference where a member of the audience asked a question regarding getting enterprises to adopt LAMP. The panelist provided an answer which I felt was insufficient and therefore figured I would provide my own perspective...



LAMP has become a defacto-standard around the web community in the recent years but hasn't been adopted in corporate America in any way worth mentioning. LAMP is the combination of Linux + Apache + MySQL + PHP. In order to understand the lack of adoption, it is important to look at each component separately:

GNU Linux

The name "Linux" is used to refer to three similar yet slightly different things, which can be confusing to all but the hardcore geek who more than likely isn't employed in corporate America. At the lowest level, every Linux system is based on the Linux kernel — the very low-level software that manages your computer hardware, multi-tasks the many programs that are running at any given time, and other such essential things. These low-level functions are used by other programs, so their authors can focus on the specific functionality they want to provide. Without the kernel, your computer is a very expensive doorstop. It has all of the features of a modern operating system: true multitasking, threads, virtual memory, shared libraries, demand loading, shared, copy-on-write executables, proper memory management, loadable device driver modules, video frame buffering, and TCP/IP networking.

The second perspective on GNU Linux refers to the Operating System. An OS includes the kernel, but also adds various utilities — the kinds of programs you need to get anything done. For example, it includes a shell (the program that provides a command prompt and lets you run programs), a program to copy files, a program to delete files, and many other odds and ends. Some people honor the request of Richard Stallman and the GNU Project, and call the Linux OS GNU/Linux, because a good number of these utility programs were written by the GNU folks. This perspective is the proper one that enterprise architects need to start acknowledging but fundamentally won't occur due to the clowns in the media who create industry rags and prefer commercial (aka tainted) definitions.



The third perspective is the one pushed by commercial entities such as Novell, RedHat and so on which refers to the distribution. A distribution may include tons of extra software, games and other applications that really have nothing to do with the base operating system. In fact, many of these can contain a variety of disparate licensing schemes all on the same CD which can expose the enterprise to more risk than they had planned.

Of course, the main reason folks buy from commercial entities is the notion of indemnification. I wonder what would happen if a bunch of corporate lawyers figured out that in purchasing commercial distributions of Linux and the fact that they contain multiple competing licensing schemes on the same CD would scare them back to Microsoft? Of course, I wouldn't let this happen and believe a better answer may be for enterprises to create their own distributions but this is a topic of a future blog entry.

Anyway, the role of an enterprise architect is to enable the strategic intent of the business through the use of information technology. Operating systems do not enable strategic intent. They are commodity and pretty much don't provide any form of competitive advantage. The best one could hope for is a minute amount of cost savings which in my humble opinion is distracting. There are better uses of energy within the enterprise than pursuing strategies around Linux.



Apache Web Server

I use Apache at home for a variety of sites I run on the side but would absolutely never recommend it for corporate usage. While it scales well and is stable, it is damn hard to configure to work within a corporate environment. In order to get it working in large-scale enterprises it would require them to hire folks who actually know what they are doing. These types of folk want more money than corporations are willing to pay. Commercial vendors on the other hand understand this truth and focus on productivity enhancing tools by putting wizards into their products such that any moron could get them working.

If Apache came with more plugins as part of the distribution, then I would be game to recommend. Minimally, it should come bundled with MOD_JK and MOD_JK2 such that one could easily connect to a J2EE container such as JBoss that would be a good first step. Likewise, have you ever attempted to connect Apache to commercial security products such as Netegrity SiteMinder? It is painful...

MySQL Database

Has anyone ever attempted to migrate from one database vendor to another? This is a pain that I wouldn't even wish on Bin Laden. Enterprises have absolutely zero appetite for the pain and even if they did, the work effort involved in converting would cost more than the underlying savings.

The pain of database conversion can be reduced though. While a commercial product, the folks over at Ants have a solution...



PHP

Here is comes a surprise. Enterprises don't choose the languages they code in, it is chosen for them. With the savage practice of purchasing commercial packaged software coupled with the desire of enterprises who can't excercise restraint need to customize the snout out of packages they purchase and do so in whatever language the software vendor chose to write it in. In days of old, it used to be COBOL, nowadays it is more than likely Java.

If the community can convince SAP, Oracle, Microsoft and IBM to develop enterprise applications in PHP then corporations will adopt it, otherwise so long. Maybe folks in the open source community may be well served by understanding enterprise architecture...








<< Home
| | View blog reactions


This page is powered by Blogger. Isn't yours?