Skip to main content

SOA & Routers

Why is a Cisco router $10,000 and a Linksys router $100? Or perhaps the better question is why are your network guys willing to pay $10,000 for a Cisco router when a Linksys router can be purchased for $100?

The answer is that Cisco routers have multiple layers of reliablity, managability, and security that Linksys routers don't.

But 100x (100 times) difference? Is it really worth 100 times difference?

The network is the backbone of your IT infrastructure. If your network goes down, all the IT systems stop working and so does much (if not all) of your company's operations. And keeping that up, being alerted early to problems, being able to reroute and resolve problems, that is indeed worth 100 times difference.


When creating traditional big-box applications, the traditional components are:

  • The Application You Wrote

  • The Container or Runtime

  • The Application Server

  • The Database

  • The Database Server

  • (When we move to an application with a web GUI, you can add a web server in there.)

    The whole big box application is dependent on those few components, all of which tend to be within the application team's control or at least dedicated to the application. When there's a problem, get the server guy, the database guy, the app guy and figure it out. It's all boxed together.

    Lets say we take our big box application and add some new functionality which is dependent on 3 web services - each supplied by different application. Two of those services route and transform through our ESB (Enterprise Service Bus). Being our services are web services, we add a web server to the above meaning each of those environments brings 6 dependent components times 3 services, plus another 6 for the ESB and our original 5 running our environment...

    Our application is now dependent on 29 components to operate.

    Old coaxial or 10base2 networking fast, simple, and didn't have the repeater overhead of a hub. However, every node was directly connected to the whole network. Meaning, a problem with ANY node resulted in impact to the WHOLE network. A loose wire or a bad network card and the whole network was down, with no easy way to isolate the problem!

    Clearly this wasn't a reasonable way of operating, 10baseT and the network hub quickly took over.


    Formerly, when our application had a problem our department was impacted. Say 20-100 people stop working while IT scrambled to fix the problem. When our application which is providing a service to 5 other applications has a problem, now it's 100-500 people impacted. And if it's our ESB with a problem, which has 50 services routed through it, literally half to the whole IT structure could effectively be down.

    As we shift to SOA, our primary SOA components become as important as the network itself. Our ESB must be as reliable as the highest SLA of any application that uses an ESB service - if not higher. And every service our application uses must be of equal or higher SLA as our application OR we build our service usage paradigm to compenstate.

    Services and/or the ESB can be designed and configured to degrade gracefully, use alternate routes or services, and handle service failure. Let me restate that, not can be, must be. Many an IT organization using SOA will come to this realization and make these adjustments, usually 2-3 years into the maturity cycle as they've spent many a long night tracing service failures and listened to business managers expressing their frustration with yet another IT outage (while still trying to explain to the CIO why this SOA thing was a good idea).

    The ESB's will NOT do this for you. While the SOA Runtime Governance tools are beginning to probe deeply enough to begin to catch certain types of service problems early, they may alert support to begin trouble shooting but aren't going to save the application from the negative impact.

    Necessary SOA Paradigm shift: Program for fault tolerance.

    Popular posts from this blog

    Integration Spaghetti™

      I’ve been using the term Integration Spaghetti™ for the past 9 years or so to describe what happens as systems connectivity increases and increases to the point of … unmanageability, indeterminate impact, or just generally a big mess.  A standard line of mine is “moving from spaghetti code to spaghetti connections is not an improvement”. (A standard “point to point connection mess” slide, by enterprise architect Jerry Foster from 2001.) In the past few days I’ve been meeting with a series of IT managers at a large customer and have come up with a revised definition for Integration Spaghetti™ : Integration Spaghetti™ is when the connectivity to/from an application is so complex that everyone is afraid of touching it.  An application with such spaghetti becomes nearly impossible to replace.  Estimates of change impact to the application are frequently wrong by orders of magnitude.  Interruption in the integration functioning are always a major disaster – both in terms of th

    Solving Integration Chaos - Past Approaches

    A U.S. Fortune 50's systems interconnect map for 1 division, "core systems only". Integration patterns began changing 15 years ago. Several early attempts were made to solve the increasing problem of the widening need for integration… Enterprise Java Beans (J2EE / EJB's) attempted to make independent callable codelets. Coupling was too tight, the technology too platform specific. Remote Method Invocation (Java / RMI) attempted to make anything independently callable, but again was too platform specific and a very tightly coupled protocol. Similarly on the Microsoft side, DCOM & COM+ attempted to make anything independently and remotely callable. However, as with RMI the approach was extremely platform and vendor specific, and very tightly coupled. MQ created a reliable independent messaging paradigm, but the cost and complexity of operation made it prohibitive for most projects and all but the largest of Enterprise IT shops which could devote a focused technology

    From Spaghetti Code to Spaghetti Connections

    Twenty five years ago my boss handed me the primary billing program and described a series of new features needed. The program was about 4 years old and had been worked on by 5 different programmers. It had an original design model, but between all the modifications, bug fixes, patches and quick new features thrown in, the original design pattern was impossible to discern. Any pattern was impossible to discern. It had become, to quote what’s titled the most common architecture pattern of today, ‘a big ball of mud’. After studying the program for several days, I informed my boss the program was untouchable. The effort to make anything more than a minor adjustment carried such a risk, as the impact could only be guessed at, that it was easier and less risky to rewrite it from scratch. If they had considered the future impact, they never would have let a key program degenerate that way. They would have invested the extra effort to maintain it’s design, document it property, and consider