Avoid this Fundamental Mistake, Simply Illustrated

An easy to make mistake in planning your Enterprise application can cost you big time. (Some folks even repeat this error after suffering through it once, because they don't understand why they failed the first time.) Here are two pictures that show you the right way to do it, and the wrong way as well.

One of the best things about my job as a SOA support engineer is that I get to see lots of application architectures, shared from smart people from all over the world. I probably learned more in the first year of this job than I did in my best 5 of any other, because I got to benefit not just from my own mistakes, but also from the mistakes of others. Nobody is right all the time, and anybody who steps out to design something complicated is putting themselves at risk of learning some good lessons. Here's one that's shown up time and again.

It's natural to read about layered architectures and think this means you can have different machines that serve different purposes. It seems natural to think of a bank of servers that act as 'business logic' machines, perhaps sending data over the wire to a different bunch of machines at the 'DAO layer'. This is wrong, don't do it! A variation of this theme is to envision a couple of machines that 'concentrate' on a task like being a messaging broker. Same idea-- let one server concentrate on one task-- this is not good!

A better way of doing it is to use your whole middleware stack on EACH server. (That's right-- let that server act as GUI, mid-tier, Data layer, JMS broker, etc.) Manage load by using a load balancer up front. This is much easier-- once you have the configuration put together, replicate it as many times as needed to scale up (assuming your middleware offers this capability. In JEE, it's pervasive.) If you have stateful clients, you'll want to use replication so you can failover. If your cluster goes beyond a couple of machines, you'll want to use 'Buddy Replication' schemes, where only 2 or 3 machines replicate state for each other, rather than every machine trying to carry state for the rest of the cluster.

Check the diagrams. This isn't a new idea-- I know I've heard this from Martin Fowler, read it in 'JBoss in Action', and seen it in print elsewhere too. But still, the idea is perhaps not the 'natural' decision to make, so people who haven't had it called out to them may make a big error in a very expensive place. Please think hard before adapting a "Distributed and Layered" architecture!

Happy Architecting!