Our CDN Journey Thus Far

Posted by Charles Buege on Jan 19, 2022 2:55:02 PM

Wednesday, January 19, 2022

by Charles Buege, Fuel Editorial Advisory Committee Member, Chicago Fuel Chapter Leader

Just sit right back
And you'll hear a tale.
A tale of a fateful trip,
That started from this tropic port,
Aboard this tiny ship.

Oh, wait, sorry. That’s the theme to Gilligan’s Island. Our journey isn’t nearly that dramatic or that long in duration.

Anyway, I’m here today to tell you the story about how our company has been trying to determine the best course of action for choosing a CDN. For those not in the know, CDN stands for content delivery network.

What is a content delivery network (CDN) you may be wondering? Well, for those who haven’t had to work with one yet, a CDN is a technology that is used to disseminate the static files for your website around the world using a series of servers to improve the performance for your site. That’s the simple definition of it. Implementing and choosing a CDN that is the right option for you, that’s where things get a lot more involved.

In the case of my company, we have a site that is predominantly dynamic. The main application is a single page application with some functionality that is run in other windows/tabs, but for the most part, 75% to 80% of the system is a single window application. This also means that our site is pretty constantly changing and new versions of the site are coming out rather frequently, at a rate of about once to twice a week for minor bug fixes and new functionality on about a monthly basis.

Why is this information a factor when choosing a CDN? Well, once we go live with new functionality, we want that to be available to our customers as quickly as possible. It is also possible, even likely, that when some of our new functionality becomes active, that old functionality will stop working completely due to any of a number of factors: old configuration settings being changed, database tables being modified or dropped completely, new forms superseding old forms, image files being replaced, etc.

This is something that needs to be taken into consideration when selecting a CDN – how quickly will the CDN go ahead and push out these new files into its infrastructure for the new users to get access to. Known as caching, the CDN will keep all of the files in its system for a pre-determined amount of time. This can range from a few seconds all the way up to a year depending on how your CDN is configured and what your CDN has available as options.

But this leads to another issue/thought that we came across: We want to go live with our new site and we want the old version to go away immediately. How do we do this? How do we deactivate our old site/cache/files and make our users get our new content immediately? This is another element that we had to consider when we started to look into CDN options:

  • What do CDNs offer with regards to immediate invalidation of old files when going live with new versions?
  • How quickly will our users see the new files? Do we need to purchase a higher tier of service to get our users a quicker refresh of content?
  • Will our users need to actively do anything like refresh their browser window to get the new site when we push out or is there something that the CDN can do on the back end so that the next time our clients request content, they will automatically get everything pushed to them fresh if we happen to do a refresh of data they are looking at fresh in the middle of the day?

And, for that matter, what if we had to go back to the previous version of our site because we found a bug in our new version? Can we do that quickly? If so, how quickly? Or would we need to redeploy the previous version of all of our code and just treat that like a ‘new version’ of code that we are deploying to the CDN? We found out quickly that different CDNs handle going back to previous versions of code in different ways depending on how the code is deployed in the first place. So, for the ability to revert back to a previous version, it would mean that we’d have to reexamine our entire deployment process, possibly make changes to it, and then we could revert back to a previous version more rapidly if we needed to. But how often have we had to do this? Over the last eight years, we’ve only had to do this a handful of times. We then had to ask ourselves – do we want to reexamine/change our entire deployment process for this quick fallback to a previous version or do we just revert our code to the previous version, do the entire deployment as if it was a new version, and continue that way? This was another question that we needed to ask ourselves – investment of our time and effort versus the potential need of having to do something using our past experience as a measuring stick against which to measure.

Next, we started to look into our static files. And we’ve got a lot of them. Whenever our site is compiled from its dynamic version (React, a JavaScript framework) into its static components to be loaded into the CDN, we get a lot of files. But when we started looking at all of the files, we found that while almost all of the React-based files changed every time, the majority of our images all stayed the same. Well, if the images predominately stayed the same, do we really need to deploy the images with the full application every time that we recompile the React site? No, we realized, there’s no need for that. And for that matter, if the images are all the same, then do they even need to be in the same CDN as our site/application? Can’t they be in their own CDN with a different set of settings telling the system that they can be out there, cached longer, before they need to be refreshed? Maybe the images don’t need to be refreshed more than on a weekly or monthly basis since they almost never change, but the files for the React site should be checked a couple times a week since they are more prone to changing.

Splitting the necessary files up into multiple CDNs is another option that we have been looking into. And by doing this, we’ve also found that we can take on a significant cost savings here too. Whenever you deploy files into a CDN, that’s when you are going to be taking on the greatest cost. Each time you deploy, that’s the most expensive action because the CDN then needs to deploy all of your files across its entire network, normally across high-speed connections around the world. So, if instead of pushing these images out with every deployment of the React code, we can instead just have the images pushed out on a monthly basis or, even better, only push out the images when something has changed, we can save a significant amount of money from the replication charges of the images being distributed throughout the CDN infrastructure. Additionally, since the React files are all very small Javascript, HTML, and other tiny text-based files, when they do replicate through the CDN network, they take up less bandwidth and will also end up costing less.

One of the final factors that we considered is with regards to who the primary users of the CDN system would be. While I was looking into CDN options for us, I concentrated on looking at the different cloud providers that we were already using in an effort to keep everything under one umbrella and keep the billing consolidated. Well, after looking at the functionality of what our current cloud providers offered, I discovered that a lot of the functionality that we would need to do wasn’t currently present and we’d need to write a lot of scripting and processed to make the system do exactly what we wanted it to. Was that going to be a big deal? Not really, no. It was going to be pretty easy scripting, it was going to be customized to give us exactly what we wanted, and it would only take about a month or two to write everything.

What I, and this is fully on my shoulders for not taking this into consideration at the time, had not thought about was that the development team was working on a new version of our site currently and had been working with a development version site to be doing what they needed to. Granted, I knew this, but I hadn’t truly considered the implication of this. Well, after speaking with the team lead who setup their development environment, he was already working with a CDN solution that was not part of our current cloud providers, so not under the current umbrella of what we have today. I was ready to dismiss it out of hand, but then I thought: “Wait. He’s the team lead. He knows a lot about this stuff. Let me at least look at this tool first. He wouldn’t have chosen this tool to do this without looking at our cloud solutions first, so he must have chosen this for some reason.” I then proceeded to sit down with him and asked him to give me a side-by-side comparison between what I’d found from our cloud providers and with the tool that he was working with. I showed what I’d found, what would need to be written to make our cloud providers work, and how it would work with our current system. He then showed me what his solution entails. His solution was exceptionally simple compared to what I would have had to write for our needs. Where I would have had to spend a month of script writing, almost all of the functionality I wanted was already in place with the CDN he was using.

After that realization was pointed out to me, it became a matter of cost comparison – will using this tool that is not part of our standard billing be that much more expensive than our current cloud provider that it is cost prohibitive to use? Nope, it wasn’t. Turns out that it is actually less expensive than going with our cloud provider’s solution and the amount of time it would have cost us to write all of the custom scripts, test everything to make sure it works as we want it to, the future upkeep, and any additional issues we would have run into down the road.

So, in summary, after looking between the different solutions out there, we were able to come up with a plan that fits our needs. But here’s the take-away that I would recommend everyone learn from this article. These are the questions and thoughts I wish I’d known to ask myself before I had taken on this project to begin with:

  • How much of my data is going to be changing when pushing to the CDN?
    • If I can split up data that isn’t changing very frequently from data that is changing frequently into multiple CDNs, I could potentially have some cost savings.
  • How quickly do I need to have the CDN “go live” with my new site?
    • This will affect what tier of CDN service I would want to select.
  • Will I ever have a need to fall back to a previous version of my code without doing an entire redeployment of my site?
    • I'll need to see if my CDN allows me to do this. If I don’t need this functionality, then I don’t need to pay a premium for this capability. If I do need this, then I may be able to give non-developers the ability to revert us back to a previous version of our code in the event of an emergency.
  • Do I have the right people involved in identifying the correct CDN solution from the beginning?  Make sure that I do.

In summary, the most important thing is that to be sure that you’re going to be able to do this project correctly, you need to make sure that you’re going to have the right resources, the right people, and the right questions answered from the start to make everyone’s lives easier and make the project go that much smoother.

Charles Buege is the Senior DevOps Engineer for Temeda, an Industrial IoT company out of Naperville, Illinois. He runs an IT-based Meetup group called "The IT Crowd" and has been mentoring many people wanting to get into the IT field for over twenty years now.

Topics: Charles Buege

Posts by Topic

see all

Subscribe to Blog Updates

Recent Posts

Posts by Topic

see all