STAKEHOLDER



[pic]

Pinellas County

Business Technology Services (BTS)

Linux Server Operating System (OS) Technology Consolidation – Survey Results

Version 2.0

Prepared by BTS Enterprise Technology Services (ETS)

December 2008

Table Of Contents

Overview 3

External Survey Summary 5

Internal Survey Summary 6

Conclusion 7

Appendix A – External Survey Responses 8

Appendix B – Internal Survey Responses 13

Overview

Despite numerous efforts, the preparers of this document were able to find very little objective qualitative comparison between the Linux SuSE/SLES and Red Hat Operating Systems. In an effort to fairly compare the technologies, two surveys were conducted:

• External Survey

With the assistance of John Becker (OMB), we were able to identify seven Florida counties of similar size to Pinellas County:

▪ Broward

▪ Jacksonville

▪ Hillsborough

▪ Miami-Dade

▪ Palm Beach

▪ Orange

▪ Sarasota

With the assistance of Richard Ginski (Security/BTS), we were able to identify three additional government entities:

▪ City of Largo

▪ City of Tampa

▪ Tampa International Airport

The survey questions were:

    1.    What server operating systems does your IT/IS Department support?  

    2a.    Do you support database servers running Linux?

b. If so, what versions of Linux?

      c.    Any issues associated with running DB servers on Linux?   

    3a.    Do you support middleware servers running Linux?

b. If so, what versions of Linux?

      c.     Any issues associated with running middleware servers on Linux?

    4.    For each Linux platform, how many servers are maintained?  

    5a.    Have you prepared any studies comparing your Linux platforms?

b. If so, would you be willing to share your findings with us?

    6.    If you support multiple versions of Linux for servers and wanted to consolidate

technologies, which technology would you choose? Why?

• Internal Survey

We identified the following BTS internal stakeholder groups impacted by the Linux OS technology consolidation:

▪ DBA Group

▪ Intel Group

▪ Linux Group

▪ Middleware Group

▪ Network Group

▪ Security Group

▪ Storage Group

The survey questions were:

1. Are there any distinct advantages associated with supporting a server running SuSE/SLES vs. Red Hat?

2. Are there any distinct disadvantages associated with supporting a server running SuSE/SLES vs. Red Hat?

3. Are there any other points associated with either technology that should be considered in this evaluation?

External Survey Summary

For the External Summary details see Appendix A.

|ORGANIZATION |# OF SERVERS RUNNING | |CONSOLIDATION |

| |RHEL 3 |RHEL |

| | |4 |

|DBA |- Poor Level of Service |+ Oracle Support for Red Hat |

| |- Poor Timeliness of Resolutions |+ Fewer DBA SUSE/SLES Server (4) to be rebuilt vs. Red |

| |Affected IT Project Schedules |Hat Servers (13) |

|LINUX | | |

|MIDDLEWARE | | |

|INTEL |+ Supports OES |+ More online support forums |

| |+ Leverage Novell investment from other | |

| |products | |

| | |+ Vendor Support more familiar with Red Hat |

| | |+ More vendors competent supporting Red Hat |

| | |+ More training options |

|NETWORK | |+ Currently there is a network application that is not |

| | |supported by SuSE/SLES and is supported by an old |

| | |version of Red Hat |

|SECURITY |+ Purchase Price |+ Superior Support |

| | |+ Better Patching |

| | |Longer wait time for patches = less secure |

| | |+ More Solutions |

| | |ISV’s support the more popular platforms |

| | |More COTS solutions support Red Hat |

| | |+ Lower COTS Pricing, Higher Quality |

| | |Competition between ISV’s drives price down |

| | |+ Lower Labor Costs |

| | |Ease of use and better support = lower BTS labor costs |

|STORAGE |+ Purchase Price |+ Multipath easier to configure |

| | |+ SAN boot easy installation |

| | |+ iSCSI Support |

| | |iSCSI is more cost effective than fiber channel. There is the |

| | |potential to save money. |

Conclusion

The External Survey feedback was limited. Of the parties polled, ten responded (representing five of seven counties).

• Four of the five responding county agencies employ Linux servers.

• Only one county had consolidated to one version of the Linux OS (Red Hat), citing support, in-house expertise and compatibility as the reasons behind the decision.

• Only three counties polled employed a significant number (50 +) of Linux servers.

The Internal Survey indicated a strong preference for the Red Hat Linux OS.

Appendix A – External Survey Responses

DETAILS

| |1. What server operating systems does your IT/IS Department support? |

|DBA |Are there any distinct advantages associated with supporting a server running SuSE/SLES vs. Red Hat? |

| |ADVANTAGE FOR Red Hat FOR ORACLE DATABASE SERVERS: Oracle Corporation’s expertise is in Red Hat. Oracle has staff |

| |that knows the internals of Red Hat because it offers its own flavor of Red Hat. |

| | |

| |Are there any distinct disadvantages associated with supporting a server running SuSE/SLES vs. Red Hat? |

| |HISTORICAL DISADVANTAGE FOR SuSE/SLES: in 2007 the linux server staff experienced issues with the level of service and|

| |timeliness of resolution from Novell. Please refer to Jeff Scarsbrook’s document “RHEL over SuSe_08072007.doc” |

| | |

| | |

| |HISTORICAL DISADVANTAGE FOR SuSE/SLES: In 2007, server/dba staff reached a roadblock in that Sles 10 had issues |

| |that went unresolved for months that prevented Oracle 10g database servers from being built out with Sles 10. i.e. |

| |project schedules could not be met. Please refer to Jeff Scarsbrook’s document “RHEL over SuSe_08072007.doc” |

| | |

| |Are there any other points associated with either technology that should be considered in this evaluation? |

| |AMOUNT OF TIME FOR SERVERS TO BE REBUILD BY BTS DBA AND LINUX GROUPS DEPENDING ON WHAT THE FINAL STANDARD IS: |

| |-If Red Hat is selected 4 SuSE/SLES database servers will need to be rebuilt. |

| |-If SuSE/SLES is selected is 13 Red Hat database servers will need to be rebuilt. |

| |(see OS_Count_TS0001_08122008.xls) |

|Linux | |

|Middleware | |

|INTEL |Are there any distinct advantages associated with supporting a server running SuSE/SLES vs. Red Hat? |

| |None other that OES services from Novell running on SLES. |

| | |

| |Leverage Novell investment from other products |

| | |

| | |

| |Are there any distinct disadvantages associated with supporting a server running SuSE/SLES vs. Red Hat? |

| |There are many more forums and support sites online that support Red Hat. It is often easier to get feedback from |

| |user groups. In this country most technology companies provide support for Red Hat Linux before supporting SUSE/SLES |

| |Linux. The technical support personnel from the vendor are generally more familiar with Red Hat Linux. |

| | |

| |Red Hat is a market leader and because of this has broader 3rd party support and more training options |

| | |

| |Our staff has had more success and a generally better opinion of Red Hat |

| | |

| | |

| |Are there any other points associated with either technology that should be considered in this evaluation? |

| |What are our current vendors most comfortable supporting? I believe in most cases, with Novell being the exception, |

| |our vendors are more competent supporting Red Hat. |

| | |

| |Cost of time for migration of current standards to proposed new standards. |

| | |

| |True cost of support, IE if SUSE support is less expensive but not responsive is it really a better value? |

|Network |Are there any distinct advantages associated with supporting a server running SuSE/SLES vs. Red Hat? |

| |From a Network & Telecommunications perspective, there is no real difference in supporting either OS. We do have a |

| |server that uses an older version of RH due to vendor support for RH only and at a older version. |

| | |

| |Are there any distinct disadvantages associated with supporting a server running SuSE/SLES vs. Red Hat? |

| |From a Network & Telecommunications perspective, there is no real difference in supporting either OS. |

| | |

| |Are there any other points associated with either technology that should be considered in this evaluation? |

| |None. |

|Security |Are there any distinct advantages associated with supporting a server running SuSE/SLES vs. Red Hat? |

| |The only one I can think of is that transition costs to another platform would be avoided. But transition costs are |

| |“fixed costs” which, like licensing costs, “evaporate” over time. |

| | |

| |Licensing costs appear to be less on the SUSE side. |

| | |

| |But the support issues/problems and labor issues (variable costs that accrue indefinitely over time) with SLEZ would |

| |continue. Over time, this factor would outweigh initial fixed costs (licensing and transition). |

| | |

| | |

| | |

| |Are there any distinct disadvantages associated with supporting a server running SuSE/SLES vs. Red Hat? |

| | |

| |Yes! |

| |Better Patching |

| |Patching on the current platform will continue to have more of a delayed-affect and the County will be more |

| |exposed/less-secure, due to proprietary elements in the SLEZ distro. We should be able to take patches made-available |

| |by the Linux community and install them directly on our Linux systems without having to wait on vender to tweak it so |

| |that it will work on their distro. If a vendor (Novell) has to take these patches from the Linux community and then |

| |covert them to their SLEZ distro so that it can be installed on SLEZ, it will increase our length of exposure making |

| |us less secure. For example, current distros of SLEZ do not contain the latest open source code from the Linux |

| |community. More specifically, I know that SNORT NIDS, included with SLEZ, is at least two versions behind what is |

| |available by the community. Not good. |

| |More Solutions - Better Support |

| |Our department strategy is to re-use, buy, then build as a last resort. This essentially means that the bulk of new |

| |technologies/new solutions will be purchased if we don’t already have them. SUSE and Novell have long been a niche |

| |market in the US which comes with disadvantages for them and their customers like us. We have been held back and our |

| |hands have been tied by staying with them |

| | |

| |More Solutions: |

| |ISV’s support platforms that give them the best opportunity of making revenue. Therefore, from personal experience, |

| |ISV’s support the more popular platforms first in order to maximize revenue. Then, they later “port” to other distros.|

| |Their solutions, which are ported-later to other distro’s, tend to be less reliable because there is less focus/effort|

| |on those other distros. This negatively-impacts our agility. The other distro’s that are later supported are almost |

| |treated as an after-thought by ISV’s which results in support issues on these niche platforms from ISV’s. |

| | |

| |Further, ISVs’ support agreements typically-don’t support Linux as a whole. ISV’s typically will only support specific|

| |distros of Linux. |

| | |

| |More COTS Solutions: |

| |Given all of this, due to the strength and market presence of Red Hat (which includes RHEL, CentOs, and Fedora), has |

| |resulted in more of the mainstream ISV’s (Independent Software vendors who provide COTS solutions) supporting Red Hat |

| |than any other distro. This results in more solutions being made available on Red Hat platforms and therefore, |

| |more-diverse solutions that BTS can offer to their customers. This would place us in a stronger competitive position. |

| |When, in a number of cases, only one solution from one vendor is available for a given distribution, this places BTS |

| |and their customers in a weak and undesirable position. Finally, the customer essentially looks elsewhere because BTS |

| |limited what solutions they can provide their customer. |

| | |

| |Lower COTS Pricing, Higher Quality |

| |Further, if using more-popular distros, there is more competition among ISV’s. “Economics” dictates that more |

| |competition results in lower ISV pricing (for COTS) and higher-quality. This results BOTH the customer and BTS |

| |“winning” in these scenarios due to lower pricing and higher quality solutions. In the past, we have not been able to |

| |take advantage of this scenario because we have been involved with “niche-players”. |

| | |

| |Lower Labor Costs: |

| |This needs more analysis. But I believe the key argument in this whole issue is labor cost. Unfortunately, ETS has not|

| |been tracking labors hours spent on SUSE vs. Red Hat. Without gathering this vital information, cost analysis, in |

| |general, can not be determined. You can’t just compare licensing costs here. Licensing costs are fixed costs and fixed|

| |costs “vaporize” over time. The labor costs are significant variable costs that will continue to exist as long as you |

| |have the technology. Bottom line, fixed costs eventually “go away” over time, variable costs remain with you. So |

| |variable costs are really where the focus should be. |

| | |

| | |

| | |

| |Are there any other points associated with either technology that should be considered in this evaluation? |

| | |

| |Service Provider of “Little Choice” |

| | |

| |Whether is has been Novell’s OS, SUSE, or other products being offered by Novell, there have been many times I have |

| |heard the statement “we’re waiting on Novell” to either resolve a problem or to provide functionality that other |

| |solutions already have in production (and Novell claims is in theirs but does not work). This has been occurring since|

| |I have been working here (11 years or so). |

| | |

| |Given this, there have been indications that Novell struggles with sustainability. For example, they have released |

| |products which are incomplete, example: Novell’s certificate authority where a component critical to its functionality|

| |was not even included (CRL’s, certificate revocation lists in order to disable certificates that are distributed). Or |

| |when they released NAM with a “logic bomb” still included in their “production product” where NAM died on us, due to |

| |the logic bomb. This not only negatively-impacts our service offerings but increases costs and damages our reputation.|

| | |

| |Although the company has been around for decades, they still operate very much like an immature company. |

| | |

| |They also continue to struggle financially by incurring more losses than they do profits. For BTS, this is not a good |

| |indicator of long-term sustainability (one of our principles). Granted, their Balance Sheet may show Novell’s |

| |“liquidity”, but that is not an indicator of profit/loss. (Their Income Statements indicate profit/loss). Further, |

| |mathematically speaking, Novell’s liquidity will disappear if they continue to sustain losses. |

| | |

| |In order for us to be the “Provider of Choice” we need to use “Vendors of Choice”. At some point, as the BTS |

| |organization matures, BTS will be only as good as the vendors they have chosen to work with. If we have to compete |

| |with other providers who are using “better vendors” (who are providing more/better solutions) we will lose “in the |

| |face of competition”. |

| | |

| | |

| |Comparison Over Time: |

| | |

| |Instead of a 3 year comparison, we need to realistically consider how long we will be leveraging this technology once |

| |the decision is made to go in a certain direction. For example, most of our platforms have been around for 10+ years. |

| |I would think a similar length of time would need to be utilized when comparing the two options and their relevant |

| |costs over time (10+ years). |

|Storage |Are there any distinct advantages associated with supporting a server running SuSE/SLES vs. Red Hat? |

| |Yes, the SuSE/SLES software license is cheaper. |

| | |

| |Are there any distinct disadvantages associated with supporting a server running SuSE/SLES vs. Red Hat? |

| |Yes, SuSE’s multipath and san boot installation isn’t built into the native SLES install (Requires extra |

| |configuration) |

| | |

| |If a San volume is added to the server, it has to be rebooted. |

| | |

| |No iSCSI support |

| | |

| |Are there any other points associated with either technology that should be considered in this evaluation? |

| |Red Hat incorporated Multipathing and San booting in the native Red Hat installation |

| | |

| |Red Hat has iSCSI support |

| | |

| |If a San volume is added to a Red Hat server it does not require a reboot. |

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download