Wipro is a technology consulting
firm that benefits from a "strategic alliance" with Microsoft,
including "building financial models and ROI calculators for Microsoft
product deployments" and "co-product development and engineering of
Microsoft products". They're about as deeply enmeshed with Microsoft as
a company can be without actually being owned outright. Wipro is even
engaged in "managing call center operations for Microsoft product
support" and ".NET evangelism with focus on enterprise and mobility
applications". In other words, Wipro's business model is tightly tied
to developing, maintaining, and marketing Microsoft product lines and
services. This is anything but independent. For more detail, check out
the Wipro Technologies website: Wipro ? Microsoft: a strategic relationship

Recently,
Microsoft commissioned a study of patch management costs, comparing
Windows platform patch management with open source platform patch
management. Considering the above explanation of the relationship of
Wipro to Microsoft, and the fact that Microsoft commissioned the study
and reported the results, I suspect you can guess whether or not the
study favored open source software for patch management costs. Once
again, a Microsoft-commissioned study performed by a company that is
little more than a Microsoft lackey shows Microsoft undercutting the
cost of software that can be had for free. Go figure.

The study
results, in a little more detail, indicated that the patching costs
were very competitive between the Microsoft platform and the open
source software platform. It was admitted in the study that Microsoft
systems required more patching, but this is supposedly balanced by the
fact that the per-unit cost of patching for Microsoft systems was
lower. Of course, it's also claimed that patching is easier for Windows
systems ? a subjective, qualitative statement that cannot really be
statistically demonstrated in a study, and can thus be safely spouted
without worrying about the facts disproving the claim. When pinned down
on such issues, of course, Microsofties will always fall back on the
old "Windows GUIs are better!" argument. In my own experience, a simple
shell or Perl script handling sorting and distribution of apt patching
on Debian systems (for example) is about as easy as it can possibly get.

This
study, of course, actually compared corporations that use third-party
patch management software for organization and distribution of software
patches. These third-party solutions cost money to use, of course.
Interestingly, the per-unit per-patch cost that showed Microsoft's
stuff being cheaper used the same back-ends as the open source
software. Why is the per-patch per-unit cost lower? Simple: more
Windows systems were required for performing to similar standards.
Since the back-end cost was for the network, and not for the individual
units, where Windows systems require more computers in place the
per-unit cost involves a smaller division of the total cost over the
larger number of units, leading to a lower "per-unit" component of the
cost. Add to that the fact that patches are more numerous for Windows
systems than for Linux systems, and the "per-patch" component of your
cost is lower as well, because of similar division of cost between
instances. Considering that the per-patch cost division occurs on each
individual unit, that means that your total manipulation of cost
figures to produce "per-patch per-unit" costs involves dividing the
total cost by a number reached by multiplying the number of units by
the number of patches. Thus, the total cost of your solution is likely
more because of greater labor overhead (longer hours spent in
patch-management), but since that total cost for your network is
divided into such small numbers when divided by number of patches and
number of units, your per-patch per-unit cost can be significantly
lower. Thus, cleverly massaged statistics prove the sky is orange.

This would be why such
Microsoft-sponsored studies always examine per-unit costs for
distributed bulk services: multi-unit
services that only cost once can be whittled down when you split them
up over a larger number of systems, since a larger number is often
needed to achieve the same end results. Go figure. This turns the
real-world increase in financial and management resource expenditure
for a full-network solution into a decrease in resource expenditure for
each individual unit. So much the better for your study results if you
have to perform the same tasks over and over again, allowing a decrease
in expenditure for each iteration, though the total cost climbs.

Ultimately, none of this is all that
relevant to real-world costs. Real-world costs for actual patch
management and deployment are almost nothing for a knowledgeable
admin, regardless of the platform. What costs money and man-hours is
pre-deployment patch testing and post-deployment rollbacks and recovery
when patching goes awry ? and, of course, downtime from both
patch-related complications and the patching procedure itself. These
are, to the people who run these studies on the Microsoft paycheck,
irrelevant ephemera, but for those of us in the IT trenches they are
the meat and potatoes of the almighty TCO (total cost of ownership) and
administrative overhead (how much work and stress is involved in being
a system or network administrator).

Microsoft's track record in
post-deployment complications for new patches is legendary, and not
positive. The fact that most statistical analyses of system failures
during XP Service Pack 2 deployments performed by IT professionals were
in the range of 10-15% is just astounding. This sort of astronomically
high system failure rate after a patch purported to increase system
security and stability is simply unacceptable for most production
environments, and drives post-deployment recovery costs through the
roof for many administrators. Smart admins see a resulting increase in
pre-deployment patch testing because it simply becomes that much more
critical that patches are fully tested for potential problems before
deployment.

Then, of course, there's the matter of planned
downtime. Unplanned downtime is of course an incredible, and often
disastrous, addition to total cost of ownership for a given platform.
Planned downtime doesn't compare in terms of cost increases in most
environments. There's still an associated cost, though: even if
business isn't damaged overtly by planned downtime on the revenue side,
downtime of any kind tend to involve increased costs where such
concerns as the salaries of admins and contractors are concerned.

Almost
every single important patch applied to a Windows system requires a
system restart. The only time a system restart is required for a unix
system (such as Linux) patch is applied is when it's a kernel patch.
One of the major reasons for this is the system configuration scheme of
Windows, where all services are configured through a single flat-file
database. This is, to say the least, suboptimal for system uptime.

Time for some anecdotal evidence:

I've
never, in all my work as a consultant, had to recover from a Linux
system patch. Not once. All Linux system patches and upgrades worked
flawlessly for me. On the other hand, I literally paid my bills for a
while on Windows patch recovery when clients started applying SP2 to
their Windows XP systems. Linux systems used by the same clients hummed
along, undisturbed.

While I didn't service the Server 2003
systems that developed major problems with the deployment of SP1, I
know that similarly impressive spikes in the consultancy's revenue
stream occurred with that patch as well.

On top of all that, I'm
still waiting to hear about a number of patches for things that have
been languishing on Microsoft's back burner for far too long. I haven't
heard of a needed patch for the Linux systems I support that has yet
taken more than a few days to appear after the need was discovered. I
can only thank my lucky stars that my duties with the consultancy are
moving more and more into Linux and web development, and farther from
Windows system support. The stress levels have dropped considerably. I
get to design and implement, and spend less time fixing.

With
all of that in mind, and casting a scornful glance back at the
chicanery of Microsoft and Wipro Technologies, I have to ask:



Is anyone buying this?