For a while now, you’ve probably heard the term “Web 2.0” loosely bandied about.  But what does it really mean?  I don’t think there’s any hard and fast definition.  It’s more of a broad philosophy.  But I like to use the term to distinguish my projects from other types of projects, especially “enterprise” projects.

As the name implies, “Web 2.0” means that you have a web site of some sort.  It might be an online store.  Or it might be web services.  There are lots of possibilities.  But in general, you are evolving continuously based on user needs.  From a project perspective, this means that you are using an agile development methodology and frequent software releases.  You tend to use open source software whenever possible to keep licensing costs to a minimum.  It also means that the software architecture must be very modular so that the number of servers for one functional module can scale independently from those needed for some other module.  For example, one functional module could be your front-end web servers, while another module could be authentication web services.

“Web 2.0” also has implications for the data center hardware.  Again, you need to be evolving and adjusting very quickly.  The ideal way to do this is by using pure cloud computing.  Cloud computing lets you easily create or remove virtual servers as your load changes over time.  However, you can also evolve quickly even if you’re using fixed servers in your own data center.  (More later on the pros and cons of cloud computing versus fixed servers.)  The trick is to use commodity hardware so that you can buy and install more servers and infrastructure gear very quickly because they are readily available.  For example, you could use cheap, off-the-shelf Dell servers that you can order via Dell’s web site.

Let’s contrast this with the typical enterprise project.  In many cases, the project needs to be planned months in advance.  The servers are usually expensive, high-end servers that require longer lead times.  Cloud computing is generally frowned upon.  The software development is usually a one-shot project for a fixed duration and there are usually very high licensing costs.

If you read about Service Oriented Architecture (SOA) for server-based applications, you’ll find that SOA means different things to different people, especially for enterprise environments.  In fact, there are some specific acronyms and methodologies that can make SOA seem really complex.  But the basic principles of SOA can be used by anyone to improve their site, even small ones.

Think about it this way…  Divide your application into functional modules, with each module having a set of web service APIs.  You even probably know intuitively how to divide things up.  For example, it’s very common for end users to authenticate by logging in.  So authentication could be one of your functional modules, and your front-end web servers could call it via web service APIs.  Or you may have to scale JPEG images to create thumbnails, so that could be another functional module.

The ideal way to implement this basic SOA scheme is to put each functional module on one or more servers dedicated just that one function.  And when your site gets bigger, that’s exactly what you should do.  But if you have a really small site, you’ll want to save money by putting more than one functional module on the same server.  The trick is to minimize one module from interfering with the other.  For example, you probably wouldn’t want to put authentication on the same server as thumbnail scaling because the scaling function requires a lot of heavy-duty CPU usage.  It could cause authentication requests to slow down to a crawl.

There are several benefits from using this basic SOA approach.  First, you reduce risk by only deploying new code to the servers where you’ve made changes.  All the other servers remain unchanged.  If something starts going wrong right after the deployment, it’s much easier to pinpoint it to the isolated change you’ve just made.

Second, your site is much easier to scale.  By monitoring traffic to each functional cluster of servers, you know when you need to add servers.  On the other hand, if many functions are hosted on the servers, it’s much harder to tell which one is causing the load.

Third, by putting different functionality on different servers, you are forced to make sure the APIs are very clean.  There’s no temptation to cut corners and make calls directly between modules located on the same server, so you avoid “spaghetti code” that is difficult to break apart later when you need to scale.

You’ve put lots of blood, sweat, and tears into developing a great online product, and you’re ready to launch it.  But how are you going to handle the inevitable problems and issues that that cause down time once you’re open to the public?  You realize that you need to create an escalation plan—one that specifies who should be responding first.  Should it be the Network Operations Center (NOC) at your data center?  Or should it be your developers?  Someone else?  In my experience, more than 90% of the time, the problems that arise are due to software bugs or configuration issues, and not hardware or networking.  That argues for your developers to be the first responders.  Otherwise, you’re wasting precious time while the NOC finds one of their technicians to try to troubleshoot the issue, only to discover they can’t do anything about it.

On the other hand, a developer usually can determine very quickly if an issue is a hardware or networking problem and call the NOC.  (Most networking problems that take the site down are catastrophic.)  The developers are also going to be most familiar with how the latest code is supposed to work, whereas the data center folks may be pretty unfamiliar with your site, especially since you are just one of many clients that they support.

When you write your escalation plan with developers as the first responders, you may get some grumbling from them.  After all, who wants to get awakened in the middle of the night?  But think of this as an incentive.  The more solid the code, the less likely they’ll get called.  And if they do get called in the middle of the night, you’ll be darn sure that they will put in a really solid fix for the issue.