Subscribe to our newsletter
Get the latest news and industry insights in your inbox.
Subscribe to our newsletter
Thanks for subscribing.
Moving to a new content delivery network (CDN) can seem daunting from an operational standpoint, and it’s important to ensure your CDN is set up correctly before you start migrating all your traffic. In this post, I’ll outline a few steps you can take to experience a smooth migration process to Fastly.
First, ask yourself two questions. If you’re currently using a CDN, what do you like and what don’t you like about it? Also, what parts of your application would you like to cache, but haven't been able to? The answers to these questions will help you determine what you care about most, and what you want to get out of our content delivery solution.
If you haven’t already, sign up for a test account. We recommend putting a small portion of your traffic on Fastly while you’re checking us out (this will let you see how your content works in a real-world setting).
There are three ways to start testing traffic on Fastly:
The best way you can test Fastly is by issuing a local DNS override of your own machine through an /etc/hosts file override. Doing this override in a local setting (such as your office network) will let you test Fastly in a real-world scenario before moving all your traffic over. Many customers have done this to great success — they were able to have their entire staff working on their site without disruption. This also gives your co-workers the opportunity to alert you to any issues they encounter while you’re testing. With internal traffic being served by Fastly, you can fine-tune configurations to make sure the site doesn’t break and that assets are being cached properly.
Your staff can go about business as usual, giving you insight into whether the CDN is working as it should.
Another way to test is to start moving your traffic over by region and test how the CDN works in a live environment. You can either choose to migrate a percentage of your total traffic or migrate traffic by region (e.g., migrating 25% of American traffic).
The method that works best for you depends on your individual DNS provider. Random assignment of traffic doesn’t have the same clarity or insight as a regional switchover would — if only one in five users from America gets an error message when he requests an asset, that can take time to track down. This is why we recommend a regional switchover, but again, the best approach for your individual business depends on your DNS.
If you’re already implementing domain sharding, your sharded domains are a great opportunity for a partial migration to Fastly. First, split your assets into a number of subdomains, and then migrate one subdomain over and see how it functions. This is a more controlled approach that allows you to let the CDN run and test it as much as you want before switching your entire site over.
Once you’ve moved some traffic over to Fastly, ask yourself these three questions to determine if your migration has been successful:
We work hard to make the migration process as seamless as possible. But issues still happen, and the most common problems tend to be with assets not caching when they should.
One of our most frequently asked questions during the testing and migration phase is “Why is this not caching?” and often has to do with existing
Cache-Control header configurations which we will never cache.
CMS and developer frameworks may have unnecessary
Set-Cookie headers that get returned on every object. CDNs, by default, won’t cache responses with a
Set-Cookie header for good reason: if a
Set-Cookie header contains a session ID, and the
Set-Cookie header was cached, the session ID would be cached with the
Set-Cookie header. This could possibly expose personal information to other users, so any time Fastly sees a
Set-Cookie header on anything, our CDN will not cache it. Make sure that your system is only returning
Set-Cookie headers where appropriate.
Fastly also won’t cache assets labeled
Cache-Control: private and we respect items labeled max-age as well. Learn more about common cache problems and how to solve them.
One of the best things you can do when migrating traffic over to a CDN is to set up logging. Logs give you a picture of historical stats over time as well as real-time information, so that when something anomalous happens, you can look at your logs and see what was happening when the anomaly occurred, leading to faster fixes. You can also use our steaming logs for business intelligence. Other CDNs will collect limited analytics for you, but you won’t see that information until several hours later.
Setting up logs yourself is fairly straightforward — our documentation will help get you up and running, so you can start streaming logs to your own third-party monitoring tools right away. Note that for a number of regulator, performance, and privacy reasons, Fastly doesn’t store logs.
Here are some great tricks other Fastly customers have used when setting up their logs.
We recommend you set up Origin Shield as soon as possible. You can designate one of Fastly’s points of presence (POPs) as a shield node to your origin server. All origin requests and cache misses then go through your designated Origin Shield POP before hitting your origin. And when other POPs receive requests for assets they don’t have cached, those POPs will request the asset from the shield node first, instead of your origin server. This diverts even more traffic away from your origin and leads to more performance gains, as well as protecting the origin during high-traffic events and reducing strain on your own infrastructure.
At Fastly, we make it easy for you to get up and running on your own, without needing to engage an account rep. If you have any questions, our support team is ready to help you through your migration process.