ENCRYPTION
SSL Encryption is perhaps the most common and straightforward service that lends itself to specialization. If your site includes some pages and services that need to be secured, you can run those pages separately - either through a third-party SSL processor or through dedicated Web servers that are configured to run your SSL pages.

Like image handling, building a specialized SSL service creates a need to point to a different group of servers in your code, adding additional development complexity and requiring additional management effort. Alternatively, as with affinity, there are hardware solutions, such as application acceleration appliances that can reduce the coding requirement for SSL by handling the handshaking and encryption that would normally have to take place at the server. (See Figure 2.)

In general, like all types of specialization, distributing SSL and image handling have a cost in terms of development complexity and management effort. But what these strategies let you do is distribute each specialized task independently of the others and utilize your hardware more effectively - ultimately making your application more agile.

BROWSER & OUTPUT CACHING
One specialization that can have a huge impact on your ability to scale for growth or for sudden changes in demand is caching of both static and dynamic content. By incorporating browser caching, you can significantly reduce the load on your Web servers. You can also use appliance-based caching solutions that adjust HTTP headers to manage browser caching, as well as providing a more scalable substitute for ASP.NET output caching services.

Of course caching has its own costs. Both browser caching and output caching are complicated and time-consuming to code, which means you don't want to use them everywhere. Finding the places in your application where caching makes the most sense and would deliver the most value can be difficult. Even more significant, when you add caching you also add new requirements for maintaining the currency of the cache. The last thing you want is to be serving data that's no longer accurate. Knowing when the cache is wrong and developing a dynamic strategy to deal with cache expiries is critical. Often, the complexity of addressing these issues causes many developers not to use caching, despite its obvious benefits.

DATA CACHING
The most significant affinity in any ASP.NET application is the data. Introducing data caching (separating data into read-only and read/write specializations) is ultimately the highest-impact technique you can use to improve the scalability and agility of your application. Developers with the biggest Web 2.0 sites such as MySpace and Facebook recognize this, and it's the data caching strategies they've employed that have allowed these sites to become hugely successful Web 2.0 applications.

Of course, data caching is probably the most complicated thing you can do in an application. Data, by its nature, wants to be stored in only one place and doesn't distribute well. You have to use a system called multi-master replication to code the "write" components of the application to write to different databases than the "read" components, while allowing read/write components to feed data continually to read-only components. It's incredibly difficult to do. (As a consultant, if a client wants to use data caching, I know I'll have a job for years.) But when you really need to scale to millions of simultaneous users, data caching is the best way to do it.

Building the Agile Web 2.0 Application
Actually implementing all of these strategies isn't trivial. But if your application is going to be agile enough to truly embrace Web 2.0 capabilities at scale, intelligent distribution and specialization are essential.

Of course, there's one other vital piece of the puzzle: instrumentation. How do you know which parts of your site are ideal targets for distribution and specialization? Even after you've architected a sound distribution strategy, how do you measure whether it's continuing to meet your needs as they change? You need proper instrumentation in place to tell you when sudden changes are occurring and when your various distribution and specialization strategies should come into play. Without hard information about what's actually happening in the environment, even the most advanced specialization and distribution strategies are operating in the dark.

When you combine more intelligent distribution and specialization with up-to-the-minute knowledge of your environment, you can build true agility into your application. More important, you can take full advantage of all of the potential that Web 2.0 has to offer, knowing that no matter what demands the future may hold, your application and environment are prepared to meet them.