How Sears Could Have Used the Cloud to Stay Available Black Friday
The prediction of the death of online shopping this holiday season were, apparently, greatly exaggerated. As it's been reported, Sears, along with several other well known retailers, were victims of heavy traffic on Black Friday. One wonders if the reports of a dismal shopping season this year due to economic concerns led retailers to believe that there would be no seasonal rush to online sites and therefore preparation to deal with sudden spikes in traffic were unnecessary.
Most of the 63 objects (375 KB of total data) comprising sears.com home page are served from sears.com and are either images, scripts, or stylesheets. The rest of their site is similar, with a lot of static data comprising a large portion of the objects.
That's a lot of static data being served, and a lot of connections required on the servers just for one page.
Not knowing Sears internal architecture, it's quite possible they are already using application delivery and acceleration solutions to ensure availability and responsiveness of their site. If they aren't, they should, because even the simple connection optimizations available in today's application delivery controllers would have likely drastically reduced the burden on servers and increased the capacity of their entire infrastructure.
But let's assume they are already using application delivery to its fullest and simply expended all possible capacity on their servers despite their best efforts due to the unexpected high volume of visitors. It happens. After all, server resources are limited in the data center and when the servers are full up, they're full up.
Assuming that Sears, like most IT shops, isn't willing to purchase additional hardware and incur the associated management, power, and maintenance costs over the entire year simply to handle a seasonal rush, they still could have prepared for the onslaught by taking advantage of cloud computing.
Cloudbursting is an obvious solution, as visitors who pushed Sears servers over capacity would have been automatically directed via global load balancing techniques to a cloud computing hosted version of their site. Not only could they have managed to stay available, this would have also improved performance of their site for all visitors as cloudbursting can use a wide array of variables to determine when requests should be directed to the cloud, including performance-based parameters.
A second option would have been a hybrid cloud model, where certain files and objects are served from the local data center while others are served from the cloud. Instead of serving up static stylesheets and images from Sears.com internal servers, they could have easily been hosted in the cloud. Doing so would translate into fewer requests to sears.com internal servers which reduces the processing power required and results in higher capacity of servers.
I suppose a third option would have been to commit fully to the cloud and move their entire application infrastructure to the cloud, but even though adoption appears to be imminent for many enterprises according to attendees at Gartner Data Center Conference, 2008 is certainly not "the year of the cloud" and there are still quite a few kinks in full adoption plans that need to be ironed out before folks can commit fully, such as compliance and integration concerns.
Still, there are ways that Sears, and any organization with a web presence, could take advantage of the cloud without committing fully to ensure availability under exceedingly high volume. It just takes some forethought and planning.
Yeah, I'm thinking it too, but I'm not going to say it either.
Related articles by Zemanta
Published Dec 03, 2008
Version 1.0
Lori_MacVittie
Employee
EmployeeLori_MacVittieEmployee
Employee
Lori_MacVittie@Hamish,
Yes, *she* knows nothing of the internal architecture. Which is why assumptions were made. Because we don't know and even if we did, we wouldn't be sharing that info publicly.
Yes, many stuff that looks static isn't. However, if you look closely at the Firebug capture you can see that much of the page likely is static. It's rare that CSS and images are dynamically generated.
Persistent sessions. Ah, yes, persistence. Something we've written a lot about in the past.
Persistence vs Persistent
Enabling Session Persistence with iRules
Session persistence based on source IP
Affinity|Session Persistence
BIG-IP doesn't understand session limiting unless you tell it to care about session limiting. Off the top of my head there are two ways to do this:
1. The app server must be able to indicate that it is reaching session capacity so the BIG-IP can use that information to stop sending it requests. This could be done through monitoring using a page that indicates how many more sessions could be handled, and then BIG-IP can act upon that information.
2. Using the persistence tables in iRules or an HTTP derived "session specific" statistics profile, you can track the number of sessions on any given server and use that information in determining which servers (if any) are available.
I'm sure many folks would prefer this functionality be "built in" but it's so variable depending on the configured session length, size of data stored in sessions, etc... that it's not something that's easily abstracted and genericized. Better to allow the customer the ability to specifically configure for their environment than pre-bake a solution that only solves the problem for a few customers.
Thanks!
Lori- Lori_MacVittie@Tom
That's an excellent point. You can't keep your servers separated from other cloud client servers, because all the physical hardware is a shared resource, necessarily. The separation occurs at the virtual machine layer, if virtualization is the core technology on which the cloud is built.
The jury is still out regarding applications and PCI/SOX compliance in the cloud. While some PCI requirements, such as application firewall/code scanning could certainly be addressed in the cloud, still there are other points in the requirements that may not be adequately addressed in the cloud.
Lori - Lori_MacVittie@Ari
Regarding your point 1: aren't you going to share what it was?? Shame on you for piquing our interest and not sharing! :-)
Regarding I/O bottlenecking: Amen. I agree that the JMS/middleware/database layers are the real bottlenecks in most high volume situations. It's always been a bit surprising that database caching solutions never made an impact on the market as they really had an interesting solution to the problem that could certainly alleviate some (not all) of the problems associated with these layers of the app infrastructure.