Learn how to move to .NET from one of the first, and largest .NET applications anywhere, Microsoft.com with its traffic of 111 million unique users. Larry Jordan, Microsoft.com Development Manager, describes his challenges and approaches in converting a 24x7x365 application to .NET. In his keynote address at VSLive! New York, “Microsoft.com Application Framework,” Larry Jordan will present a detailed look at .NET adoption on the Microsoft.com Web site. That site utilizes a centralized framework for content aggregation, presentation and programmability. Larry’s presentation will focus on the use of various XML capabilities in .NET and the network distribution model of Web services that make up the architecture of Microsoft.com. He spoke recently to Visual Studio Magazine’s editor in chief Patrick Meader about some of the challenges of porting legacy systems to .NET.

PM: Tell me briefly what you’ll be discussing in your VSLive! keynote.

LJ: I’ll describe the implementation details of the Microsoft.com Web site. My team owns the home page, the registration systems, the search systems, the download systems, the major aspects of Microsoft.com that provide services.

I’ll discuss a new application-centered side team we’ve created to implement the site. The team consists of 26 developers who focus on the application framework, including integration of ASP.NET and all the components that we’ve built over the years. They’re converting these legacy systems into Web services that run on the site in what approximates a federated model.

So now we have all kinds of groups at Microsoft that treat the site as a big hosting platform. We’ve enabled that platform for years, but now we’re making a move toward the application space internally.

PM: For perspective, what does Microsoft.com include and what kind of peak and daily load does the site experience?

LJ: Microsoft.com is the third-largest Web site on the Internet now (according to Keynote Systems, which monitors Web traffic), and we’re the world’s largest corporate site. For the month of April, we had 111 million unique users and 722 million page views.

PM: It’s widely known that Microsoft.com runs on .NET, but there’s a decent amount of confusion about what .NET is exactly, so tell me what it means from your perspective.

LJ: My team is moving years of legacy ASP- and HTML-based code over to SOAP-enabled Web services. In the case of the services on the back end, every one of our databases and SQL Services has been converted to a SOAP-enabled Web service. This was important foundational work we implemented with .NET.

Obviously, we’ve been working with .NET since the day it came out. We’ve recently ported everything over to Windows Server 2003, and all our back-end infrastructure is now built on top of SOAP conversations. Everything on Microsoft.com is based on messaging and SOAP. The current step is porting every single one of our ASP-based applications to .NET. I’m really excited by the kinds of productivity gains .NET and Visual Studio .NET provide for integrating all the disparate elements that make up the Microsoft.com site.

PM: You’ve touched on the transition to .NET at Microsoft.com. Give us a sense of perspective: What was your starting point? What were you using prior to .NET?

LJ: We were using SQL Server, and most of our site was based on ASP. Some of it was really good; some of it was kind of hacked up. But ASP never had a great structure for programming. I think of it as being lost in the wild. You were doing your best and able to implement impressively powerful systems, but you were really back in the 1970s when it came to the style of your programming. .NET brings structured environment back into mix, and I’m just amazed at the productivity gains from my team.

PM: And what are you using now?

LJ: Everything now is based on Visual Studio 2003 and the .NET Framework 1.1 on Windows Server 2003.

PM: Microsoft.com serves as a large-scale testing bed for new Microsoft technologies, and you often find yourself running on beta platforms and tools long in advance of a given product’s release. That would seem to do crazy things to lifecycle planning, where the need for new iterations isn’t necessarily based on new needs. How exactly do you manage that aspect of developing and maintaining the site? How do you strike a balance between constantly using and trying out new technology on the one hand and maintaining a stable, dependable flagship site on the other?

LJ: We’ve put quite a bit of thought into that. It is painful at times, but we do take steps to make this process easier on ourselves. I am adamant that we want to stick with the capabilities of Microsoft software as it exists out of the box. For example, in the past, we might have known that ADO did something by default we didn’t like, and felt the urge to write a COM object that did something different. The problem with that approach is that now you’re beholden to that legacy solution. As the technology improves, you can’t swap it out easily.

I like to run my team and their development at the level where we can swap out those technologies that sit underneath things without having to take huge hits on productivity. For example, assume one of my developers comes to me and says: “I’ve got a great new way to get at the data.”

I’ll say: “We’ve already got great ways to get at the data. Let’s improve the product; let’s not try to reinvent it ourselves.”

Sometimes when people hear that, they think we’re just implementers. And we are, in a sense. We’re trying to bring business value at our particular level, and it doesn’t make sense for my team to compete with the product groups. That’s the one key philosophy that has really saved us, and allowed us to swap the technologies out relatively easily. Of course we’ve had issues with ADO and DAO and related technologies through the years, but these difficulties are minimal compared to the difficulties we’d have faced if we’d tried to bypass these things.

PM: Tell me about a couple of your biggest challenges and the key lessons you’ve learned as you’ve ported Microsoft.com to .NET?

LJ: The bottom line is that people are nervous about cracking code open. They’re concerned about getting into code that hasn’t had much structure to it, especially code that has been in production for several years.

For example, I’m doing a port right now where I’ve had 11 developers touch the code over the years. The people on my team are nervous about getting in there because these systems tend to have huge dependencies.

As we get into .NET, we’re componentizing the architecture better, stripping away these dependencies, and the problems we face are diminishing. I’m personally porting over much of the code that my team is scared to death of. The reason I do it is so I can say to the team: Don’t worry about this, guys. You know how to do this job. The tools we have available to us now make the project less daunting than it appears at first glance.

PM: What lessons do you think people outside Microsoft can take from your transition?

LJ: My developers know they have to get this work done, but they also want to work on new and exciting things. So I encourage them to do both at once. You’re looking at your new feature development project, but you know you also have to fix this older project. I want you to work on both projects simultaneously. This way, you’re getting a good idea of how to reverse engineer the old stuff as you work on the new stuff. I’m sure there’ll come a time when we look at .NET, and we’ll have to port things from it to whatever comes after it. But that situation is going to be much easier than the situation we face right now.

PM: What are some of the lessons you’ve learned from doing this particular implementation?

LJ: If I were to go back and do it again, I’d have wrapped up a lot more of my libraries and code into COM objects. I would have done a lot more abstraction, which would have made the job of porting a lot easier. ASP is incredibly powerful and lets you mix in everything from data access to the presentation layer and everything else. And that’s really what’s happened over the years. Maintaining good levels of abstraction and encapsulation still matter enormously.

Larry Jordan
Larry Jordan is a development manager for Microsoft.com and responsible for site-wide applications like Search, Business Intelligence and legacy application porting. Larry has worked at Microsoft.com through the first version of IIS to the current and coming .NET platform. He considers himself a customer of Microsoft products and is dedicated to improving Microsoft enterprise applications in most demanding environment.