The Easy Way

Apache is one amazingly flexible web server. It handles multiple domains with ease, using the VirtualHost method, and the ServerAlias directive allows you to host permutations easily. Consider the following totally made-up example:

<VirtualHost *:80>
  ServerName blog.fosketts.net
  ServerAlias www.blog.fosketts.net
  ServerAlias fosketts.net
  ServerAlias www.fosketts.net
  DocumentRoot /var/www/
</VirtualHost>

This looks great, right? It tells Apache to watch any IP on port 80 for an HTTP request for a server called blog.fosketts.net and to serve it the content from /var/www/. It also tells Apache to accept plain old “fosketts.net”, “www.fosketts.net”, and even ”www.blog.fosketts.net”.

What’s Wrong With Easy?

Although accepting all these hostnames seems like the friendly and correct thing to do, it’s not in your best interest. It tells web clients that the exact same content lives on four different servers, and they’ll start linking to your content every which way. Pretty soon you’ll have incoming links for all four hostnames. So what’s wrong with this?

1. It’s confusing for users – They’ll start asking, “is your site www.fosketts.net or blog.fosketts.net?” It’s fine to segment things, but confusing to do it unnecessarily.
2. It’s hard to configure and maintain – Once your site starts getting linked to and shared around, you’re stuck supporting all possible combinations. When you switch hosts or server platforms (ahem) you have to make sure everything still works.
3. It hurts your search ranking – You might not be all that concerned with search engine placement, and it’s not as bad as some say, but splitting your traffic between multiple sites also splits your “SEO juice”.
4. Web crawls overload your servers – Search engines treat each host name as a different server. If you allow links to multiple names without a proper redirect, you’ll get multiple crawls, often at the same time.

In summary, the easy was isn’t good. ServerAlias looks friendly, but it’s not a friend when used this way.

Let’s say your name was Stephen, but some people call you Steve. Rather than insist on one or the other, you could just go through life accepting either. But imprecision can lead to issues, even in the real world. Will people know to look up Stephen in the company directory when they know you as Steve? You might start getting duplicate junk mail for both names as they find their way onto mailing lists. Then there’s the embarrassing “I always called him Steve” moment at the company party, when someone feels like they’re not part of the “in crowd” that knows your real name. It’s best to be friendly and accept anything but politely suggest that everyone uses just one name in the interest of sanity.

Redirection is Right

The best approach in life is also the correct method on the web. Your server should be set to accept any number of possible names in case someone comes in with the wrong one. But rather than blithely accepting the name, your server should issue a proper “redirect” call, instructing the browser or crawler to reload the page using the correct name from that point on.

This is simple when using Lighttpd. I just added the following lines to my lighttpd.conf file and it magically issued a proper redirect whenever someone came in using the “www” name:

$HTTP["host"] =~ "^www\.(.*)$" {
  url.redirect  = (
    "^/(.*)" => "http://%1/$1",
  )
}

I was amazed that I could locate no such universal redirect option in Apache. You can do all the RedirectMatch calls you want, but their regular expressions only operate on the path part of the URL, not the hostname. This is great for adding a “www” but makes it impossible to create a generic rule to eliminate them!

Instead, we have to use RedirectMatch on each VirtualHost domain individually. This also opens the possibility to deal with other conditions we might come across, but it’s not as simple and clean as the Lighttpd method.

Here’s where the magic is. Each VirtualHost configuration you add (in /etc/apache2/sites-available on Ubuntu) should include rules to deal with the incorrect names as well as the single correct one. Here’s the correct redirect rule for the example above:

<VirtualHost *:80>
  ServerName fosketts.net
  ServerAlias www.fosketts.net
  ServerAlias www.blog.fosketts.net
  RedirectMatch 301 (.*) http://blog.fosketts.net$1
</VirtualHost>

<VirtualHost *:80>
  DocumentRoot /var/www/
  ServerName blog.fosketts.net
</VirtualHost>

The first VirtualHost block matches all the incorrect hostnames and redirects them (with a code of 301 for “Permanent”) to the correct hostname. The “(.*)” part matches any and all paths and arguments and the “$1″ part appends them to the new hostname. Then we set up another VirtualHost block for only the correct hostname and put any and all rules in there.

This way, any clients or crawlers that hit “www.fosketts.net” or any of the other alternatives will get a proper 301 redirect to “blog.fosketts.net” and go about its business. It tells Google that there is only one proper server name for this content and encourages users (who will likely copy and paste from the address bar) to use it, too. Neat and tidy, and very friendly.

I’d love to hear alternative methods of doing this. Please leave a comment if you have a suggestion that uses a 301 redirect and works across multiple domains!

© sfoskett for Stephen Foskett, Pack Rat, 2010. | How To Force Apache To Redirect To Canonical Hostnames, or ServerAlias Is Not Your Friend
This post was categorized as Enterprise storage, Everything. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

But cloud services are different. Seriously! Cloud services don’t need standards because:

1. Cloud services are still rapidly evolving – No one knows how they will look in a year, let alone a decade, and a premature standard will be worthless. Similarly, it’s not at all clear what use cases will eventually win out, and usage should drive interfaces, not the other way around.
2. Cloud services are many and varied – It’s incredibly hard to come up with a reasonably-complete standard programming API or management platform when each vendor’s offering is radically different. Standards must follow the 80/20 rule, but today’s cloud offerings are only about 20% similar.
3. (Real) cloud systems are open already – The whole point of the public cloud is to leverage existing open standards for access (IP/HTTP) and any worthwhile service already has a freely-usable REST-like API. Cloud services are engineered to be programmable and open, so the only lock-in is in how you use the cloud.

We can’t even agree on terminology at this point. Is data storage as a service DaaS (as SNIA says) or STaaS (as NetApp says)? How do you define public, private, and hybrid cloud? And what is cloud anyway? Cloud computing is not a war, it’s a fantastically exciting race to deliver value!

Open for Business

I’d like to return for a moment to that last point: The key element I’ve seen in most interesting cloudy products is programmability. Service providers publish API documents outlining the inputs, processing, and outputs for their systems and developers and end users create applications that leverage these. The best of these APIs use the concept of REST, delivering services through extremely simple and self-contained HTTP calls. This barely even rises to the level of software coding (and thus isn’t a true API) and is the hallmark of the cloud.

These systems are wide open: You can explore their interfaces, discovering new ways to use the them that were never intended. The same process accompanies all Internet systems, from RSS and Atom to Yahoo Finance. Just as one can rapidly migrate from Yahoo to Google by substituting a few URLs and parameters, so too can one move between cloud platforms.

Note that certain cloud systems lend themselves more to this kind of mobility. Once cannot move virtual machines from Amazon EC2 to Rackspace or Terremark because the underlying hypervisor technology is different. But even here companies like RightScale are stepping in to enable mobility.

When it comes to cloud storage services, the major players’ interfaces are open enough that migrating data in and out is simply a matter of performance: Read from this one, write to that one, and wait until the process is done. I am not a programmer and yet I was able to port an application from S3 to Nirvanix in just a few hours using only the respective API documentation. Interfaces like CloudLoop can also be leveraged to ease the movement of data.

Standards When?

Cloud services will eventually settle down and be standardized. I expect a workable cross-platform API for RESTful cloud storage within 24 months, for example. And one expects that the management of cloud compute instances will pass through a consistent and stable interface in that same timeframe. But these will develop as a natural part of the evolution of the systems themselves, not through some artificial “build it and they will come” standardization process.

There is nothing wrong with big companies sending their representatives to SNIA and DMTF meetings to talk about standardization. In fact, this is a great way to discuss ideas and begin to orient the industry. But the time for standards has not yet come, and users of cloud services have no need to wait for them. In fact, waiting for a standard will just prolong the maturation of cloud services, since real-world applications are the external pressure that forces evolutionary selection. Amazon would never have created their virtual private cloud (VPC) capability without customer input, and they will never perfect this capability if they rely only on pundits, bloggers, and product marketers.

Even when standards do appear, they will not eliminate per-solution APIs. Cloud service providers will continue to explore new concepts, and these will appear first in “proprietary” interfaces. Perhaps they will use entirely unique calls, or perhaps they will leverage reserved or unassigned sections of the standard, but innovation will continue. Witness the radical changes in HTML versions to date, the additions to CSS, and the wide world of browser plugins.

So we don’t need cloud standards yet. They will come, whether artificially pushed by committees or evolving through use, but only useful standards will survive. Isn’t that just how it should be?

Note: I am employed by Nirvanix, a cloud managed storage service provider, providing independent cloud strategy advice as Director of Consulting. Although this article was not created for my employer and is not intended to reflect their views, my perceptions are obviously colored by my daily work.

© sfoskett for Stephen Foskett, Pack Rat, 2009. | We Don’t Need Cloud Standards (Yet)
This post was categorized as Computer History, Enterprise storage, Gestalt IT, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.