The Maturing of Linux Management

As Linux becomes a larger force in data centers, operational support emerges as a critical factor in determining long-term success. Treating Linux as a separate technology silo requiring individual management is not the answer. However, Linux does have some unique needs.

META Trend: Through 2005, users will seek to minimize the number of infrastructure and application management vendors for similar technology (e.g., one monitoring vendor). Through 2006, new infrastructure and service pricing models (e.g., subscription, usage, term), continuing capacity- and version-driven cost increases, and expiring enterprise agreements will cause buyers to reassess procurement efforts. The focus will be on more function-specific, loosely coupled, "good enough" suites built around Web services protocols.

Linux is here to stay. Data centers are continuing their adoption of Linux at an accelerated pace. The basic OS and hardware are no longer in question, so other forms of differentiation have emerged. This includes which additional services the hardware provider offers, how tightly the vendor is tied to the community, how vendor support processes work, and what kind of management is available.

The good news is that clarity is emerging on all fronts. Vendors are investing heavily in creating services (e.g., installation, Level 1 and Level 2 support, migration), which by 2005 will be the primary differentiators for hardware vendors. Leading vendors are tying tightly to the Linux community by acting as contributors, not just exploiters. The community is sensitive to this. If a vendor is perceived to be profiting on Linux without contribution, it is possible to view a different level of responsiveness to the vendor’s requests.

The decision organizations need to make now is where and how to get their Linux support. Do they get it from their hardware providers (e.g., IBM, HP, Dell), or deal directly with the distribution vendors (e.g., Novell, Red Hat) or a third party such as Oracle as an alternative? A contributing factor to the decision will be an evaluation of the organization’s existing support agreements with vendors. If there is a strong desire to minimize/consolidate vendors, then adding Linux to current agreements is advisable. Beyond that, the decision is based on price and perception of completeness of Level 1 and Level 2 support (e.g., call center). The reality is that, no matter which vendor provides Level 1 or Level 2 support, Level 3 support will be delivered by the distribution vendors (Red Hat or Novell), since they have agreements with all major hardware vendors.

Organizations must educate themselves on how fixes and support are executed. When a “hot fix” is required, the support vendor can quickly get it to the organization. However, the complexity is how the hot fix makes its way back into the mainstream distribution and how it is then tracked and delivered. The challenge is that, when a hot fix is sent back to the community, it is up to the support vendor to track when it is delivered to the distribution vendor and report it to the customer. Although this is very well-defined for the kernel, it is not as clear for other utilities. If an organization is not educated on how its support vendor executes this process, it may end up excessively patching, or worse, running a system that is not aligned with mainstream distributions. Although management is maturing, there are still some key considerations.

Should Linux Be Managed As a Silo?
Infrastructure and application management vendors have all addressed Linux. Most vendors (e.g., CA, Tivoli, HP) have added it to their mainstream product lines or even made it a Tier 1 platform, with some (e.g., BMC) offering Linux-focused tools. Even better news, the mainframe is also addressed (e.g., Candle, BMC, CA). Linux distribution vendors have identified management as a potential money maker, and each has management offerings that target Linux as a standalone management silo.

Patch management is one example of an area where organizations have addressed Linux as a silo. Currently, there are numerous patches for all Linux distributions. As Linux matures (2006), it will receive fewer patches, and processes will become more mature. All will reduce the cost of support. Organizations should not treat Linux patching as a separate patch process. Rather, it is part of the formal configuration management process and must be aligned with enterprise patch efforts. Although true Linux patching requires some different technologies, it does not mean that a separate process should be created. Organizations must use a common process that leverages platform-specific tools as necessary. Addressing it as a silo effort will increase the cost of support.

It is not recommended to treat Linux as a separate silo, nor is it advisable to invest in Linux-specific tools when they can be avoided (device administration is an area where Linux-specific tools cannot be avoided). Areas such as performance monitoring should not be addressed separately. Intelligent configuration management (e.g., provisioning) may require specific Linux tools, primarily if the vendor offers integration testing for distributions and third-party components. If it is not critical for that level of Linux-specific testing, a common tool can be leveraged. Such tools are usually supplied by the hardware vendor, and in the case of Linux, they are from the distribution vendor. In addition, numerous open source options are available.

A Unix system administrator team should be expanded to include Linux, and existing operational processes should be expanded to encompass Linux where necessary (e.g., change, incident, configuration management), but separate processes should not be created. Moreover, with Linux on Intel (Lintel) deployments, Linux leverages shared Windows on Intel (Wintel) platform configurations and adaptive resource management tools capabilities.

Should Linux Be Managed With Shareware or Enterprise-Class Tools?
This question can be easily answered if Linux is added to mainstream support, making use of the same enterprise-class tools that have been used across the organization. However, that is not the answer for all devices. We advise that all server resources be categorized and identify which carry mission-critical processing versus which are supporting functions (e.g., print servers). Leveraging lower-cost or open source management for lower-priority devices is advisable. The Linux community offers a plethora of low-cost or free management tools that can be explored (specifically for device-level administration), but most are not enterprise class and are better for small or non-critical environments.

For many small and medium businesses (SMBs), Linux may become the dominant platform. With fewer enterprise-class tools being used within SMBs, it makes sense to explore open source/shareware management technology for Linux. This assumes there are no conflicts with previously deployed management technologies.

Bottom Line: Linux is sought to save money and add flexibility. However, improperly addressing support and management needs will negate such benefits.

Business Impact: Linux will save an organization money only if it is handled properly across its entire life cycle.

META Group originally published this article on 1 April 2004.