Visual C#. NET 2003 Unleashed

So far, this chapter has discussed the various ways in which you can get the files that belong to your website onto a production server or some other deployment destination. The next section of the chapter focuses on more advanced and difficult concerns with deployment, such as deploying to web farms, deploying to secure environments, and deploying to limited environments such as public web hosts.

Web Farm Considerations

In Chapter 25, "Advanced ASP.NET," you saw how to design, architect, and code your web applications so that they can take advantage of the scalability, reliability, and availability that are provided by the use of web farms.

Before .NET, deploying applications to web farms could be unbelievably complex and very painful. Imagine trying to make sure that every GUID for every COM object on every server in a 10-server farm was the appropriate value, that every version matched, and that all the ASP files were synchronized.

It might not be that difficult now, but it's not an automatic thing, either. When deploying to a web farm, if you can't afford the downtime involved in bringing down the entire farm, you need to figure out a strategy for leaving the old version of the site up and running on other servers while you upgrade each box. This could pose a problem because if the new version of your application makes changes to the database, you obviously can't make changes to the same databasedoing so would break the old application while upgrading the new one.

That is just one example of the many things that you must be concerned with when deploying an upgrade or an installation to a web farm when availability is critical. As mentioned in Chapter 25, configuration issues must be taken care of, such as various Web.config settings, and you also have to make sure that application IDs within the IIS metabase are synchronized or ASP.NET won't work properly within the context of a farm.

Other deployment issues center around dependencies such as files on disk. What if your application requires that various resource files be available for download by the users of the application? Do you deploy all of those files to another server that acts as a singleton file server and is not part of the farm? Or do you deploy the files redundantly to all the servers and make sure that you have some method for resolving the local pathnames? There is no one right answer because the solution varies depending on the problem. This chapter can't give you the solution to your web farm deployment issues, but it can give you a list of some of the issues that you will need to address when deploying to a farm.

TIP

Make sure that you know whether your application will be running on a farm before you've written a single line of code. The deployment environment of an application should be determined in the Analysis and Design phases of a project. Preparing early for a web farm with considerations for session state, application state, and hardware dependencies will save you a lot of trouble when it comes time to deploy.

Firewalls, DMZs, Routers, and Security Constraints

A fairly common joke among developers is that there is an inverse ratio between productivity and security. Most of that is a joke…most of it. It wouldn't be funny if there wasn't some truth behind it. When you deploy your application into a secure environment, a myriad of things must be considered and properly configured for your application to work.

In a typical secure environment, the production web application is in a DMZ (demilitarized zone; an IT term for the barrier zone between your secure network and the Internet). Connections to the secure network behind your firewall(s) where the databases live can be limited. Some networks actually limit the number of open connections, and others restrict the available ports. Either way, you'll need to work it out with your infrastructure folks to enable the appropriate ports for your data access calls (for example, SQL Server's default instance starts at port 1650, but you can configure it to listen on any port).

You have connections that go from your DMZ to your secure network, allowing your public-facing application to access secure data behind the corporate firewall. What if you need data from another source? What if your application actually is a web service consumer and you need to establish connections to other websites for some or all of your back-end data? If you don't tell the infrastructure and security people about that need, your application probably won't work. In most cases, applications on boxes in the DMZ are forbidden direct Internet access, and have to use virtual IP addresses that allow them access to a specific host on the Internet. Without that virtual IP in the DMZ allowing your application to communicate with the outside world, your web service and any other connection will fail.

Many people fail to see the importance of taking all of this into consideration, and those same people end up with chronic headaches and spend far too many weekends in the office putting out fires. When you build your applications, you need to make sure that you are designing for deployment. Don't simply build your application so that it compiles and don't be satisfied that your application works on your nice, clean development machine. You need to build your application with deployment in mind. Before you write a single line of code in your ASP.NET application, you should know the answer to every one of the following questions:

• Where will my application be deployed? To a data center, a third-party host, a server under my control, or a server from another department?

• How will my application be deployed? Does it qualify for XCopy deployment or will I have to create a web setup project?

• What external dependencies does my application have? What does it need to access from the operating system and from the client (via cookies, session, and so on). What does it need from the outside world? Does it consume web services outside my network? Does it make other proprietary network connections outside my network?

• How will my application communicate with the database? Can that communication type be supported in a secure production environment through firewalls and still work properly and efficiently?

• How big is my application? What kind of disk storage will I need for the application? Will consumers of the application be using up a lot of bandwidth in doing so? If so, can I afford the cost of that bandwidth?

• How important is privacy to my application? Will I need SSL support from the operating system and from the networking infrastructure? Will I need the ability to encrypt and decrypt on the fly?

• How scalable must the application be? Will I need a farm? If so, how many servers do I need and what are my maintenance plans, deployment plans, and failover contingency plans?

Hosted Environment Considerations

A hosted environment is a third-party company, such as Brinkster, Mavweb, or any of thousands of others that provides hosting services for your application.

These hosting companies maintain their own Internet presence, their own data center, their own bandwidth, and their own servers. In exchange for a monthly fee, they allow you to rent space on their servers in which your application can run. Because of the incredible acceptance rate of the .NET Framework, it is actually becoming pretty difficult to find a hosting company that doesn't provide at least one option in which it hosts ASP.NET applications.

There are a number of benefits to these systems. The foremost benefit is cost savings. You don't have to own your own server or run your own data center or pay for your own bandwidth if you are using an external host. The hosting company takes care of everything. The hosting company might charge you extra for additional bandwidth, but you don't actually have to have a T1 or a T3 running through the back door of your house to host your application.

You need to be concerned with a number of things when you use an external host. These issues are related to the fact that not everything is under your control, and external hosts have restrictions and rules by which your applications must abide.

One of those restrictions is data access. Most hosting companies provide the capability for your application to read and write to the disk, so you can use XML and Access databases fairly easily. Others allow you to pay extra for SQL data access, but have disk space limitations.

You also should be aware of other limitations to third-party hosting, such as limited authentication methods. To provide hosting services to a large number of applications, some hosting companies disable the ability to set the authentication mode in the web.config file to keep people from tampering. Add to that the fact that most hosting sites limit things such as disk space, network access, operating system privileges, bandwidth, and more, and you will quickly realize that certain applications just can't be affordably hosted by third-party hosting companies.

If you plan to release a large commercial application, you probably are not going to want to make use of an external host. However, if your application is small or has limited needs, you can create an affordable presence on the web with all the speed, reliability, and productivity inherent in ASP.NET and the .NET Framework.