I live in a world of end user experience management. The SLA's I have in place with my customers are quantified in milliseconds, and as such we employ a strategy known as edge acceleration. Edge acceleration can mean different things to different people, but those who have a SaaS (Software as a Service) model treat the "edge" as the network physically closest to the end user and the "origin" is where the application(s) is hosted.
For web-based applications, the following almost always happens (regardless of industry, form, or function):
Steps (necessarily very high-level)
1) user pulls up some hostname (app.company.com) in a browser
2) user sees a page, usually a login page, accompanied with text and images
3) user logs in and proceeds to use the application in any number of ways
Since these three steps are effectively universal in SaaS, it is worth our while to analyze these steps in an effort to increase the accessibility of these things from the edge.
Analysis
1) An end user typing a hostname into the address bar of his browser and clicking "go" triggers a number of events. First, the hostname typed in needs to be resolved to an IP address via DNS. Once the IP is known, our end user connects to the IP requested, and issues HTTP GET's based on the server response (HTML).
Leveraging an edge DNS service, such as Akamai's eDNS service, will ensure that a nameserver most accessible to the end user will pick up the request and respond. This is theoretically faster than having ns1.company.com hosted in Silicon Valley with end users in New York. With eDNS, users in New York will have their requests answered by servers which are usually physically much closer, and therefore faster.
2) An end user downloading and rendering the login page of a web-based application is probably the easiest part to deal with. Since there's nothing user-specific at this point generally object here are statically cacheable.
Leveraging an edge HTTP content delivery service, such as Akamai's EdgeSuite service, tries to make sure the end user will be downloading this static content from a webserver cache somewhere closer than the origin. Static content here typically includes JavaScript, JPG, GIF, PNG, CSS, and text. Edge delivery services also tend to add gzip compression to these files, reducing data transfer and speed to transfer. Files are cached for some configurable time and new files are retrieved from origin by the edge servers when an end user makes a request.
This is a well-understood problem and solution, and most CDN's in existence today basically provide this as a baseline service.
3) Once a user types in their identifying information and clicks login is where the complexity gets introduced. Usually when a user clicks the login button, there's a database lookup to validate user-supplied credentials, a session is instantiated for the user, amongst other things. In either case, these server-side events require end user interaction with the origin and the edge delivery model above simply cannot handle it. For this, a new trend in CDN technology has developed in the form of dynamic application acceleration. Akamai's service in this arena is called Web Application Accelerator (WAA) and utilizes their SureRoute technology to pass end user traffic back to origin and vice versa. In theory, WAA bypasses the BGP that most providers use by maintaining their own (more optimized) route tables, thereby decreasing the latency an end user experiences.
Since this is a relatively new challenge to address en masse, it's understandable that Akamai's solution leaves a lot to be desired. However, their service is significantly faster for almost any type of application, and smaller companies simply don't have the expertise or funds to build their own application acceleration infrastructure. The major online retailers and MMOG operators figured this out years ago and have been building out their own infrastructure, but the cost-prohibitive nature of these undertakings is a large obstacle to overcome.
Interesting note: there have been more and more companies competing in the application acceleration space with packaged solutions but I think we're still a bit aways from having your average medium-sized SaaS company deploy these things.
For web-based applications, the following almost always happens (regardless of industry, form, or function):
Steps (necessarily very high-level)
1) user pulls up some hostname (app.company.com) in a browser
2) user sees a page, usually a login page, accompanied with text and images
3) user logs in and proceeds to use the application in any number of ways
Since these three steps are effectively universal in SaaS, it is worth our while to analyze these steps in an effort to increase the accessibility of these things from the edge.
Analysis
1) An end user typing a hostname into the address bar of his browser and clicking "go" triggers a number of events. First, the hostname typed in needs to be resolved to an IP address via DNS. Once the IP is known, our end user connects to the IP requested, and issues HTTP GET's based on the server response (HTML).
Leveraging an edge DNS service, such as Akamai's eDNS service, will ensure that a nameserver most accessible to the end user will pick up the request and respond. This is theoretically faster than having ns1.company.com hosted in Silicon Valley with end users in New York. With eDNS, users in New York will have their requests answered by servers which are usually physically much closer, and therefore faster.
2) An end user downloading and rendering the login page of a web-based application is probably the easiest part to deal with. Since there's nothing user-specific at this point generally object here are statically cacheable.
Leveraging an edge HTTP content delivery service, such as Akamai's EdgeSuite service, tries to make sure the end user will be downloading this static content from a webserver cache somewhere closer than the origin. Static content here typically includes JavaScript, JPG, GIF, PNG, CSS, and text. Edge delivery services also tend to add gzip compression to these files, reducing data transfer and speed to transfer. Files are cached for some configurable time and new files are retrieved from origin by the edge servers when an end user makes a request.
This is a well-understood problem and solution, and most CDN's in existence today basically provide this as a baseline service.
3) Once a user types in their identifying information and clicks login is where the complexity gets introduced. Usually when a user clicks the login button, there's a database lookup to validate user-supplied credentials, a session is instantiated for the user, amongst other things. In either case, these server-side events require end user interaction with the origin and the edge delivery model above simply cannot handle it. For this, a new trend in CDN technology has developed in the form of dynamic application acceleration. Akamai's service in this arena is called Web Application Accelerator (WAA) and utilizes their SureRoute technology to pass end user traffic back to origin and vice versa. In theory, WAA bypasses the BGP that most providers use by maintaining their own (more optimized) route tables, thereby decreasing the latency an end user experiences.
Since this is a relatively new challenge to address en masse, it's understandable that Akamai's solution leaves a lot to be desired. However, their service is significantly faster for almost any type of application, and smaller companies simply don't have the expertise or funds to build their own application acceleration infrastructure. The major online retailers and MMOG operators figured this out years ago and have been building out their own infrastructure, but the cost-prohibitive nature of these undertakings is a large obstacle to overcome.
Interesting note: there have been more and more companies competing in the application acceleration space with packaged solutions but I think we're still a bit aways from having your average medium-sized SaaS company deploy these things.
Great Post! Good coverage of the Akamai solutions.
Test comment
Interesting article Tony, thanks. Could you explain this bit a little more?
>Akamai's service in this arena is called Web
> Application Accelerator (WAA) and >utilizes their
> SureRoute technology to pass end user traffic back
> to origin and vice >versa. In theory, WAA bypasses the
> BGP that most providers user by maintaining >their own
>(more optimized) route tables, thereby decreasing the latency
> an end >user experiences.
How much faster in practice would their routing layer be?
The difference in speeds largely depend on who your provider is right now and the location of your end users. I currently get approximately 33% improvement in Europe and 11% improvement in the US. The US performance is a little less telling since my transit provider runs their own mesh of top tier providers.
The timing was for a scripted transaction involving a login, interacting with a few dynamic components, and then signing out.
Akamai's SLA management system utilizes their SureRoute platform to pull a file and compare it to speeds achieved over BGP. However, since the file pulled involves no dynamic data they claim a much higher percentage of decrease in terms of delivery speeds.
It's also worth mentioning that the behavior of your application could play a significant role in how beneficial something like WAA can be. For example, if your application contains a lot of server-side processing of large data chunks which result in pre-summarized and optimized data being sent back to the end user, WAA will be significantly more helpful.
How do you "ensure" that DNS lookups go to the most "accessible" DNS server? I've observed that some (but not all) DNS servers appear to keep statistics on which of your DNS servers is nearest -- but only if it has to delegate requests to your DNS server regularly...
Great article.
I have a post I did a few weeks ago about Akamai that might go well with this one.
Akamai, ADM, and King James
Eric- users get the closest edge server (DNS or otherwise) via one of two mechanism: DNS or BGP Anycast. BGP Anycast works by having multiple routers announcing routes for the same IP address. The "closest" part of the equation comes from BGP, which will find the least expensive route (in terms of latency, route conditions, etc) from the end user. The CDNs who use DNS to do this redirect end user lookups based on some combination of end user proximity and/or some internal mapping scheme which is used to determine the edge server for a given end user.
So this isn't exactly a new idea of course. But years ago (about 4 or 5) was doing that with Internap. It is a rather expensive setup. I had to get cage space with them and then they handled all of the routing for me. They also guarantee the latency to most places so it takes off of your bandwidth costs if it gets slow. You can check out their offering here: http://www.internap.com/solutions/routecontrol/page1980.html
How would you address issues eith users using opendns.com?
Dns server doesn't see ip of end user - juse dns serger he is using. Because of this i think you cannot say that akamai system evaluates user proximity. Just his dns. Unfortunately there is great amout of users which uses opendns
Vladimir- that's true that it's the end user DNS server IP that is being evaluated for targeting. I don't think that means user proximity gets it entirely wrong, though.
Granted, it's entirely possible for my IP in San Francisco to be mistaken for one in San Jose 50 miles south of here (and according to my router this is actually the case).
Your comment about OpenDNS is interesting. It's true that more end users using something like OpenDNS convolutes the DNS proximity picture, but currently OpenDNS is primarily a US/North America thing, and their four (soon to be five) POPs in the US effectively splits end users into one of four regions, which is a lot closer than no checking.
Tony, If you are in Asia and use OpenDNS, it impacts when you try to use a CDN network
http://blog.goolamabbas.org/2008/02/24/impact-of-opendns-on-cdn-services-particularly-when-used-in-asia/
Sounds perfect to me. I have read this post with a great pleasure. You should write much more often.