Using aiScaler to facilitate website transition
Posted by Max Robbins on October 25th, 2010aiCache’s pattern and origin server tagging (os_tag directive) is ideally suited for easing the typical chores of website transitions.
Many an IT professional shiver at the mere mentioning of this two words: website transition. It doesn’t have to be painful. Let’s imagine that Acme Inc has its current website of news.acme.com hosted with a legacy provider, FlyByNite WebHosting Inc.
The site was developed a while back and is running a custom written CMS that is, quite frankly, growing long in the tooth. It is rather slow, lacking in features, hard to maintain and especially hard to modify. It can go down without much of a warning and doesn’t have much of monitoring in place – which results in fair bit of frustration at Acme, as helpless Acme web site crew observes, in horror, another meltdown, unable to do anything to help the situation.
Not content with status quo, Acme leadership team decides to embark onto a difficult journey – a complete redo of the site’s CMS, this time going not with a home-grown solution, but adopting one of more popular Open Source CMS.
Such endeavors are typically very labor intensive and error prone all-or-nothing approaches. In other words, after spending much time and money, you’d throw the proverbial switch and send traffic from old environment to the new one and hope it all works out.
With aiScaler in the mix it doesn’t have to be such a monolithic effort. Instead, you can transition your site section by section, without any impact on your users, having complete control and confidence every step of the way.
Acme starts by placing aiScaler in front of news.acme.com domain. They can now cache some content, reducing the load on the frail legacy environment, observe traffic and it’s vital statistics in real time, alert when things go sour, still keep the site up in case of complete hosting meltdowns, that are growing more frequent at FlyByNite WebHosting Inc’s datacenter.
The situation is instantly improves and there’s now some breathing room for the transition. Next, Acme sets up their own CMS instance (with most CMS, 2-3 web servers and a DB, ideally in a highly available setup). Now Acme chooses a section that they want to improve first – typically one that gets most traffic. Let’s say it is US News and it lives under news.acme.com/us_news .
Having setup the section on the new CMS, now we can tell aiScaler to fill the requests for news.acme.com/us_news not from legacy, but from the new CMS – by tagging the relevant pattern and adding the new CMS web servers to the configuration.
With a simple, instantaneous aiScaler configuration change, Acme can introduce the new CMS into the traffic path in an incremental, controlled, measurable and fail-safe way.
As more and more sections are developed in the new CMS, they too, are configured to be served from the new CMS. Incrementally, section by section, Acme takes over the control and hosting of news.acme.com and after a while the FlyByNite WebHosting Inc is out of the picture.
The picture below depicts the setup, with legacy CMS on the left and the new CMS on the right. You can see basic flows of traffic coming to Acme’s hosting environment and aiScaler deciding where to fill the content from. A very straightforward setup indeed. We also attach a small snippet of aiScaler configuration file that shows basics of using os_tag settings to accomplish the desired effect.
……
website
hostname news.acme.com
pattern /us_news simple 1m # Cache for 60 seconds
os_tag 2 # Fill from the new CMS by specifying os_tag of 2
pattern ….. # Patterns for content to be served from old CMS
pattern …..