One of the headlines that caught my eye today is this blog post from the Amazon Web Services team about a new Memcached as a service offering from Gear6.
(Credit:
Memcached)
Similarly, Gear6 has added features such as replication, clustering, optimized memory utilization and management to create what it calls a Memcached distribution, much in the same manner as Linux distributions are packaged. Joaquin Ruiz, executive vice president of products at Gear6, provided me with additional insight into why Memcached is popular with Web 2.0 sites and why it matters for cloud computing.
The problem, according to Ruiz, is dynamic data services. In a recent blog post, he pointed to the tight connection between dynamic content and Web 2.0; that is, one defines the other. In this Web 2.0 world, the LAMP (and to some extent Java and Ruby) stack "provided a low-cost, efficient development foundation for Web 2.0 but did not free us from the monolithic, vertically oriented, "scale-up" platforms. Memcached provided the heavy lifting in terms of horizontally scaling ("scale-out") on non-monolithic SMP server architectures from Intel and AMD."
In the Facebook example, the Memcached tier stores members' personalized dynamic content, such as status updates, wall posts, etc., so that they can be quickly accessed when queried. It's a similar set up for Twitter tweets or comments on photos on Flickr. While latency in a social application is mildly annoying, latency in a transactional application could mean lost revenue.
Dynamic data services will likely remain an important part of cloud services, which brings us back to the idea of a Memcached service on a cloud platform. Amazon's Jeff Barr noted, "powerful, high-level services like this allow application developers to spend more time focusing on the novel and value-added aspects of their application and less time on the underlying infrastructure."
Anything that developers and companies can take advantage of to serve data faster and more efficiently means they have time to do other things, including increasing their bottom line.
As transactional data volumes increase, system architecture must stay flexible and be able to scale in accordance.
Back in September, the London Stock Exchange experienced a significant interruption when a proprietary system built on Microsoft technology went offline. Few details were shared, but I eventually cobbled together a rough explanation of what happened.
The stock exchange's system hung due to a "coincidence" (whatever that means) that stopped data from processing. What appears to have happened is several Windows processes, including message processing, crashed at the same time due to a configuration glitch. Because the applications were so directly tied in to Windows, the impact affected everything instead of just one component.
I spoke on the phone with Craig Hayman, vice president of IBM's WebSphere, discussing how open standards and design principles allow for more robust system architecture. Craig explained that the stock exchange incident was likely a result of being too dependent on a myopic structure rather than relying on a three-tier architecture that's been proven to scale.
It feels a bit old-school to talk about three-tier architectures in this day of Ruby apps built in 15 minutes, but the fact is you need separation and best-of-breed components when you are dealing with large transaction volumes and varietal peaks.
... Read more
When I read today that Europeana, a digital library of Europe's cultural heritage "crashed just hours after it went online and will be out of operation for several weeks" I was pretty shocked.
How a website could crash and be offline for weeks in this age of flexible-scale Cloud offerings and caching technology is a bit mind-boggling--especially considering that a properly architected website should be easily portable to larger hardware or a scaled-out system.
There are a great many ways to deal with traffic bursts, from using Amazon S3 for storage, or EC2 for more machines, to Akamai for edge-caching to Memcached to alleviate database load.
Just by offloading the images from the repository, I bet Europeana would have fared just fine. If searching the database brought the site down then those guys are in for some very tough times.
It's one thing to be a victim of your own success (as the site says they are) and quite another to be hamstrung by not following best practices.
- prev
- 1
- next
