Catchy title, you say? It is a bit off-topic perhaps, but not really, and it does sound logistics related somehow, and actually it is. In fact, it is about the supply chain of my blog, and how to ensure a timely and reliable delivery of my blog contents to each and every reader throughout the entire Internet. And while it has very little to do with most of what I usually write about, the similarities to real-world logistics are strikingly familiar, and thus worth mentioning. Indeed, there are some supply chain lessons in practice to be had here. That said, this blog post is perhaps of more use to my fellow blogging community than to my fellow supply chain community, so if you’re looking for some supply chain gems, you may skip reading this post. If you’re looking for some blogging gems, please read on.
Have you noticed?
First off, a question to my regular readers? Have you noticed any changes in loading speed recently? Does this blog seem faster? It should, and I will get to that in a moment. If it’s not faster, please let me know, as I must have done something wrong then.
The supply chain of my blog
So, what has happened? Well, a year ago I wrote about the supply and demand side of a blog, and even set up a model framework for the supply chain of a blog:
However, focusing primarily on the chain itself, I did not pay much attention to how the outgoing flows were delivered. In logistics terms, I did not pay much attention to my 3PL or my carrier. I should have, because as I have written earlier, the carrier is what drives flexibility and reliability. That is why the delivery network is important.
The need for speed
The delivery network is as crucial to a blog as it is to any business. While it is important to have the right infrastructure, aka cables and connections, what really matters most – as in much of real-life logistics – is delivery speed. Of course, initially, it may seem that the delivery speed for blog content depends primarily on the infrastructure on the reader side, i.e. the individual Internet connection, the current Internet traffic in the vicinity of the reader, the device the reader is using and even which browser the reader has, but that’s not all. In fact, it also depends on how I serve my readers. There is not only a pull speed, there is also a push speed.
Serving and delivering – 3PL
Now, using a logistics analogy, very few bloggers will use 1PL, that is serving the blog from their own computer that is stationed in their own home or their own office and run a cable all the way to the readers home. Most bloggers will use 2PL, that is hosting their blog with a webhost, like I do, where the actual blog resides on a server, and in my case the server is in the US. More correctly perhaps, this is not 2PL, but 3PL, as you have little or no control or say in type of server or Internet connection from that server to the reader.
Warehousing
In logistics terms the server can be viewed as a centralized warehouse. Normally, “your” server will also host many other blogs, so you will have to share resources with those. Just like in real life the 3PL is serving many clients, and is likely to give different priority to different clients, meaning that you (your blog) will have to queue until it’s your turn to send out what the reader wants. This can be abated by securing a dedicated server that only hosts you, making sure that you are the preferred customer. That way you can make sure that you will not have to compete with others for the server’s scarce resources. If you need to know, I am using Blue Host for this, a hosting company I’ve been overly satisfied with.
Make to Stock or Make to Order
The reason why delivery speed is important is that a website that is served from a server is built on a Make-To-Order basis. The reader asks for a certain post or page, and the server assembles it on the fly. There’s nothing on the shelf, and all the bits and pieces have to be located and sent to the reader’s browser on a perhaps slow or sluggish Internet connection, maybe criss-crossing the globe several times before ending up with my reader. That’s like your mailman bringing you a piece of hardware every 2 minutes instead of a truck bringing the whole lot at once. However, this Make-To-Order can be turned into Make-To-Stock, as in the truckload analogy. In blogging lingo that is called caching. When using caching, the server will essentially preload or preassemble your posts, ready for delivery, and when a reader requests them they are sent off in one go, much faster than making it to order. That is very useful since the server doesn’t have to assemble posts again and again, but can simply deliver what is in the inventory. For the bloggers among you, I am using W3 Total Cache, although WP Super Cache appears to be a notch better.
It’s a long way to Tipperary
Coming back to speed and the reader side, while caching delivers content en bloc, and thus improves reader experience, if the reader sits far from the server there will be some lead or lag time, as it is in real life, when sourcing and sending your goods from and to far and away locations. Add to that, this is even more a problem if the reader’s Internet connection is not up to par. While my cached post may travel on a ten-lane freeway while still in the US (broadband), in some remote village in India, it may have to follow a narrow and winding dirt road (dial-up). That said, considering the amount of Internet traffic at any given time, an empty dirt road can be much faster than a clogged freeway.
Content Delivery Network to the rescue
Switching back to logistics for a moment, if I wish to serve my customers faster I may consider using decentralized warehousing. This is also possible when delivering web content to readers and in blogging lingo that is done using a Content Delivery Network, or cloud computing to use another word. Not only is it possible to have my posts made to stock, I can also pre-distribute them as close to the intended reader as possible, which means the posts may not have to travel the whole globe before reaching my reader, but can take the shortest and fastest path. This ensures timely and reliable delivery of my blog posts to any reader, wherever he or she may be. Depending on how much of my blog content I pre-distribute, it may even save me from a supply chain disruption, should my web host go down. Thus, using a Content Delivery Network or CDN for short ensures flexibility and agility, two very important parameters in logistics. Coming to think of it, a CDN is perhaps similar to 4PL, or maybe it’s still 3PL? Anyway, after doing some research on this I ended up with Amazon CloudFront as my CDN, giving me a global network of edge locations in the United States, Europe and Asia. If you’re blogger, let me tell you that Amazon CloudFront is extremely easy to set up, and more importantly, it is highly affordable to the average blogger, as Larry Ullman explains in his post on the matter.
Why am I doing this?
Like all businesses, I too must evaluate my customer base, i.e. reader base, and make sure that I serve them the product they ask for when they ask for it. Looking at my reader base and visitor statistics, not all of them are in the US, but many of them are actually in the so called emerging countries, and I want to serve them just as well or fast as I serve my American clientele.
Is it working?
I have been experimenting this week, trying out make-to-order versus make-to-stock and looking at centralized warehousing versus decentralized warehousing. Judging by the performance meters measured on pingdom.com and various other services, the latter won in both cases. Witch caching only, WP Super Cache seemed to outperform W3 Total Cache, but the latter integrated much better with Amazon CloudFront, and in the end it is about finding the service that matches my needs: W3 Total Cache and Amazon CloudFront. While my US readers on a broadband connection are likely not to see any difference in the speed of my blog, I am sure that it will matter to my far-and-away readers. If you are one of my regular readers, have you noticed any improvement? I’d love to hear from you. What I have notices is a little bit of lag time for serving images. While the text displays instantly, sometimes the images will lag just a little bit behind. Noticeable, but not annoying.
The Cloud and the Supply Chain
A similar view, comparing the cloud, aka a CDN, with a supply chain, can be found in the post Can the Cloud learn from Supply Chains? on Christian Verstraete’s blog. Here, Christian does a much better job than me at identifiying the individual elements of a supply chain and the corresponding elements of the Cloud.
Update 2011/05/28
As to my own affordability, March 2011 cost me $8 for this. April 2011 incurred $18 in costs, and May was showing a similar trend, which is why I turned it off, since this was getting way to expensive for me. Besides, monitoring my blog’s global response time on pingdom.com I could see very little, if any, improvement. I am now testing CloudFlare, which seems to be a better and cheaper alternative, and as the test results confirm CloudFlare beats CloudFront by a considerable margin.
Related posts
- husdal.com: The supply chain of a blog
- husdal.com: 2010 in retrospect
