Load Balancing is Dead...
I was reading some arbitrary stuff, when I suddenly came across the topic "Load Balancers are Dead" , I thought, what the hell ... Is that really true, if they are dead what are we going to do... do we have to relearn the entire suite of technicalities, so on and so forth. My mind could digress on that for ever... I decided to read on and not just carried away by the title.
There was a relief, we dont have to relearn at all, but the application of all that knowledge will be changing. Load balancing as we know is going away, but not the concept.
We will be going to be "Distributing" and not merely "Balancing" it. Though we tend to use these terms interchangebly, it is not really the same... Distributing has Balancing as the core concept with some algorithms into the place, so that we dont just randomly keep throwing packets to random boxes, but we do some wise decision making before we give off the packets for processing. (Last place i thought i would see M.B.A's ;))
Contrary to my assumption, the load baalncing is not going away, but load balancing at layer 4 is...
Traditional layer 4 load-balancing offers horizontal scalability and ensures availability of applications by balancing requests across a number of servers. While there are several industry standard algorithms such as round-robin, least connections - and their weighted variations - that can be used to determine how those requests are distributed, in the end you still need a pool of identical servers from which the Load balancer can choose to retrieve content. If you're relying on third-party web application servers this can become costly as your capacity needs grow. You'll need to purchase additional licenses for each and every server you deploy, not to mention the potential additional costs of SSL certificates and application-specific costs such as JDBC/ODBC drivers or integration software, etc ...
Using layer 7 - application fluent - features, you can architect a solution that not only ensures availability and scales well, but that also reduces the costs associated with web application servers such as additional licensing fees.
Layer 7 routing, a.k.a. content switching, a.k.a. content based routing, allows you to examine application specific content and headers to determine which server or pool of servers should process a given request. You can examine every aspect of a request - URI, headers, application content - and make decisions to intelligently distribute the request. You can easily distribute all .JPG or .GIF files to one server, all .HTML files to another server, and all .ASP or .JSP requests to yet another. You can look at application-specific content - virtually a requirement for content based routing of web service (SOA) and XML requests - and direct requests as required by your application delivery needs.
Certainly the web application server must process requests and must be the core of your application architecture. But you can use simple application aware routing to move images and static content to other, less expensive servers and thus reduce the overall cost of maintaining your application infrastructure. This has the added benefit of increasing the capacity of your web application servers, as the application servers will no longer be expending valuable (and expensive) resources on serving up images and static content. Moving static content and images to less expensive servers reduces costs, but it has the advantage of allowing you to configure the servers to specifically serve up these content types without affecting how the core application content is served or requiring that you maintain complex application server configurations to handle these different content types.
And while it's undoubtedly more efficient to design an application from the start with this capability in mind, the beauty of application delivery controllers is that you can add this functionality at any time without needing to rewrite the actual applications involved. Because the application delivery controller is an intermediary, it can examine all requests and decide where to route the request. Thus you can virtually rearchitect your application architecture in real-time without incurring the costs of rewriting or redeploying existing applications.
While the layer 7 can incorporate delays, but the kind of machines we have today, that is reduced
Take care ... till next time
There was a relief, we dont have to relearn at all, but the application of all that knowledge will be changing. Load balancing as we know is going away, but not the concept.
We will be going to be "Distributing" and not merely "Balancing" it. Though we tend to use these terms interchangebly, it is not really the same... Distributing has Balancing as the core concept with some algorithms into the place, so that we dont just randomly keep throwing packets to random boxes, but we do some wise decision making before we give off the packets for processing. (Last place i thought i would see M.B.A's ;))
Contrary to my assumption, the load baalncing is not going away, but load balancing at layer 4 is...
Traditional layer 4 load-balancing offers horizontal scalability and ensures availability of applications by balancing requests across a number of servers. While there are several industry standard algorithms such as round-robin, least connections - and their weighted variations - that can be used to determine how those requests are distributed, in the end you still need a pool of identical servers from which the Load balancer can choose to retrieve content. If you're relying on third-party web application servers this can become costly as your capacity needs grow. You'll need to purchase additional licenses for each and every server you deploy, not to mention the potential additional costs of SSL certificates and application-specific costs such as JDBC/ODBC drivers or integration software, etc ...
Using layer 7 - application fluent - features, you can architect a solution that not only ensures availability and scales well, but that also reduces the costs associated with web application servers such as additional licensing fees.
Layer 7 routing, a.k.a. content switching, a.k.a. content based routing, allows you to examine application specific content and headers to determine which server or pool of servers should process a given request. You can examine every aspect of a request - URI, headers, application content - and make decisions to intelligently distribute the request. You can easily distribute all .JPG or .GIF files to one server, all .HTML files to another server, and all .ASP or .JSP requests to yet another. You can look at application-specific content - virtually a requirement for content based routing of web service (SOA) and XML requests - and direct requests as required by your application delivery needs.
Certainly the web application server must process requests and must be the core of your application architecture. But you can use simple application aware routing to move images and static content to other, less expensive servers and thus reduce the overall cost of maintaining your application infrastructure. This has the added benefit of increasing the capacity of your web application servers, as the application servers will no longer be expending valuable (and expensive) resources on serving up images and static content. Moving static content and images to less expensive servers reduces costs, but it has the advantage of allowing you to configure the servers to specifically serve up these content types without affecting how the core application content is served or requiring that you maintain complex application server configurations to handle these different content types.
And while it's undoubtedly more efficient to design an application from the start with this capability in mind, the beauty of application delivery controllers is that you can add this functionality at any time without needing to rewrite the actual applications involved. Because the application delivery controller is an intermediary, it can examine all requests and decide where to route the request. Thus you can virtually rearchitect your application architecture in real-time without incurring the costs of rewriting or redeploying existing applications.
While the layer 7 can incorporate delays, but the kind of machines we have today, that is reduced
Take care ... till next time
Comments
Post a Comment