Eclipse Galileo is out now. It is remarkable: 33 projects and 24 million lines of code, according to the press release. Perhaps the two biggest features in this release are support for Mac Cocoa - in order words, proper Mac support - and PHP development tools. All open source, all free.
Unsurprisingly, Eclipse appears to be the most popular Java development tool, and if you extend that to IDEs based on Eclipse, its dominance is overwhelming. Its obvious rival, Netbeans, has improved greatly in the last few years and may be better for some purposes; but it looks unlikely to catch Eclipse, and the impact of Oracle's impending acquisition of Sun is unknown.
Eclipse has also influenced other development tools, forcing vendors to offer more for free and to improve their extensibility. You can see this effect in Visual Studio, for example, with its Express editions and both technical and licensing enhancements to its extensibility in recent times. Microsoft may say that this would have happened anyway, but I am doubtful. Eclipse changed the game.
Still, there is something that I've always found intriguing about Eclipse, which may be a weakness in its business model (if a free platform can have such a thing). I put this to Executive Director Mike Milinkovich and he responded robustly, which I like because it usually means I've asked a good question.
Eclipse is a a tools platform, not an IDE, and member companies build their own products based on the shared platform. Examples are Adobe with Flex Builder, IBM with Rational Application Developer, Zend with Zend Studio, and Embarcadero with JBuilder. Each of these companies has a dilemma. The more they invest in the shared platform, the more they collectively benefit by getting features that they do not have to build on their own; but the better the shared platform gets, the more difficult it is to differentiate and sell their commercial products. I asked Milinkovich about this tension and he interrupted me:
That's not a tension, that's exactly the way Eclipse is designed to work. That is the Eclipse business model. Our licensing model and our business model are geared around the notion that we're building an open source platform which then people build products on top and differentiate in the marketplace based on what they do on the proprietary side.
Although Milinkovich says it is "not a tension", Embarcadero CEO Wayne Williams complained about this very thing, telling me that IBM is now pulling back from investment in Eclipse and reserving the best new features for its own products - which, whatever the truth of the matter, IBM has every right to do.
An additional factor is the difference between vendors like Google, which has an Eclipse plug-in for App Engine, but is only concerned to promote its platform; and those like Embarcadero whose business is selling tools. Vendors like Google can improve Eclipse without any threat to their business.
Eclipse is wildly popular, but came last in a recent Software Development Platform survey of developer satisfaction by Evans Data. To be fair, all the products won a reasonably good rating, so we should not infer that Eclipse is poor; it is not. I can understand, though, why some member companies may be happy to see Eclipse rated as good, but not too good, giving them space for their Eclipse-based products; and if this is the case, it may limit the extent to which Eclipse is likely to improve.
Question: which is best for cross-platform, managed code using a runtime such as Java, .NET, or Flash, or is it native code? When Java arrived in 1996, Sun promoted write-once-run-everywhere as one of its key benefits. The arrival of just-in-time compilers for all the runtimes mentioned above removes many performance concerns. So is managed code the best solution?
My assumptions about this were challenged when I spoke to Embarcadero's CEO Wayne Williams last week. His company is the one that now owns Delphi and C++ Builder, the RAD software development tools, after acquiring Borland's Codegear division last year. Williams told me that taking Delphi and C++ Builder cross-platform is now the top priority for the team working on those products. Concerning native code, he said: "It's crystal clear. If you want a small, fast, GUI-rich application, and you want to target the popular platforms, there's only one game in town." That means at least x86 code for Windows, Mac and Linux, and he added, "there's no reason mobile devices shouldn't be on that roadmap as well."
What's wrong with Java then? "There's always been two approaches to target multiple platforms. One is interpreted, where you shield the code the developer is writing from those differences. The Virtual Machine is responsible for that, and if you want to add another platform, it's all centralised. It's easier, but the result is poor, it's a least common denominator approach.
"It's a bigger investment and it's more difficult to cross-compile, where you natively target these platforms, but the end result is much better. You're running true native code with full access to whatever hardware there is on that platform."
It was like going back in time: I recall similar arguments about Java back in the nineties. Since then, we've had not only JIT compilers but also huge increases in hardware performance. Is Williams living in the past?
Before dismissing what he says, it's worth noting that native code has never gone away. I use cross-platform native code applications all the time, from the SQLite database engine to the Audacity sound editor, and I enjoy their small size and fast performance. Over at Google, the Chrome team is hard at work delivering a new web browser, and it is mostly written in C++. Most of Windows is written in C++, despite Microsoft's commitment to .NET; and Java is an afterthought in Apple's OS X.
Although hardware performance has improved, the increasing numbers of mobile devices with constrained resources is a counter-balance to the idea that hardware takes care of inefficient code; and although managed code is fine for many business applications, it's hard to quibble with Williams' contention above that "If you want a small, fast, GUI-rich application, and you want to target the popular platforms, there's only one game in town."
There is another argument for managed code, which is that applications are quicker to write and safer to run when they are under the control of a runtime virtual machine. That is generally true as well. Still, Delphi does a great job of hiding the complexity of native code development. It may be just a little anachronistic, but if Embarcadero successfully deliver a cross-platform Delphi compiler, I think there will be plenty of take-up.
Williams says we may see cross-platform Delphi as soon as next year.
The Web is broken in lots of ways, one of which is that its content is mostly unstructured. Most web pages have a title and some content, and that is about all you can assume. Researchers and standards bodies have been trying to impose more semantic order on the web since its earliest days, by adding metadata so that web crawlers can parse the content accurately, rather than relying on inference. These efforts have had little success outside academia; and the semantic content of typical pages has arguably got worse rather than better, thanks to the trend towards richer pages using JavaScript and Flash, rather than simple text marked up with HTML.
Microformats are a softer approach to adding metadata, using standard HTML but with conventions that identify certain types of content, such as name and address details (hCard), events (hCalendar), or even CVs (hResume). If you have web pages that include content of this type, you can usually mark it up according to the microformat specification without damaging the appearance of the page. The benefit is greater searchability; in fact, you could think of it as a kind of search engine optimization.
A good example is hReview, a draft specification for reviews of anything from products to events or places. If I'm considering a purchase, I often type in a search for "product x review", and then find myself sifting through lots of useless results, because all the ecommerce and affiliate sites know we do that kind of search, and pretend to have reviews when really they do not. If all the sites used hReview I could do more precise searches, perhaps specifying "only reviews in the last 12 months", and sorting by rating, and the search engine could structure the results nicely so I can see at a glance the author's name and an extract from the review itself.
Simple standards like this can have a huge impact. The whole blogging revolution was driven by RSS, which itself is a kind of microformat for news.
The snag is, they have to be widely adopted to be useful. I first wrote about microformats in 2006, but despite my enthusiasm they have had little impact to date. That may be about to change. On Tuesday May 12th the mighty Google announced a new feature called Rich Snippets, which means it will be exposing microformat metadata in its search results, along with another more generic type of metadata called RDFa.
It all sounded familiar to me, as the previous weekend I attended Yahoo Hack Day in London, and heard about its Search Monkey project which also uses microformats and RDFa. Yahoo was there first; but it is Google that has the power to shake up the web.
Should you care about microformats? If Google is serious, then it will have a wide impact. Business names and locations should be marked up with hCard, for example. Anyone designing an Ecommerce site with user reviews should be looking at hReview. Although the list of microformats Google is taking note of is small at the moment, if it catches on that list will inevitably grow.
The message that Google is giving an advantage to sites that use microformats and RDFa will be heard loud and clear by the SEO community, and given the commercial importance of effective search ranking this could grow quickly.
Then again, I may be over-optimistic now (and yes, I do think it is a good idea) as I was in 2006. Watch this space.
Recently I have been working with Microsoft Silverlight, looking at how to put together a simple database application. I am no designer; my interest in Silverlight is to do with cross-platform deployment, a consistent runtime, and an alternative to HTML and Javascript. It seems I am not alone in this respect; the Silverlight forums are dominated by programming rather than design queries. Here are the message counts at the time of writing:
The Silverlight 3 wish list is also illuminating. You soon get a feel for what developers are most frustrated about, such as: no printing support, no easy way to save documents to the user's hard drive, ugly fonts, no clipboard support, no access to devices like web cams and microphones, and no support for WSHttpBinding which adds transactions and reliable messaging to web services.
Only a few of these things are fixed in the Silverlight 3.0 beta. There is a file save dialog, and text rendering is improved though Microsoft is a long way behind Adobe Flash in this respect.
That said, Silverlight 3 does offer substantial improvements for business applications. For example, in Silverlight 2.0 you have to handle client-side validation manually, whereas Silverlight 3.0 adds validation support similar to what is in ASP.NET. There is also a new server-side piece called .NET RIA Services, which wraps key areas like authentication and transactions. Although Silverlight cannot do real transactions, .NET RIA Services introduces changesets, which let you bundle a set of database updates into a single web service call. You can also include arbitrary custom operations, such as approving a purchase order. On the server side, where you do have transaction support, this is processed and can succeed or fail as an entire unit.
Despite the snags, there is a lot to like in Silverlight. As a GUI framework it works really well, and it is good to know that special effects and transitions are available are available if you need them. Microsoft appears to have executed well on the challenge of creating a smaller, cross-platform build of the .NET Framework, which is really Silverlight's key advantage.
Another plus is the ability to work in Visual Studio with the server and client projects side by side, integrated for debugging. You can set a breakpoint in the Silverlight client, and another in the ASP.NET web service implementation, and it just works.
Presuming that Microsoft's continues its rapid pace of Silverlight development, my guess it that it will evolve into an excellent client for .NET applications, since this is what the community is demanding. As yet though, Silverlight has made little impact on the wider world of web design, which remains dominated by Flash, and it is hard to see that changing.
When Rasmus Lerdorf announced Personal Home Page Tools 1.0 in June 1995, I doubt that he had enterprise software development in mind. Fourteen years later, the CTO of Zend software, Zeev Suraski, shows me a slide. It has a large area shaded light blue, representing all the part-time or hobbyist users of PHP, and a thin strip of darker blue representing corporate PHP developers or ISVs (independent software vendors) offering PHP applications.
"Those two categories are growing significantly," says Suraski. "In 2006 we're talking about maybe 10% or less of the entire user base, whereas by the end of 2009 Gartner expects it to be about 35%. This changing demographics is a sign of maturity for PHP."
He would say that, of course, because that thin strip is Zend's potential customer base. The company sells a professional IDE for PHP, support services, and the just-released Zend Server which packages PHP along with commonly used companions such as MySQL. There is also an optimizer (technically an op-code cache), a Java connector, and the paid-for version has additional monitoring, debugging and caching components.
It is not just talk though: Zend is flourishing despite the recession - "the Q1 of 2009 has been our strongest quarter ever," says Suraski - and although PHP's enterprise market share is small compared to Java or .NET, it is growing.
What interests me is why this has happened. It is partly thanks to the merits of PHP, its speed and simplicity, and the fact that Java's libraries and to a lesser extent those in .NET are over-engineered for many tasks. More directly important though is that the community using PHP - the large area of non-paying users in Suraski's slide - has created a remarkable pool of resources on the Internet that is available to everyone, business users included. Non-commercial users are those most likely to share their knowledge, unfettered by concerns over business confidentiality or copyright.
I experienced this for myself recently, when I sat down to write a small PHP application. Every problem I encountered was quickly resolved with a Google search, or by looking at the discussion attached to entries in PHP's online documentation.
II don't mean to belittle the extent of online resources available to Java or .NET developers, but would argue that PHP has the edge here.
I also realise that it is no good just doing a search and adopting the first solution that seems to work. Developers need to understand what is being suggested and assess its quality, rather than optimistically pasting in the first block of code that seems to work. If PHP has a weakness, it is that the language does little to help developers write secure, maintainable applications, which may explain why there are so many vulnerable PHP applications out there.
So what about Zend Server? Note that this is not an application server in the WebSphere sense; it is primarily a PHP platform installer and support package, and as such not that different technically from what you can do with a Linux package manager or something like XAMPP.
I tried installing Zend Server on Windows Vista and bravely chose the IIS 7.0 integration rather than Apache. It actually worked smoothly and will be fine for developing PHP applications, though I would normally deploy to Linux, which I gather is a common scenario. That said, the work done by Zend and Microsoft makes PHP on Windows Server a reasonable option as well, and one that makes sense if you need to integrate with .NET, SQL Server or other Windows services.
The real winner here is PHP. Zend is making it business-friendly without damaging its open source ethos, and in doing so providing a great example of how free software can sidle its way into the enterprise.
Too strong? Maybe, but the ASP.NET Web Forms programming model has run its course. It was hugely impressive when it originally appeared - I remember it being announced as ASP+ in 2000, and how phenomenal it seemed. You can build a web page visually, using a rich set of controls, and have ASP.NET abstract away much of the problem of managing state. It also lets you write code in any .NET language, which is just-in-time compiled at runtime for fast performance.
ASP.NET works the same as ever today; but the web has moved on. The Web Forms model makes programming the web more like programming Windows, which was cool at the time but not any longer.
Fortunately for Microsoft, it has an alternative, called ASP.NET MVC. The first full release was announced at the Mix09 conference last week, and you can download it now. I took the opportunity to ask some of the delegates what they thought of it.
The reactions I got fell into two broad categories. The first group found it difficult to puzzle out what it really was, even those who had attended sessions on the subject. The second group loved it, and never ever wanted to go near Web Forms again. In fact, such was the frustration with Web Forms among some developers, that they had developed their own alternative frameworks but were now moving to the official one.
So what's wrong with Web Forms? Complaints I heard include that it is not testable; that it is not really compatible with AJAX; that it is inflexible; that ViewState, hidden form data which preserves state across page refreshes, is a nuisance; and that it is hard to write REST-style applications or those which properly support the Back button.
Enter ASP.NET MVC, which answers all of these complaints. MVC stands for Model View Controller, though having played with it a little I find the name somewhat misleading, as well as being a mouthful (contrast the delightfully-named MonoRail, which is an interesting alternative). Why misleading? Well, it doesn't have much of a Model, as this post observes. It does have views and controllers; but I think one of the reasons developers find it hard to grow is that starting with a discussion about MVC architecture is not the best way to teach it.
I think the place to start is with URLs and routing. It also helps to know that ASP.NET MVC follows the principle of convention over configuration (though not to the same extent as Ruby on Rails). In a nutshell, ASP.NET MVC breaks the link between the URL in the browser and aspx files on the web server; instead, it processes the URL and returns what you want it to return.
A "View" in ASP.NET MVC is an .aspx page, but in the form of a lightweight template, not a Web Forms with a complex page lifecycle.
I've been playing with ASP.NET MVC recently, and it is a delight. Yes, there is more manual coding than with Web Forms, but it is worth it for the additional control you gain. Even the performance seems better, a consequence of the lightweight approach. As it happens, I'm also a believer in test-driven development. I guess I'm in the second group that I spoke to at Mix09.
Microsoft is not killing off Web Forms; rather, it is very insistent that they remain under full development. I get the impression that the company expects ASP.NET MVC to be a minority choice.
Nevertheless, if you work with ASP.NET do not hesitate to check out the new framework. Personally I think ASP.NET MVC might just rescue its web platform from a slow but inevitable decline.
I'm at Microsoft's Mix09 conference in Las Vegas, where the big news (aside from small matters like the final release of Internet Explorer 8) is the beta release of Silverlight 3.0, Microsoft's browser plug-in that competes with Flash as a platform for rich internet applications.
Silverlight 3.0 is stuffed with new features, one of which is the ability to run outside the browser. Right-click an applet, choose Install onto this computer, and suddenly you have a desktop application complete with a shortcut in the Start menu, or on the Mac desktop. This has triggered a debate over how SLOOB (that's Silverlight Out Of Browser) compares to Adobe's existing AIR (Adobe Integrated Runtime), which supports Flash applications running on the desktop.
Understandably, Adobe folk like Ryan Stewart are emphasising the differences:
"I think AIR and the Silverlight OOB (Out of Browser) are two very different technologies for two very different scenarios...AIR is about letting you take your web application skills to build desktop applications and Silverlight OOB is more about letting you take your Silverlight applications to the desktop. The different models will be different for everyone, but right now AIR gives you a lot more flexibility and more API hooks into the operating system."
The big issue is how much these desktop/web hybrids interact with the local machine. Microsoft makes a point of how SLOOBs run in the same sandbox as they would in the browser, which means the user can install without a security prompt, but also that the application has very access to the user's desktop. The only access to the file system is to a protected area called isolated storage, or via a file dialog that the user controls. Microsoft says there might (or might not) be a way of displaying notifications but that is about it.
AIR applications by contrast run with the same permissions as the user. Installation involves the user consenting to a dialog which usually threatens unrestricted access to the system. Your AIR app can read and write any files that the user can read or write. There is also a notification API, and support for drag-and-drop.
That said, AIR applications are also restricted by design. They cannot be extended with native code, or execute other applications. Adobe has always presented AIR as a way of delivering web applications on the desktop, rather than as an alternative to C++ or .NET for traditional desktop applications. So is it really so different from SLOOB?
Well, some of the AIR features do give it an edge. One is the ability to fire notifications (annoying though this can be). It's something that Microsoft definitely intends to add to SLOOBs, though I get a different answer every time I ask about it; it might not come until Silverlight 4.0. Another difference is that AIR can host HTML as well as Flash content, which is an advantage for applications that depend on both. AIR also includes an embedded relational database engine, SQLite, whereas SLOOB developers will have to roll their own or use XML, though I doubt this is really a big deal. One other thing: Silverlight knows nothing about printing, which is unfortunate when running outside the browser.
Nice features; but I still feel that AIR and SLOOB are close competitors. Both take a cross-platform, rich internet application runtime and make it available from a desktop shortcut and with offline support. That makes a huge difference to users, even if the technical differences between running in or outside the browser are not so great. SLOOBs are going to be attractive to .NET developers because they include the .NET runtime and can be developed in the familiar Visual Studio IDE.
Personally I'd like to see an option to run AIR applications sandboxed, as full file access is more than most of them need. I'd also like an option to run SLOOBs with greater local system access when needed. Why not have the best of both worlds?
In the meantime, I'm expecting both to succeed. For applications that will work as a SLOOB, it makes a great user-friendly, cross-platform alternative to Windows Forms; and we've already seen effective user of AIR for cloud-centric utilities like Twitter clients. Both platforms are also highly effective for visualizing data. Who knows, this approach could become the norm for a wide range of business applications.
Historically, the web development choice between the Microsoft platform and open source has been a fork in the road with many consequences. Choose Microsoft, and you generally use Visual Studio, Internet Information Server, ASP.NET, C# or Visual Basic, and SQL Server for the database manager. Choose open source, and you most likely target LAMP in one of its guises, the most common being Linux, Apache, MySQL and PHP, and work in Eclipse or almost anything other than Visual Studio.
Recently the boundaries have been blurring a little. Apache actually runs nicely on Windows, and I've used it happily to host a Subversion repository, while on the other side Microsoft has been making an effort to support PHP in IIS 7.0. But what about running ASP.NET on Linux, is that a silly idea?
I've been following the efforts of the Mono project in this area for some time, though it's been a while since I've tried it out. Mono was originally focused more on desktop than web applications, and I've used it mostly in that context. When laterooms.com tried Mono in early 2006 it quickly gave up, citing problems with Mono's Boehm garbage collector; see the developer's comments to my blog post at the time.
Still, that was three years ago. I had another look a couple of weeks ago, and I've been impressed. In particular, the ability to develop in Visual Studio and deploy to Linux is interesting. I'm working on a small project, and getting this working is remarkably simple. I used Visual Studio 2008, but set the project to target .NET Framework 2.0, as Mono lags behind Microsoft in implementing the latest .NET APIs, and using MySQL rather than SQL Server, since this is available on my Linux web server. Using MySQL with .NET is straightforward thanks to the official ADO.Net provider, which specifically supports Mono as well as Microsoft .NET.
On the web server, running Debian 5.0 Linux (Lenny), I installed the libapache2-mod-mono and mono-apache-server2 packages using Aptitude. Next, I configured Apache to use Mono on a particular web site, with a few lines of manual configuration, as explained here, and imported the MySQL database from the Windows development machine to the Linux web server.
Back in Visual Studio, I compiled the web site, uploaded it, and it worked first try. Performance is good as well.
I realise that a number of caveats apply. It's worth reading this page, the current Mono todo list, which notes some of the important areas where Mono is lacking and includes the comment:
Mono is known to be not as performant as the .NET Framework.
Note that Mono still uses the Boehm garbage collector, though an alternative is in development. Further, Mono does not implement the entire .NET Framework. Mono is a brave choice; Windows and IIS the sensible option for .NET applications.
It still seems to me significant that you can easily deploy to Linux and Apache using Mono. Not all applications are mission-critical, and not all applications need to scale as well as Laterooms.com. Mono has a number of attractions. First, it is open source, so in the event of problems you can always obtain and amend the source code. Second, running on Apache and Linux is a considerable saving in license costs. Third, you can get official developer support from Novell.
Why would you use C# and ASP.NET rather than PHP or Java? The main reason would be because you know and like the language, the platform, and/or the Visual Studio IDE. In an interesting report on the state of the computer book market, O'Reilly notes that C# is now the largest programming language for all book sales. Thanks to Mono, you can use C# but still deploy to an open source platform.
It also seems to me that Microsoft's official support for Moonlight, the Mono implementation of Silverlight, is important. Microsoft now needs Mono, in order to tick the cross-platform box and compete with Flash, giving more assurance to its long-term future.
Mono's growth over nearly a decade has been slow but steady. Perhaps now is the moment that it creeps into the mainstream.
Are you using Mono, for web or desktop development? I'd be interested in your comments.
Microsoft's Eric Nelson conducted a poll on how many businesses still use Visual Basic 6. It is hard to make sense of the statistics, since there was a built-in bias:
This survey was sent out to individuals we "suspected" had Visual Basic 6.0 heritage but it was also widely advertised through the MSDN Flash to UK developers.
In other words, only Windows developers were consulted, and those more likely to be using VB 6 were specially targetted. Some results:
See the original post for more detail. I'd like to know more about the wider picture - how many companies overall still use VB 6 - but although these figures are skewed I can well believe that there is a lot of VB 6 out there.
Incidentally, the respondents are correct in believing that the VB 6 IDE is no longer supported. Extended support ended in March 2008. However, note that Visual Basic for Applications, which partly shares the same runtime, remains part of Office and therefore is supported. The VB 6.0 runtime is supported at least until 10 years after the release of Windows Server 2008; see this paper for exactly what is and is not included.
I noticed that msvbvm60.dll, along with other VB 6.0 runtime files, is also in my beta copy of Windows 7. I guess that will nudge the support life for the runtime even further into the future.
The bottom line is that Microsoft would be crazy to release a mainstream version of Windows that could not run VB 6 applications. For the most part, laggard VB 6 developers are safe, though there could be third-party components that stop working. Another point is that VB 6 will always be 32-bit.
All this prompts a few observations.
First, if you have skills in VB 6.0, it looks like you will be in demand for a while.
Second, my own views on VB 6.0 are mixed. I recognize that it was a revolutionary and very capable tool; but if anyone is inclined to wax lyrical about its merits, I point them towards Verity Stob's Thirteen Ways to Loathe VB and Bring your Hatchet by Bruce McKinney. At best, it is a flawed platform.
Third, I do see the sense in leaving well alone in many cases. VB 6.0 is lightweight compared to .NET, and runs on a wider range of hardware. Migrating code is perilous unless you have rigorous unit tests; some quirk in VB may catch you out, so that ported code does not work in quite the same way.
It strikes me that there is little value in migrating from, say, a VB 6.0 client application to a .NET Windows Forms application. My instinct would be either to leave it be, or redesign it as a web application. Otherwise the risk is that your new ported application will be just like the old version, but slower.
Microsoft has a summary of the options here, which seems to promote the idea of hybrid applications, perhaps using the Interop Forms Toolkit to embed .NET controls in VB 6 forms. Maybe, but there is a danger of getting the worst of both worlds. That said, every case is different so there is little value in generalizing. The important thing is to have a technical and business rationale for the path you choose.
Hyper-V may not be the best virtualization platform out there, but it does not have to be. Its unique selling point is deep integration with Windows Server 2008, complete with an easy to use management console. I've been using it extensively, though on modest hardware, and overall I'm impressed. Enable the hypervisor in the BIOS, install the Hyper-V role, create a new virtual machine, and go. I've used both Server 2008 and Windows 2003 as guest operating systems, and everything works as advertised. You can assign an .iso image to the virtual DVD drive, which is handy for me as an MSDN subscriber, since I test new Microsoft software by downloading it from there. A great feature is that you can backup both host and guests in one shot, even when the machines are running. Provided that the Hyper-V integration services are installed in the guests, the host backup will talk to the Volume Shadow Copy Service (VSS) in the guests to ensure the integrity of the backup.
Hyper-V is handy for Windows developers since you can run servers like SharePoint and Exchange without the clutter and expense of real boxes. Once the new machine is up and running, I generally connect through remote desktop on another machine, and it looks just like any other remote Windows server.
That said, there are a few snags with Hyper-V. While performance is generally good, I've found that disk I/O can get slow. There are a couple of things you can do to mitigate this. One is to be generous with RAM - more memory means less disk access. Second, Microsoft states that a fixed virtual hard drive is faster (though less convenient) than a dynamic virtual drive, which is the default. It is possible to convert from one to the other, though it is a slow operation.
Another issue is that because of the VSS integration, you should not attempt to back up simultaneously from the guest and from the host. It would be easy to do this by accident through scheduled backups, as Microsoft also recommends that you should do both kinds of backup for critical servers.
Using the supplied Windows Server Backup in a Hyper-V guest is awkward, since drives attached through USB or eSATA are not recognized automatically in the guest. You can backup to a network share or a second mounted virtual hard drive. I've heard that this problem is fixed in Hyper-V R2, which you can currently download as a beta.
The subject of Hyper-V and domain controllers is rather complex. Sandy Berkouwer has two separate posts which are helpful. Actions like pausing or saving state in a domain controller can cause problems, and Berkower suggests that having at least one physical domain controller is wise. Microsoft warns against having the host machine joined to a domain managed solely by a guest.
Another issue is that if you are unlucky, and are using snapshots (giving the ability to roll back to a previous time), Hyper-V can occasionally revert to an earlier time without being asked. If this happens, shut the machine down right away and see if you can recover it, as I did, by restoring a backup and doing a manual merge with the snapshot differencing file.
Microsoft appears to be handling the Linux integration services with all the enthusiasm you would expect. You can find the services here - though you have to sign in with a Live ID. Only Suse Linux Enterprise Server is supported, and the site forum, which is noticably lacking official Microsoft participation, includes telling comments. Why does the code have build dependencies on Xen (an open source alternative to Hyper-V), and only works with version 2.6.18 of the Linux kernel? However, note this comment from a user:
For anyone not aware, doing even light disk IO under a hyper-v linux guest without linux_ic will chew on your cpu the entire time, which makes it very unusable for any server that's not mostly idle.
The good news on the Linux front is that Microsoft has just announced an agreement with Red Hat to support Red Hat Enterprise Linux 5.2 and 5.3 - 32-bit and 64-bit, but apparently uniprocessor only - complete with integration services; we have to hope this works out better than the Suse partnership has, so far. It deserves some effort from Microsoft, since running a LAMP stack on a Windows Server machine via Hyper-V is useful.
Despite some hassles, Hyper-V is invaluable, and there is now little excuse for wasting power and space on numerous lightly-used servers. Virtual servers have many advantages, in cost, in ease of management, in flexibility, and in backup and restore. My guess is that they will become the norm for test as well as for production, hosted either locally or in the cloud.
