So You Want to Host a Comic?
You’ve made a comic, your comic might even have a name, but you want to get it out to the world. “How do I setup a website?” I get asked this question a lot, and I usually end the conversation there and advise that Tumblr serves the needs of the many, and its extensibility and customization can serve the needs of the rest. You can even host your domain on it.
Some people are taken aback by this, and it feels like I gave the equivalent of “Now get out of here, kid, SCRAM!” But it is honest advice.
I have a 15 year background in IT. I’ve worked desktop support, I’ve worked at datacenters with tens of thousands of servers, I’ve worked at places that produce top 50 websites, I’ve written cookbooks, modules and the occasional program to make sense of it all, and as of late, I’ve slung more CSS and Javascript than I’m comfortable with.
“I want to make sausage!”, you might declare to the sausage maker, and back at you would stare the worried eyes of a person who has taken thousands of little piggy lives, and stuffed them into millions of little piggy treats.
Maybe the butcher with the thousand-piggy stare is right. After all, you’re a comic artist, why dirty your hands with the sausage at all?
But what happens when you need more than what Tumblr, Blogger, or Wordpress.com can provide? What happens when you want to make some very special sausage? Well, there are ways, but it’s very hard to keep the blood off your apron, and your audience.
Backups
You have your comics, but it is the year 20xx, and chances are your comics are a bunch of PSDs and PNGs scattered about. Without these, you have no comic, and I assert that having no comics is a fundamental problem for a comic creator. How do we avoid this? And what the hell does this have to do with hosting?
Local Backups
You should have a local, versioned backup of your entire system and all attached storage, ideally on a RAID 1. Apple provides you with Time Machine, and similar utilities can be found for Windows. Once you restore a PSD from a year ago that you accidentally overwrote, you’ll never go back.
The RAID functionality ensures that a single hard drive failure won’t wipe out your history. As a habit we have taken to carrying one of the hard drives with us when we travel, in case our home is burglarized or suffers some other catastrophe.
Remote Backups
You should have a remote backup of all of your crucial files via something like Dropbox, and you should also consider something like CrashPlan which backs up your ENTIRE system remotely. I recommend using DropBox in your backup mix because they will save all of your files indefinitely, so even if you delete a file or overwrite it, they keep it for you.
Ok, I’m backed up, but what does this have to do with hosting?
It is important that you mentally and logistically prepare yourself for the eventual failure of your equipment. By practicing obsessive backups, and especially by surviving your first catastrophe, you inoculate yourself against a sedentary approach to running the IT portion of your business. You WILL go down, you WILL suffer a failure, but if you keep regular backups, you WILL get back online.
After all, what will you populate your new site with if all of your comics are gone?
Get your domain
Not tomorrow.
Not next week.
Not in 10 minutes.
Get YourAwesomeName.com, get YourAwesomeComic.com, get YourAwesomeComic.WhateverYouCanGet.
You’re probably not getting your domain right now, and that’s totally ok if you enjoy wallowing in regret.
Design
You’ve decided that you need something more than what Tumblr can offer, but what is it? What is your vision? How did Tumblr block you? What functionality do you need?
Mock up your new home, draw out what goes where, make some wireframes, write some pseudocode for that functionality you needed.
Then toss all that garbage out, and hire a real web designer.
Select a Content Management System
It is tempting to want to write some backend code to manage the content for your new site, but you probably shouldn’t. It is very likely that someone else has written something better, and that every single line of code you write will be a superfluous liability.
ComicPress is a theme for Wordpress, and it does just about everything you need. For the rest, Wordpress Plugins can fill in just about every other gap.
This is NOT a recommendation for Wordpress, as my relationship with the software is rather strained. However it does the job well enough that I haven’t bothered to move away from it. While the barriers to escape are low, it is my begrudged captor, and we spend many a night engaged in a rambling yet crucial discourse.
Your designer should have experience working with various Content Management Systems, and you should take their suggestions and heed their advice. If you have ideas on what CMS is best for your project, you and your designer should be on the same page.
Protecting Your Resources
The server your site is hosted on will become one of your most precious resources, and every hit your website gets incurs a small computational load on that server. Most of this load will be a function of your CMS and the amount of content you have. Other factors will include the type of content, plugin behavior, themes, and so on. Yes, you can optimize the speed with which requests are returned, but the point of diminishing returns on that type of work comes early and hard. What to do?
Cache All The Things
The end goal of a CMS is to produce HTML. A rather circuitous path is followed to get there though. Once your web server gets the request, it passes it off to whatever language interpreter or CGI gateway your CMS was written for, then thousands of lines of code are applied to the request, and dozens of queries are sent to a database.
This takes time.
The end result is a simple HTML document. Your CMS probably has functionality to cache this HTML document, so that if another request for a page (say, your front page) is made, it can skip directly to the punchline, instead of setting up the joke every time. The difference in performance is like magic: a fully processed request takes about 2.59 seconds, but that same request after being cached takes 0.15 seconds.
This is a marked improvement, but maybe you’re better off if your server doesn’t get hits at all.
Cache All The Cached Things
The Content Delivery Network is an often underutilized tool. Many people use them to offload the burden of image, Javascript, and CSS requests from their servers. However these same types of resources are often the least taxing as far as computational and IO resources go. You do indeed offload connections, bandwidth, and some load by letting a CDN cache and serve static resources, but the most taxing thing your server does by far is churn out the end product of your CMS: HTML pages. Using a CDN for images and not HTML is like using a truck for getting groceries and not hauling freight.
So why not serve your HTML, your entire site, via a CDN?
Yeah! Why Not?
This seems like an obvious thing to do, but as with many seemingly obvious things, there’s a catch: a CDN cannot front an interactive server object(like the action target of an HTML form). This puts the onus on you to limit the interactions with your server. If the vision for your site can tolerate such restrictions, serving your entire site via a CDN is a great idea.
“What about comments?” you might ask. “Isn’t that a server interaction?”. It is, but by using Disqus you can add comments to your site, and those comments will be handled entirely by the Disqus servers, freeing your server from that interaction. This is not an endorsement of adding comments to your site(that’s a whole other discussion), but rather an illustration of how AJAX-style programming can reduce the amount of interactions your server handles without losing functionality.
So what’s the point of this?
Whereas your actual server will be on Server.YourAwesomeComic.com, your CDN will be on www.YourAwesomeComic.com. Your actual server will see almost no traffic aside from your CDN’s proxy server. This diminishes the need for a powerful server(or servers), which diminishes the chances of powerful bills.
Hosting your site off of a CDN can also hide server downtime. Depending on how you configure your cache directives, you can be down for an hour or so before anyone notices. Also, if you thoroughly obfuscate your server’s actual domain name, you can get a small measure of security against targeted attacks. More importantly, if you ever get a huge traffic spike, a CDN is much more capable of absorbing that spike than your server is.
I’ve been using Amazon’s Cloudfront, and it’s a great CDN, though CloudFlare seems especially suited to our purpose, what with their “Always Online” feature, and our stubborn desire to always be online.
The improvement in performance is also impressive, that .15 seconds is slashed to 0.07 seconds, mostly due to simple physics: the CDN server that is delivering your request is probably physically closer than your server is.
Reduce Requests
Using something like Google’s PageSpeed analyzer against your site will result in a number of helpful suggestions, but by far the best advice is to reduce the overall amount of requests to your site. This can be done by combining CSS and Javascript via a Minification plugin or service(Cloudflare claims to do this), and by combining the images that make up your site design into a CSS Sprite.
Along these lines, reducing the size of your comic can also be of help, both in site performance and in your CDN bill. ImageAlpha + ImageOptim on the Mac make for a powerful combination to reduce the size of PNGs. Also, you should probably be using PNGs.
Selecting a Hosting Provider
Before diving into this, there is something you must know:
If you are not using SSDs, you are wasting your life.
If a hosting service does not host your entire solution on SSDs, they are not worthy of your dollars. That earlier number of 2.59 seconds? That’s on a legacy host I’m currently in the midst of migrating from. The same test on a new host with SSD storage takes 0.52 seconds, that’s almost FIVE TIMES faster.
Also, don’t use a Windows host. Just don’t. Microsoft continues to try to push their OS as a serious racehorse, but its track record indicates a long future out to pasture. Another problem with using Windows is the low barrier to entry for Windows administration. This causes an influx of people into the field who have no real computing knowledge, yet happily chirp up and say “I’m a Windows technician!” There is a lot of noise in that market, and that makes it hard to find some signal.
That said, there’s different approaches to hosting, and it mostly boils down to Shared Hosting, Virtual Hosting, Dedicated Hosting, and PaaS/Cloud Hosting.
Shared Hosting
This is an area I’m pretty ignorant in, as I’ve never found a shared host I liked. I have heard good things about MediaTemple though, and they have recently migrated many of their solutions to SSD storage, which seems a confirmation of the good things I’ve heard. Shared hosting is an excellent choice for beginners, and some professionals as well. Some shared hosting providers even offer specialized hosting packages for various CMSes.
Virtual hosting
Most hosting available falls into this category. Historically the market was pretty diverse, and this diversity was helped along with the arrival of Amazon’s EC2, and Google Compute Engine. However after applying our SSD requirement, the available choices quickly diminish. I have personally tried Linode and Digital Ocean, and their performance, features, and price are hard to beat.
Dedicated Hosting
You probably don’t need a machine all to yourself, especially if you follow some of the guidelines in the previous section. I also tend to argue against a dedicated host because virtual hosts tend to be more reliable.
A virtual is usually hosted on a machine with RAID, it’s probably religiously backed up, it probably has redundant power supplies, more than likely it has ECC RAM, and it is probably in a cluster of machines that can survive if a single node goes kaput.
Your dedicated host will probably be well-worn hardware with no RAID, backups as a pricey option, low-grade RAM, and you will be waiting on support for hours or days when your server inevitably goes down.
If you end up needing dedicated servers, follow the SSD rule, hire an admin, and hope for the best.
PaaS Hosting
PaaS is what most people mean when they say “Cloud Hosting”. Before I go on, I must state that this is the future of hosting and web applications in general. It is the only sane way to deploy and truly scale your website. I say this even after my aborted attempt to move The Devil’s Panties to Google’s App Engine. I also say this in part because I last deployed that “app” over 4 years ago, and it is still running.
The problem with putting your comic on a PaaS is that the type of thinking required to write software that conforms to the high-concepts of PaaS is rare, and thus CMSes that work on a PaaS are rare. You’re not going to install Wordpress on App Engine or Heroku and have a good time of it.
If you have discovered that you MUST write code, or if you have discovered a CMS you like that can fully operate in a PaaS, I encourage you to use a PaaS, if only to light the way for the rest of us.
It isn’t that PaaS isn’t ready, it’s that WE are not ready.
Maintaining Independence
Ok, you’ve got a design, you’ve selected a CMS, you’ve got a hosting account, and you’ve uploaded your first few comics.
Great.
SSH into your server, do an `rm -rf /`, log in to your control panel, click delete on your account.
Now bring your comic back on another hosting provider.
What is the purpose of this hypothetical exercise?
Between now and the heat death of the universe every server has a 100% chance of going down. It might be down an hour, it might be a day, it might be forever. Your server will be felled, if not by meteor strike, then by the amoral shrewdness of business.
When that happens, flailing about is not an option. Is this the end of YourAwesomeComic.com?
Surely not.
You were stirred to action by my rant on maintaining backups, and every step along this journey you were planning how to keep your new site safe. You had backups.
You Did Have Backups, Right?
More to the point, WHAT did you back up? Did you backup your .pngs? How about your modified theme files? Your CSS? The CMS software? What about your database?
Awesome.
What about your server’s software, your server’s configuration files? Did you get those little scripts in your home directory? What about all those cron jobs? Will the combination of all of your CMS files and data yield the same result on another host? Did you forget anything?
How To Not Forget
The best way to not forget, is to never remember. You should develop your hosting solution using tools that describe the eventual state of your server and software, and use that tool exclusively to construct your hosting setup. Instead of remembering to copy that script or cron job, you should describe that cron job, you should describe the setup of your database, the configuration files for your web server. Then you should use this description to create, modify, and deploy your site’s server config, CMS config, and to a degree your site’s data and content. This collection of descriptions should become a sort of incantation, and reciting that short incantation should bring your site to life.
The ability to create and re-create with such ease is the promise of Configuration Management. Tools like Puppet and Chef have brought that promise closer to reality. In my experience though, they fall a bit short.
Short of what? Short of this:
git clone http://repo.com/devilspantiesdocker build -t devilspanties-image .docker run -d --name devilspanties devilspanties-image
Provided a server has Docker installed, that is all it takes for me to spin up a new instance of Devil’s Panties.
Whereas traditional configuration management tools describe the eventual state of a server, Docker focuses on the creation of a container. A container is like a virtual machine, except much lighter. A container contains an entire OS, and all other dependencies required to launch your application (in this case, your CMS). You can take this container and move it anywhere that has Docker installed, or you can use a Dockerfile to describe the creation of your container, and recreate it anywhere else.
Docker, or something like it, is the future of application deployment, and you should consider using it to manage the collection of bits that is your webcomic.
Do I Have To?
Using Shared hosting, a PaaS, or “Managed” Virtual/Dedicated hosting eliminates the need for dealing with configuration management, as those types of hosting providers are likely to use tools like Puppet, Chef, and Docker in-house to provide you with an easy user experience.
If you go with Unmanaged Dedicated or Virtual hosting, you don’t have to, but it is recommended you at least consider it, if only to run through the discovery process of what it would take to re-create your site somewhere else.
At a minimum, no matter the type of hosting, you should keep an automated daily backup of your site’s files and a database dump, and you should store this on something like Dropbox(there is a functional Wordpress plugin for this). If you followed the previous advice on backups, when your site’s Dropbox backup is synced to your local computer, it will then be synced to your local versioned backup device(that RAID1 you picked up earlier). This means you have remote backups to Dropbox with history, and if Dropbox ever disappears, or your backups get deleted, you will have a local copy with history.
On occasion, you should practice using this backup set to restore your site. Untested backups are almost as good as having no backups at all.
What Does This Have to do With Independence?
If you can pick up and move your entire site when your hosting provider fails, you can pick up and move your entire site whenever you want.
This removes barriers to exit should another hosting provider pop up offering more space, more speed, or a better price. It enables you to actually use the free market to your advantage, both in getting better deals, and in getting out of bad deals.
Closing Thoughts
My goal in writing this isn’t to dissuade you from rolling your own hosting solution, is what I would say if my goal wasn’t to dissuade you from rolling your own hosting solution. It is in-part my goal to dissuade you from going down this path if there is no need. However if the need arises, put on your apron, and remember what it takes to make sure your fingers don’t end up in the sausage: you need those fingers to draw comics, after all.
-obby
