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.

This entry was posted on Monday, May 24th, 2010 at 9:07 am and is filed under Data Centers, Software Development . You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.