IT Jobs
Microsoft's Windows Server chief on Linux, 64-bit computing (part 1)
Bob Muglia talks about the threat posed by Linux and the promise of 64-bit computing.
By Carol Sliwa and Craig Stedman, Computerworld | Computerworld UK
Published: 00:00 GMT, 18 May 04
Bob Muglia, senior vice president of Microsoft's Windows Server division, discusses the road map for future operating system releases, the competitive threat posed by Linux and the promise of 64-bit computing. Part 1 of the interview follows. Part 2 is available here.
How is Microsoft differentiating itself from the Linux competition?
I don't really think that Linux itself is our competitor. I think Linux is a set of technologies and open-source technologies. in general, are a set of technologies that competitors like Red Hat or Novell and IBM pull together to provide alternative competitive solutions for customers. Linux has evolved to be a commercial product. All the customers I sell to buy Linux-based products from companies like Red Hat or Novell. They put them together, stacks with other software, typically commercial software, like WebSphere. And if you look at a solution that exists in that space - say, an IBM solution - it's certainly not free. The cost of acquiring that is actually quite comparable to the cost of acquiring a Microsoft solution.
We think our advantage here is the fact that we understand each of these workloads that our server and our server system is used for, and we can focus and optimise to make each workload best of breed. But then we can also work across workloads and do a better job of providing an integrated experience for the customer relative to our competitors.
What's the difference running an ERP application on Windows vs. Linux?
The question comes down to how that ERP system integrates with the rest of the customer environment. In the case of a Microsoft solution, there's a whole set of tools and capabilities in the software that we include in products like SQL Server and in some of the solution sets that we make available to enterprise customers to allow them to deploy and integrate that application into their environment. Those sorts of things typically are not available on Linux, and what happens then is you bring in consulting services to glue those things together. Some of our competitors, IBM most notably, are predominantly a consulting company. And for them, complexity is a benefit, because it allows them to sell consulting services.
How can users get an edge by running non-Microsoft applications on Windows instead of Linux?
No. 1, because we're a software company, our objective straightforwardly is to use software to reduce the cost and increase the innovation for an IT organisation. I think our objectives are very much in alignment with those of most IT shops inside major companies. And there's a huge distinction of that vs. an environment where complexity is what is encouraged and services must be added on top of that. I think if you look at Linux and Linux stacks and the companies that are promoting those, they have a vested interest in selling consulting services.
We don't. It's that simple. Our interest is in making our overall solution, together with those of our partners, provide a better, more cost-effective answer for our customers.
The second thing is that this environment has always got sufficient breadth and complexity associated with it. While Microsoft will supply some predefined solutions, like e-mail, if you look at the set of workloads that a customer needs to have within their environment, we provide a small percentage of the actual software they need. And so that requires and compels us to build this ecosystem of partners.
There are users running Linux that don't rely on consulting services. There are workloads that are simple that can be deployed independently, like that DHCP [Dynamic Host Configuration Protocol], DNS server. Those things are relatively independent. We sometimes think about those things as commodity workloads. Here again, our goal is to differentiate ourselves by doing the best of breed in those spaces, so we're very competitive individually. But we also do a better job of integrating. For example, our DNS server integrates with Active Directory.
For which server workloads are you seeing the most competition from Linux?
Application migration off Unix is one where, certainly, Linux has some traction. Typically, there are custom-built business applications that people have on proprietary Unix that they want to move to x86 hardware. Customers do an analysis of what it takes to move that workload. Now we have Services for Unix, which does an extremely good job of helping customers to move their applications to Windows without having to rewrite those applications into a Win32 environment. But clearly, Linux is an alternative that people are looking at.
Another category is networking environments where their needs tend to be fairly simplistic.
How soon do you think before Windows Server 2003 for 64-bit extended systems will catch on?
64-bit x86, we think, is a big deal. Fifteen to 18 months from now, all new servers will have 64-bit support enabled within the new hardware. Then the key is making sure that the applications run on top of the 64-bit base. It is important to note that in an x86, 64-bit environment, customers can get a great solution even if the applications themselves are not 64-bit. Because the x86 environment natively supports 32-bit and 64-bit solutions running side by side, when the operating system goes 64-bit, the 32-bit apps run quite well in that environment. In fact, we're seeing, typically, on the order of about an eight per cent performance improvement just by upgrading the operating system.
The reason is that the operating system is able to take advantage of some of the extended capabilities of those chips. In particular, there are more registers available in a 64-bit space. The way you can do memory addressing and things are expanded. So applications get some natural performance improvement, even if they're not moving to 64-bit. An app like SQL Server gets enormous benefit by going 64-bit because it's constrained by memory. For some applications, it's a really big deal to go to 64-bit. Other apps, not nearly as clear the benefit. But over time, we'll see them all go to 64-bit.
The interesting thing is some of these scenarios are memory-constrained by the kernel and how much space it needs to take and use. So just by having the kernel go 64-bit, you get a capacity improvement. Let me give you an example of a service that just benefits phenomenally with 32-bit applications running in a 64-bit world. Terminal Server today, on these new four-way and certainly eight-way systems, is completely constrained by the amount of memory that can be used, because each user session uses a fair amount of memory. Each of them is like a client. So in a Terminal Server world, by going to the 64-bit operating system, even though Office and the apps that are being run are only 32-bit, you can get a lot more of those on simultaneously. All of a sudden, we explode the number of simultaneous users that a server can support.
Do you know any customers who have tried it?
Too early.
Has Microsoft tested it internally?
We've tried it internally and it's substantive.
What about your customers who already run 64-bit Windows on Intel's 64-bit Itanium processors?
People are seeing it for real with Itanium today. But with these x86s, we will see the price point for 64-bit systems drop substantially. The second area that's really quite exciting is the fact that because you've got this great 32-bit application compatibility, you get these benefits from places where the apps themselves haven't gone 64-bit, like Terminal Server. It's going to be years before the desktop environment's converted over to 64-bit, but you can get substantive benefits today with these 64-bit, x86 systems.
Are people running 32-bit applications on Itanium?
Not substantially. You can, but you have substantive performance degradation.
Will Longhorn have 32- and 64-bit releases?
The plan is still that it does, but it's one that we're going to watch very closely. We keep asking ourselves this question.
It would be very beneficial to move to the 64-bit platform, because it would simplify life for device-driver writers. Right now, you have to build two sets of device drivers - 32-bit and 64-bit. We're highly motivated to move to the 64-bit world. It's just a question of how fast the entire industry can get there.
It's also more work for Microsoft to support 32-bit and 64-bit, isn't it?
Sure. Absolutely, it's more work for us. It's mostly testing that's the real issue.
Is it likely you'll have to support 32-bit to accommodate companies that are slow to upgrade?
You get Virtual Server. There are some ways around some of these things. We have ways to help customers get there. It's really more a question of, How fast does the hardware environment switch over? Clearly, it'll switch first on servers and then desktops will follow and portables will follow that. We will see portables out there that are 64-bit.
For what other reasons might there need to be a 32-bit Longhorn release? There are two places where we have compatibility issues - with 16-bit applications which we don't support in 64-bit, and with devices that have not been ported to 64-bit. You've got an old printer, let's just say, that the manufacturer stopped selling three years ago, but the consumers still have it. The manufacturer [has little incentive] to put out a driver for that printer.
.gif)
Add your commentComments