In todays slashdot there is story about Novell and its vision. Well I did developing a Linux infrastructure based on SLES9, well almost did. This was about a 1..1.5 years back when Novell merged with SuSE Linux. The first 6 months were fine, the autoyast feature was pretty good at profiling servers. The simple XML structure was manageable and debugging was pretty simple. We developed an in house server registration and profiling app that worked pretty well. Creating and managing in house repository was also pretty straight forward, but it lacked the simplicity of apt/yum. When moving a repository you first had to remove the old one and install a new one, instead just modifying the config files and sending them out. The delta rpm feature was usable, but a bit clumsy as it needs the original rpm to witch the delta is applied (for large packages can slow down the server allot - wont recommend doing it on live systems). Here the problems started. First was that the patch file structure was not well defined, so creating in house rpm updates, so the packaging process was slow. Then came the problem that our update script was unable to mirror the repositories to our in house server. For about a month or tow the Novell experts called and came on site and debugged what was wrong. Well after a really depressing day I did some ethical hacking/reverse engineering to find out what is wrong I found out that Novell had switched their server to a Zenworks server. Well... offcorse nothing worked, since the Zenworks server expects special header tags in each request. Uhh ahh.. a day later we had the Zenworks mirror up and running. The problems didn't stop here. The Zenworks repository is completely different from the normal YaST repository. Well after digging into the repository documentation depths I went and a week later and about 1000 rows of perl we had an (almost) working YaST repository. It worked around 4 months and then Novell decided to change something inside and I want able to reverse this code, so out went Novell... Novell offcorse provided us a solution - use Zenworks and they were happy to sell use 80 licenses. why 80 licenses? Well, we have around 80 geographically remote branch offices with low links and if the repository admin would put for example an kernel update to central repository there would be a gap of around 2 days wen all the workstations would have downloaded the package from central repo and that is not acceptable. So out went Novell and in came RedHat Enterprise Linux 4. Another year later we have a working RH infrastructure. So the problem is not with what is cheaper, but what decision to make when. Usually managers are not very tech savvy and base their decisions on the numbers without seeing the big picture as what will it cost to develop and maintain.
As a side note you may ask "Why not go with fully open source, like debian and ubuntu?", well the answer is not that simple. Firstly Debian and Ubuntu are very good distros, I personally have nothing against them, also they are totally free with good community support. Now the downside, they lack profiling methods. For them to mature to enterprise level they firstly need a similar profiling method like autoyast or kickstart. They also need to change their configuration logic a little. Since profiling usually sets some specific config files and applies them to templates to get the real configuration files. This is not a very big change but still.. So far I have seen "automated" installations based on script files run while installing - a one mistake will take out the whole install, or create partially configured servers/workstations. The other is that most enterprise level Linux developers are used to a RPM package format and debian uses DEB - so there will be a big learning curve to relearn how to package debs.
So for the conclusion: Windows is not cheaper than Enterprise Linux's - everything depends on the needs of the enterprise and the communication between the managers and the people that will develop and run them. Also a developer/head developer and an administrator/head administrator needs to be included when discussing the purchases of new platform as they usually ask questions that will make it a success or a failure. Also don't make rash decisions based just on the numbers.
technorati tags:Novell, Microsoft, Linux
Blogged with Flock
No comments:
Post a Comment