I do not think that word means what you think it means
Greg Ferro over at My Etherealmind has a, for lack of a better word, interesting entry in his Network Dictionary on the term "Application Delivery Controller." He says: Application Delivery Controller (ADC) - Historically known as a “load balancer”, until someone put a shiny chrome exhaust and new buttons on it and so it needed a new marketing name. However, the Web Application Firewall and Application Acceleration / Optimisation that are in most ADC are not really load balancing so maybe its alright. Feel free to call it a load balancer when the sales rep is on the ground, guaranteed to upset them. I take issue with this definition primarily because an application delivery controller (ADC) is different from a load-balancer in many ways, and most of them aren't just "shiny chrome exhaust and new buttons". He's right that web application firewalls and web application acceleration/optimization features are also included, but application delivery controllers do more than just load-balancing these days. Application delivery controller is not just a "new marketing name", it's a new name because "load balancing" doesn't properly describe the functionality of the products that fall under the ADC moniker today. First, load-balancing is not the same as layer 7 switching. The former is focused on distribution of requests across a farm or pool of servers whilst the latter is about directing requests based on application layer data such as HTTP headers or application messages. An application delivery controller is capable of performing layer 7 switching, something a simple load-balancer is not. When the two are combined you get layer 7 load-balancing which is a very different beast than the simple load-balancing offered in the past and often offered today by application server clustering technologies, ESB (enterprise service bus) products, and solutions designed primarily for load-balancing. Layer 7 load balancing is the purvey of application delivery controllers, not load-balancers, because it requires application fluency and run-time inspection of application messages - not packets, mind you, but messages. That's an important distinction, but one best left for another day. The core functionality of an application delivery controller is load-balancing, as this is the primary mechanism through which high-availability and failover is provided. But a simple load-balancer does little more than take requests and distribute them based on simple algorithms; they do not augment the delivery of applications by offering additional features such as L7 rate shaping, application security, acceleration, message security, and dynamic inspection and manipulation of application data. Second, a load balancer isn't a platform; an application delivery controller is. It's a platform to which tasks generally left to the application can be offloaded such as cookie encryption and decryption, input validation, transformation of application messages, and exception handling. A load balancer can't dynamically determine the client link speed and then determine whether compression would improve or degrade performance, and either apply it or not based on that decision. A simple load balancer can't inspect application messages and determine whether it's a SOAP fault or not, and then once it's determined it is execute logic that handles that exception. An application delivery controller is the evolution of load balancing to something more; to application delivery. If you really believe that an application delivery controller is just a marketing name for a load-balancer then you haven't looked into the differences or how an ADC can be an integral part of a secure, fast, and available application infrastructure in a way that load-balancers never could. Let me 'splain. No, there is too much. Let me sum up. A load balancer is a paper map. An ADC is a Garmin or a TomTom.Is your SOA really SEA?
In reading through ZapThink's latest post regarding the "Great ESB Controversy of 2008" it occurred to me that it is quite possible, and probably likely, that the issue of ESB use primarily revolves around whether you're doing SEA or SOA. Yes, I know. You've never heard of "SEA" before. That's because I just made it up to describe the difference between a service-enabled architecture and a service-oriented architecture. And there is a difference. A SOA (service oriented architecture) implies that an architecture has been designed around the concept of services. A SEA (service enabled architecture) implies that an existing architecture has been service enabled through various service-enablement products such as, you guessed it, an ESB. These are two very different architectures, with SEA being focused primarily on reuse of existing applications as opposed to reusing new services. That being the case, it is likely that one of the primary goals of organizations whose idea of SOA is really SEA is that of integration, in which case it makes perfect sense that an ESB would be an integral component of such an organization's service strategy. An ESB provides not only service enablement capabilities, but usually also provides an easy mechanism for transforming data and messages such as XSLT and a graphical mapping tool, which makes integration a whole lot less painful than it has been in the past. Obviously SOA and SEA can be used concurrently and in conjunction with one another; they aren't mutually exclusive. The interoperability of services makes that a breeze and is one of the technical benefits of implementing a standards-based service focused architecture, whether that's a SEA or a SOA. But it might help to make the distinction because they do require a different thought process to architect and have different implementation problems associated with them. There are benefits to a pure SOA in streamlining processes, removing redundancies in application responsibilities, and introducing consistency into the applications that run the business. SEA doesn't necessarily bring those benefits to the table because you aren't going through the process of evaluating all the application and data sources and determining sources of authority and eliminating the inherent redundancies built in over the years. The goal of SEA is to quickly integrate existing applications and data sources into business processes and new applications, without a lot of concern for whether or not they are redundant or could be streamlined or need to be decomposed and rearchitected into their composite services. But it's fast, and provides benefits moving forward that are similar to SOA in agility and reuse. Both architectures have benefits and there are good reasons to go with a SEA instead of a SOA, or both. It's time we recognize that SOA isn't The One True Way and that there are other, equally beneficial and valid architectures involving services.Madness? THIS. IS. SOA!
There is an interesting war being fought in the blogosphere over the use (or overuse) of ESB (enterprise service buses) to build out a SOA (service oriented architecture). It certainly appears that Dave Linthicum is taking on the role of Leonidas and the Spartans at the battle of Thermopylae while everyone else is on the side of Xerxes and the Persians. Dave is defending his view that ESBs are overused and often, apparently, misused against a host of ESB and SOA focused bloggers like Joe McKendrick and Jeff Schneider. But everyone is talking in abstractions, and no one's really giving anyone a good idea of when to use an ESB or when to avoid them. No one seems to be looking at why people are or aren't using ESBs and getting to the root of the question - when are they appropriate for use in a SOA and when are they simply being implemented for the sake of being implemented? So when should you consider implementing an ESB as part of your SOA? 1. You have a need to orchestrate services. Orchestration of services is one of the greatest strengths of an ESB. ESBs layer transaction management around orchestration of services and provide value when two or more services need to be composed into a single "transaction". 2. You have a need to integrate middleware messaging with applications. Let's face it, service-enabling MQ or JMS is a pain in the ... neck. An ESB makes this process simple and allows for orchestration of asynchronous services that might otherwise be difficult to integrate into an architecture. 3. Multi-application updates (a la integration). I know this is an unpopular thing to say, but sometimes the best solution to the problem of enterprise application integration in a SOA world is to use an ESB. ESBs are more than capable of orchestrating updates in a parallel processing scenario, and if you have multiple legacy applications or services that need updating during the same process, then an ESB is going to provide significant value in implementing such processes. 4. You plan on doing any of the above in the future. Laying the foundation for orchestration, integration, and parallel processing of messages means laying the foundation now, not rip-and-replace later. If there are plans in your SOA's future that would include an ESB, then implement sooner rather than later. SOA is supposed to help align IT with the business. If you need an ESB, or three or ten, to accomplish that goal, then that's what you need to do. While it may not be a "pure" SOA in implementation, if you're staying true to its goal then it's definitely a "pure" SOA in design and intent.Load Balancing as an ESB Service
Most people, upon hearing the term "load balancing" immediately think of web and application servers deployed at the edge of the network. After all, that's where load balancing is most often used - to ensure that a public facing web site is always as available and fast as possible. What many architects don't consider, however, is that in the process of deploying a SOA (Service Oriented Architecture) those same web and application servers end up residing deeper in the data center, away from the edge of the network. These web and application servers are hosting the services that make up a public facing application or site, but aren't necessarily afforded the same consideration in terms of availability as the initial entry point into that application. This situation is compounded by the fact that there may be an ESB (Enterprise Service Bus) orchestrating that application, and that services critical to the application are not afforded the same measure of reliability as those closer to the edge of the network. While most ESBs are capable of load balancing these critical services, this capability is often limited and lacking the more robust and dynamic features offered by application delivery controllers (ADC). Consider a public facing service that takes advantage of an ESB: The Compliance and Shipping Services are critical to the public facing service, as are the other services provided by theESB. And yet in a typical implementation only the public facing service (the Order Management Service) will be afforded the reliability and optimization provided by an application delivery controller. It may be the case that the ESB is load balancing the Compliance and Shipping services, as simple load balancing capabilities are provided by most ESBs. While you might find the load balancing capabilities adequate, consider that most ESBs lack the health monitoring capabilities of application delivery controllers in addition to being unable to balance the load based on real-time factors such as number of connections and response time, making it difficult to optimize your SOA. The lesson learned by application delivery vendors in the past have not yet been incorporated into ESBs. Just because a server responds to an ICMP ping or can successfully open a TCP socket does not mean the application - or service - is actually running and returning valid responses. An ADC is capable of monitoring services at the application level, ensuring that not only is the service running but that it's also returning valid responses. This is something most ESBs are not capable of providing, which reduces the effectiveness of such health checks and can result in a service being treated as available even if it's malfunctioning. When it's really important, i.e. when services are critical to a critical application - such as a customer/public facing application - then it's likely you should ensure that those back-end services are always available and optimized. An application delivery controller isn't limited to hanging out in the DMZ or on the edge of the network. In fact, an ADC can just as easily slide into your SOA and provide the same high availability, optimization, and failover services as it does for public facing applications. By integrating an application delivery controller into the depths of the data center you can let the ESB do what it's best at doing: transformation, message enrichment, and reliable messaging and remove the burden of performing tasks that are better suited to an ADC than an ESB such as load balancing, protocol optimization, and health monitoring. The addition of an ADC to assist the ESB and ensure reliability also provides a layer of abstraction that fits nicely into your SOA and aligns with one of SOA's primary goals: agility. SOA implementations are by their nature distributed. Composing applications from distributed services achieves agility and reuse, but introduces potential show-stopping problems usuallyexperiencedat the edge of the network into the heart of thedata center. It is important to consider the impact of failure of a service on the application(s) that may be using that service, and if that application is critical, then its dependent services should also be treated as critical and worthy of the protection of an application delivery controller. Imbibing: Orange Juice Technorati tags: MacVittie, F5, ESB, SOA, application delivery, service oriented application delivery, load balancing
