The recent Microsoft .NET strategy announcements have prompted lots of e-mail from CIOs and network architects asking me how the .NET enhancements will change the way applications are deployed and supported in their environments.
The two most common questions concern how application deployment will change and how to ensure that these Internet-based applications are available to users at any time.
In this article, we’ll look at both of these issues and discuss strategies you can use to prepare for .NET applications, which Microsoft promises will combine the best of computing and communications in a variety of new Internet devices and programmable Web services.
Last week, Tim Landgrave began his three-part series on Microsoft .NET with “The .NET initiative: Microsoft puts the ‘e’ in NT.” In his final installment next week, Tim will discuss how Microsoft .NET changes development practices.
Deployment challenges for Web applications
One of the most common frustrations for network engineers in the current .COM/COM environment centers on application deployment. With Web applications in a continuous state of evolution, there’s a need to support rapid and continuous deployment.
If your Web application takes advantage of components, system services, or other applications that require registration in the system registry in order to function properly, then you’re used to dealing with problems like DLL conflicts, versioning problems, and dependencies.
The registration and removal process is also complex and may leave the system in an inconsistent state if your developers are not diligent. One of the design goals of the .NET platform is to replace the existing deployment process with one that supports friction-free installation that is both reliable and repeatable.
The .NET platform enables this functionality using self-describing applications. Instead of relying on an Interface Definition Language, Type Libraries, and Operating System registration to allow applications to find and instantiate applications, the .NET platform uses a simple XML metadata format for application definition and configuration.
This single metadata format is shared by the entire .NET infrastructure, which defines the rules by which applications locate, load, and parse the application definitions. By removing application registration from the installation process, the .NET platform allows system administrators to install multiple versions of the same application side-by-side and also allows for rolling upgrades of applications.
This removes a significant number of complexities normally associated with installation programs, multiple formats, registration, and so on. Installation of a .NET application is as simple as an XCopy of the application elements to a directory, and removal is a simple “del *.*” command.
Downtime issues for Web-based applications
Most network operations groups today are primarily concerned with keeping their internal applications running. When these applications can be accessed from the Internet by authorized services, the number of high availability challenges increases dramatically. These challenges include:
- Users have an expectation that Web application downtime is not an option. Systems need to be architected so that there’s a reliable way to keep the system available.
- Most people focus on mitigating unplanned downtime. But we should also consider the need for planned downtime in order to perform standard system maintenance and backup operations.
- Unfortunately, creating operational practices is a complex job, requiring people with experience in managing large, multiple systems from not only different locations but also from many different companies.
- High capacity Web architectures today are comprised of many types of hardware and software functioning as load balancers, application servers, Web servers, database servers, messaging systems, ERP systems and line of business applications from multiple hardware and software vendors.
- This large number of vendors, systems, and applications makes operational and failure analysis difficult because there’s a lack of good instrumentation data produced by these systems. There is also a plethora of APIs for gathering system health data from the different entities that make up the solution.
- The bottom line is that, in most cases, solving a problem tends to be a reactive rather than proactive exercise and requires manual diagnostics and intervention.
In order to make this environment more manageable, the .NET infrastructure will depend on WMI (the Windows Management Interface) as the conduit through which all hardware, software, and application management information will flow. All .NET infrastructure providers (Hardware, Operating Systems, Applications) will expose management and health information to WMI.
Since all the .NET servers (including Windows 2000, SQL Server 2000, Exchange 2000, Commerce Server 2000, Internet Security and Acceleration Server 2000) will expose their events through WMI, consumers (NetView, Microsoft Application Center 2000, HP OpenView) can capture and act upon these events. Your engineering and operations staff can then use this instrumentation data to proactively monitor and correct platform problems before they become significant issues.
Getting ready for .NET
You can’t begin using frictionless deployment today because new versions of .NET languages and the .NET Universal Run Time will have to be released to support it. You can, however, begin working with early .NET technology to understand how it works. You should put together a team of developers and engineers and have them create sample cross-system applications using the SOAP toolkits (from IBM, Microsoft and others) and Visual Studio 6.0.
You can also begin educating your development staff on WMI-enabling their applications. The earlier you begin using these new technologies, the sooner you can begin improving the operation of your currently deployed Microsoft platform.
Tim Landgrave is the founder, president, and CEO of Vobix Corporation, an application service provider based in Louisville, KY.
How do you plan to use Windows.NET in your enterprise? Post your comments below or send us an e-mail.