Monday, November 06, 2006
Vendor lock-in, my reality
Freedom from vendor lock-in is one of the louder themes in the criticism in this post Novell/Microsoft-deal world. Free and Open Source Software (FOSS, learned that one this week) is all about avoiding vendor lock-in. Linux comes in the wide flavors it does so that vendor lock-in doesn't have to happen.
Here is how I view vendor lock-in as a part of my job. This is coming from a system administrator who manages in a largish regional enterprise. Both this job and OldJob didn't have significant WAN links, but we did have well over 1000 users to play with.
Both my old job and my new job saw significant savings by sole-sourcing server hardware. OldJob was a Dell shop pretty completely, with a very, very few Compaq hold-outs. Here in Technical Services we're a very solid HP shop, with some Dell thrown in as we inherit systems from other departments. Both old and new jobs had some Solaris around for various things. At OldJob we didn't use OpenManage much at all. Here, we're not really using OpenView.
Both companies realized that whiteboxing, building servers from component parts and supporting things internally, was a losing idea at the scales both jobs built out at. Having a single vendor support us for server hardware eased support costs and made the internal knowledge-base required to support our hardware much less complex.
OldJob used to be a Compaq shop, but dropped it in favor of Dell due to and I quote directly, "all of that proprietary crap." The fact that Dell was a lot cheaper at the time also helped significantly. As I understand it, Technical Services was that rarity, a HP shop. The Compaq merger was viewed with some dismay in certain parts. This is why we have some HP LH3's stacked against one wall.
As for operating systems, OldJob and NewJob had different ideas. One of the reasons I left OldJob was a decision from the top of IT management to unify on a single Directory; Microsoft's. How that would interact with GroupWise, which was VERY firmly established in the enterprise and not being moved out, was a complete mystery to us techs who would eventually be asked to make it work. Accompanying this decision was the directive to start migrating the NetWare servers out in favor of Microsoft Windows. They were reducing support costs by reducing the number of OSs in the datacenter.
WWU works differently. They've had a 'best of breed' philosophy for services for some time, and NetWare is still king for File Serving performance. Solaris was king for Oracle for a long time, though that throne is in a bit of question at the moment. Linux has started creeping in as an application server a few places, so far just web-servers (the web-server that drives the time-card web front-end is Linux, with a Solaris/Oracle back end).
One of the differences between my old environment and this environment is budgetary. OldJob had a strict three year replacement cycle for servers, that they were thinking of extending to 3.5 or 4 yeaers to better handle server swaps (3-6 month stage up and migration, 3-6 month demigration and stage down). WWU plans on keeping servers in some form of production for 5 years, though the last one to two years may be as a dev server rather than mainline production. The same sort of pressures happen on the software we use on the servers, as we're more likely to use OSS than we were at my old job.
That said, when it comes to package management on the Solaris and Linux servers we rarely go outside of the vendor for packages. I know we compile Samba from source on Solaris, but then we're using an old Solaris version that doesn't do what we need out of the box very well. If it isn't on the Solaris or SLES9 repositories (we don't have any SLES10 in yet), we probably won't deploy on that.
Our OS vendors are Microsoft, Novell, and Solaris. Other departments use Gentoo, Slackware, and I'm sure some Ubuntu and Red Hat.
All that said, we do deal with, and embrace, vendor lock-in. We do it in hardware. We do it in software, as our Help Desk software only runs on a Windows/IIS stack (though can do MSSQL or Oracle as a DB source). We do it in file serving OS, as it would be a royal pain to use anything but an NCP server from Novell on NetWare (even OES-Linux presents some problems). We do it in small-office databases, which are all housed on an MS-SQL server (we can do oracle, but it is a pain and the processes are not well established or documented).
We also embrace diversity. Our HelpDesk app requires Windows/IIS, but our student email web-access app required Apache/PHP. Web-serving is perhaps our most diversified environment, as we are widely deployed in both Apache and IIS based technologies. Several main line applications are java driven, others are driven by ASP, still others use PHP.
When it comes to an OS we'll use on mainline applications, we have to have enterprise support. This means buying our OS from a firm that can provide 24x7x365.25 support. This reduces the number of firms we can purchase Linux support from. Additionally, we need some form of patch management system. NetWare is the least well supported when it comes to patch management, as it is a 100% manual process, happily it doesn't need a lot of attention. We won't do NetWare-style patch management on Linux, as that method doesn't scale. In effect we're limited to Red Hat or Novell for Linux, and as we already have a contract with Novell for NetWare support that's where we went. Furthering our lock-in with Novell.
So vendor lock in is really a fact of life here. I appreciate the fact that I can toss a Slackware server in amongst the servers and have a fair chance of making it work if I really need it to. But that'll be emergency processing, not standard procedure.
I'll leave what the Novell/Microsoft deal means in terms of the viability of Linux in the enterprise for another post.
Tags: novell, linux
Here is how I view vendor lock-in as a part of my job. This is coming from a system administrator who manages in a largish regional enterprise. Both this job and OldJob didn't have significant WAN links, but we did have well over 1000 users to play with.
Both my old job and my new job saw significant savings by sole-sourcing server hardware. OldJob was a Dell shop pretty completely, with a very, very few Compaq hold-outs. Here in Technical Services we're a very solid HP shop, with some Dell thrown in as we inherit systems from other departments. Both old and new jobs had some Solaris around for various things. At OldJob we didn't use OpenManage much at all. Here, we're not really using OpenView.
Both companies realized that whiteboxing, building servers from component parts and supporting things internally, was a losing idea at the scales both jobs built out at. Having a single vendor support us for server hardware eased support costs and made the internal knowledge-base required to support our hardware much less complex.
OldJob used to be a Compaq shop, but dropped it in favor of Dell due to and I quote directly, "all of that proprietary crap." The fact that Dell was a lot cheaper at the time also helped significantly. As I understand it, Technical Services was that rarity, a HP shop. The Compaq merger was viewed with some dismay in certain parts. This is why we have some HP LH3's stacked against one wall.
As for operating systems, OldJob and NewJob had different ideas. One of the reasons I left OldJob was a decision from the top of IT management to unify on a single Directory; Microsoft's. How that would interact with GroupWise, which was VERY firmly established in the enterprise and not being moved out, was a complete mystery to us techs who would eventually be asked to make it work. Accompanying this decision was the directive to start migrating the NetWare servers out in favor of Microsoft Windows. They were reducing support costs by reducing the number of OSs in the datacenter.
WWU works differently. They've had a 'best of breed' philosophy for services for some time, and NetWare is still king for File Serving performance. Solaris was king for Oracle for a long time, though that throne is in a bit of question at the moment. Linux has started creeping in as an application server a few places, so far just web-servers (the web-server that drives the time-card web front-end is Linux, with a Solaris/Oracle back end).
One of the differences between my old environment and this environment is budgetary. OldJob had a strict three year replacement cycle for servers, that they were thinking of extending to 3.5 or 4 yeaers to better handle server swaps (3-6 month stage up and migration, 3-6 month demigration and stage down). WWU plans on keeping servers in some form of production for 5 years, though the last one to two years may be as a dev server rather than mainline production. The same sort of pressures happen on the software we use on the servers, as we're more likely to use OSS than we were at my old job.
That said, when it comes to package management on the Solaris and Linux servers we rarely go outside of the vendor for packages. I know we compile Samba from source on Solaris, but then we're using an old Solaris version that doesn't do what we need out of the box very well. If it isn't on the Solaris or SLES9 repositories (we don't have any SLES10 in yet), we probably won't deploy on that.
Our OS vendors are Microsoft, Novell, and Solaris. Other departments use Gentoo, Slackware, and I'm sure some Ubuntu and Red Hat.
All that said, we do deal with, and embrace, vendor lock-in. We do it in hardware. We do it in software, as our Help Desk software only runs on a Windows/IIS stack (though can do MSSQL or Oracle as a DB source). We do it in file serving OS, as it would be a royal pain to use anything but an NCP server from Novell on NetWare (even OES-Linux presents some problems). We do it in small-office databases, which are all housed on an MS-SQL server (we can do oracle, but it is a pain and the processes are not well established or documented).
We also embrace diversity. Our HelpDesk app requires Windows/IIS, but our student email web-access app required Apache/PHP. Web-serving is perhaps our most diversified environment, as we are widely deployed in both Apache and IIS based technologies. Several main line applications are java driven, others are driven by ASP, still others use PHP.
When it comes to an OS we'll use on mainline applications, we have to have enterprise support. This means buying our OS from a firm that can provide 24x7x365.25 support. This reduces the number of firms we can purchase Linux support from. Additionally, we need some form of patch management system. NetWare is the least well supported when it comes to patch management, as it is a 100% manual process, happily it doesn't need a lot of attention. We won't do NetWare-style patch management on Linux, as that method doesn't scale. In effect we're limited to Red Hat or Novell for Linux, and as we already have a contract with Novell for NetWare support that's where we went. Furthering our lock-in with Novell.
So vendor lock in is really a fact of life here. I appreciate the fact that I can toss a Slackware server in amongst the servers and have a fair chance of making it work if I really need it to. But that'll be emergency processing, not standard procedure.
I'll leave what the Novell/Microsoft deal means in terms of the viability of Linux in the enterprise for another post.
Tags: novell, linux
<permalink> posted by riedesg : 11/06/2006 10:37:00 AM
