Microsoft Visual C++ .NET Professional Projects - Premier Press

THE .NET VISION AND GOALS Appendix A 921

Architectural Shift in .NET

The dramatic shift toward Internet technologies resulted in a change in the business computing models based on the client/server computing model. This was the revolutionary Web model, characterized as a collection of diverse information and applications that reside on varied hardware platforms.

The diverse nature of the Internet necessitated a common platform to deliver information while being scalable and extensible. With the widespread proliferation of the Internet, developers faced shifts in technology and a new breed of challenges. These challenges could not be met with the existing design models and tools.

The following are some of the challenges faced by developers as a consequence of the Internet revolution:

Heterogeneous environments. The computing environment at most large organizations was comprised of a diverse range of terminals, rich clients, and thin (Web) clients. As a result, applications that could integrate such heterogeneous environments were required. In addition, the new applications needed to support interaction with the legacy data and applications hosted on mainframe and midrange computers. The creation of such applications posed one of the greatest challenges to developers.

Scalability. The pre-Internet computing environment was a closed system fraught with limitations in the resources and access requirements. The availability of sufficient data to base projections for scaling the computing environment to match consumer demand allowed strategists to manage scalability with ease. In addition, a prolonged application development life cycle, often spanning several years, gave planners sufficient time to plan for system and application scaling. However, the Internet brought with it a new design paradigm that required system designs to accommodate a user base size from less than one hundred to more than one million. As a result, the existing planning meant for scalability became redundant.

Rapid application development and deployment. The emergence of the Internet necessitated rapid application development and deployment. This was an even more profound requirement in organizations seeking a transition from an intranet to the Internet. As a result, new ways to

THE .NET VISION AND GOALS Appendix A 923

Availability

Manageability

Performance

Reliability

Scalability

Security

In the subsequent sections, I’ll discuss each of the listed aspects and how the

.NET Framework supports application development with these design goals in mind.

Availability

Availability of an application refers to the amount of time for which the application is available for use. All Web-based applications and mission-critical enterprise applications need to be available round-the-clock. In other words, you need to design your application for high availability to ensure continuous business. All organizations that rely on Web-based distributed applications for their business require a range of options to modify the availability of applications to meet requirements. It becomes necessary to maintain high-availability applications in business scenarios that require a continuous flow of information. It is not easy to implement high availability for an application, and such an implementation requires a considerably more complex architectural infrastructure than the previous generations of client/server applications.

As the availability requirement for an application increases, you tend to face greater challenges, such as:

Increasing hardware costs for the application due to server, network, and disk redundancy

Increasing requirements for comprehensive testing of every automatic and people-based procedure that may affect your application

Increasing difficulty in identifying and eliminating complex failures

In addition, as the complexity and the access of the distributed application increases, chances of application failure also increase. Some of the factors that could possibly lead to an application failure include lack of stable software engineering processes and lack of constant monitoring and analyses. Some other factors include failure of hardware, such as disks, controllers, network devices,

servers, power supplies, memory, and CPUs, and natural disasters. It is hard to prevent natural disasters. However, other factors that lead to an application failure are preventable and manageable. Such factors contribute to 90 percent of the application downtime and include factors such as inadequate testing, change management problems, lack of ongoing failure monitoring, and lack of rigorous procedures and backup/restoration errors.

Availability is calculated as a percentage value expressed as the number of times an application is actually available for use as compared to the total number of times the application was planned to be available. Commonly, availability is expressed as a percentage value, such as 85 percent availability.

Contrary to what you might think, an availability of 99 percent for an application is not considered a good figure by industry standards, because it actually means that the application was not available for 88 hours in a year. Similarly, a 99.9 percent availability means that the application was not available for 8.5 hours per year, and 99.99 percent availability means a downtime of 1 hour per year. An availability of 99.9 percent is common for enterprise applications.

You can ensure a high availability of an application by choosing the appropriate hardware and software technology infrastructure. In addition, you require a serious commitment to skilled personnel, quality life cycle processes, and operational excellence.

Planning Availability Levels

It is an immensely difficult task to estimate the actual required availability that satisfactorily meets the business requirements and the budget and schedule expectations of an organization. Similarly, estimating the usage pattern and running environment of software is a tricky task. The problem in making these estimates is that the original availability assumptions can change and, consequently, lead to a revision of the original availability plans.

To decide an appropriate availability level for an application, you need to consider several aspects:

The customers and their expectations

The acceptable downtime

Dependency of internal company processes on the service

The schedule and budget

THE .NET VISION AND GOALS Appendix A 925

It is not a wise decision to create and deploy a less-than-perfect version of your application. This will simply lead to maintenance problems and disappointed customers. However, if it is necessary to implement a high-availability application and the budget and schedules aren’t feasible, then you should consider modifying the scope of the project and obtain the required funds.

It is a difficult task to design applications to maximize their availability. The vast range of application architectures makes it highly improbable for a single availability solution to work in every situation. For instance, you might consider deploying a comprehensive, fault-tolerant, fully redundant, load-balanced solution for high-volume, online transaction processing. Such design considerations take into account a combination of business requirements, application-specific data, and the available budget.

An important technique for increasing the availability of Web-based distributed applications is redundancy. Web-based distributed applications have a certain recurring architectural theme of front-end Web services, back-end data services, and management infrastructure. In this case, you can implement full redundancy, including cloned front-end servers, redundant network infrastructure, and cloned back-end servers.

Designing for Availability

Designing for availability is all about creating reliable applications. You must also design quick recovery mechanisms for your application, to reduce the downtime for the application.

Minimizing the application downtime comprises a vital aspect in designing the application availability. You can achieve this by anticipating, detecting, and automatically resolving hardware or software failures before they result in service errors, event faults, or data corruption.

Some ideas to generate highly available applications are listed here:

Avoid older, traditional approaches to availability, such as multiple CPUs and duplicated systems with fully replicated components. These approaches have several drawbacks.

Reduce unplanned downtime with clustering. Cluster service with a shared disk avoids most downtime and provides automatic recovery from hardware or software failures.

THE .NET VISION AND GOALS Appendix A 927

Use clustering

Use network load balancing

Use service-level agreements

Provide vigilant monitoring

Establish a help desk to reduce downtime

Test the recovery plan

Choose good infrastructure

Synchronize all clocks

Use data backups

Review all security plans

Advocate training and certification

Pay attention to the budget

Manageability

The manageability of distributed applications has a different set of problems. It is a difficult task to diagnose and resolve the capacity and resource problems. In addition, it is also difficult to predict the location of items on the network, the manner in which components are deployed and configured, and how to set the security attributes for thousands of different users. It is also difficult to determine whether an application is working as intended.

Managing an enterprise application greatly adds to the total cost of ownership. To decrease the cost of ongoing application administration, you need an efficient way to deploy, configure, upgrade, and monitor all local and remote components and services of your distributed application. This is a dilemma that the new emerging technologies have brought with them. As a solution, you need an efficient way to deploy, configure, upgrade, and monitor all local and remote components and services of your distributed application.

Managing a modern .NET application requires an efficient way to handle local and remote application support processes, including:

Initial deployment

Configuration tuning

Scheduled and unscheduled maintenance

928Part XII APPENDIXES

Frequent health checks

Occasional troubleshooting

Designing for Manageability

When you design an application for manageability, you provide an information infrastructure to ensure that the application and all of its important supporting services and devices can be monitored for possible corrective and preventive action. While ensuring the manageability of an enterprise-scale application, it is essential to handle common administrative tasks such as local and remote installation, configuration changes, and maintenance updates over the lifetime of the application.

Generally, designing manageable distributed applications includes the following three design features:

Management agents. Management agents allow you to monitor the local resources and publish data about the current state and performance of a resource. Additionally, management agents allow you to use local configuration services to make remote management possible. Management agents are required by each hardware device, operating system service, and application service.

Collection process. The collection process gathers, stores, filters, and correlates information of management agents.

Management console. The management console workstation is used to aggregate and report information related to application management. An administrator can use this central console to monitor all devices, analyze operational profiles, automate certain recurring activities, receive notifications from managed elements, and initiate remote configuration changes.

In addition to creating an efficient design, you need to constantly manage the application by collecting and analyzing application information during its lifetime. Some sources that you can use to gather application information to manage distributed applications efficiently are listed next. These sources can be used to identify problems and derive solutions:

Performance counters

Event Log

THE .NET VISION AND GOALS Appendix A 929

Operating services

Windows Installer

Active Directory

Registry

Server, network, and workstation hardware

Application services

Windows Driver Model (WDM)

HTTP requests

File Transfer Protocol (FTP) requests

Internet Control Message Protocol (ICMP) messages

Simple Mail Transfer Protocol (SMTP) messages

Along with Windows 2000 Server, the .NET Framework provides tools, utilities, features, and technologies that you can use to effectively manage distributed applications, including the following:

Desktop configuration. Active Directory arranges a network as a hierarchy of sites, domains, and smaller working units. Roaming users can use IntelliMirror to manage their data. IntelliMirror can also be used for automatic software installation and upgrades, group policy enforcement, and central management of user environment settings. You can modify, repair, and remove applications by using the Windows Installer Service. Remote OS Install can be used to set up new computers and reformat and reinstall an existing workstation.

Infrastructure management. The Microsoft Management Console (MMC) provides you with a simple and easy-to-use interface to access administrative activities. You can use Windows Management Instrumentation (WMI) to create, store, and analyze application operational data. Some other infrastructure management features include the Systems Management Server (SMS), Server Configuration Wizard, Terminal Services, Task Scheduler, Unattended Setup, Disk Duplication, Repair Command Console, Safe Mode Boot, Security Services, Security Configuration Manager, Public Key Infrastructure (PKI), and Kerberos Authentication.

Storage management. With the Removable Storage Manager (RSM), you can enable multiple applications to share tape and disk drives. In addition, administrators can initiate real-time tasks while the system