AnyHosting

In this excellent article on remarkable customer service, Joel Spolsky lays out seven things he learned from doing customer service himself for his “bootstrapped” software company.

I’ve done tech support and customer service in the past, and a lot of these points resonate with me, but particularly #4 (”Take the blame”) and #6 (”Practice puppetry”). I think the title on #6 is pretty self-deprecating, and I wouldn’t put it just the way he does, although his description certainly brings vivid imagery to mind, and packs a more visceral punch.

I’d emphasize more that, when doing customer service, you are on the customer’s side, representing them to the rest of your company (and not the other way around).

“Practice puppetry” is about how to handle abusive or otherwise offensive customers, and not take it personally. This is absolutely key to running a worthwhile business, in my opinion. There’s nothing to be gained by winning an argument with your customer (that link is a poignant response to this post showing someone taking their customer’s frustration personally).

#7 (”Greed will get you nowhere”) really got me thinking. AnyHosting is purposely a very small operation, and we tend to be flexible about billing (e.g. if someone signed up for a year and decides to move, there’s no contract lock-in), but the idea of having an explicit no-questions-asked money-back guarantee sounds like a really great idea. We have a lot of policies about putting the customer’s needs first, that we need to be more explicit about.

(EDIT - removed “over the phone” from “customer service” )

One thing I didn’t cover in my post about secure web hosting is how to do virtual hosting when you’re running different instances of the web server (be they in a virtualized environment, a chroot, or just different users on the same host, or even a standalone server like Tomcat, JBoss, Weblogic, Ruby on Rails, etc.).

Note that you can’t host secure (SSL) sites via any kind of name-based virtual hosting, because SSL happens before HTTP.  However, you can do IP-based virtual hosting, meaning that you need an IP address for each secure site.

A simple approach is to set up Apache to proxy requests from your primary server to the actual client server. IBM Developerworks has an excellent article on this, complete with an image that underscores the compartmentalization aspect I was hitting on before:

In this illustration, the “backend servers” can be on separate hosts, virtual hosts, or the same host (as long as each web server instance uses a different HTTP port).

We’ve done both managed hosting as well as virtual hosting at AnyHosting, and there are many challenges to doing it securely. As Bruce Schneier is fond of saying, “Security is a process, not a product.“. All of the techniques described in this post aim to mitigate the amount of damage a successful attack can do, but this must be part of an overall security strategy, which is beyond the scope of this post (but I’ll say more about in the future).

There are many aspects to security; what I’m talking about today is compartmentalization -  that is, either physically or virtually separating customers from each other (into separate “compartments”), so that a break-in to one service does not result in a break in to all of them.

When you’re doing managed hosting of separate physical servers (or even virtual private servers), there’s generally a lot less to worry about - a malicious user getting access to one customer’s server does not generally lead to a break-in of all your customer’s servers, unless you’ve been lax with password or network security (e.g. not using encryption inside your network, using the same passwords everywhere, etc.).

However, virtual hosting presents much more of a challenge to secure properly, as the whole point is to use the same server instance for multiple sites. The primary problem is that most servers operating systems that use Apache (the most popular web server on the net right now) run all websites as the same user, which means that if you allow dynamic scripts to be run (CGI, PHP, etc.) then all users have read/write access to all files on that server.

The halfway point between VPS and virtual hosting is operating system-level virtualization. You’ve got different choices depending on OS: Solaris Containers, FreeBSD Jails, and Linux VServers  are all popular choices. These each give the customer a private filesystem and process list, as well as allowing the web host to limit resources like CPU, memory and I/O.

A solution of last resort is the Unix command “chroot“, which at least separates the filesystem from separate users, but does not allow the host to control resources and care must be taken to prevent users from breaking out. Tools like jailkit can be helpful, if you decide that you need to go this route.

The safest and easiest way to host separate sites is of course separate physical servers for each client; it’s also of course the most expensive. The cost/effort ratio continues in the same direction as you look at VPS, OS-level virtualization, chroot and finally no separation (this is only applicable if you either manage everything yourself and do not allow user uploads, or don’t allow dynamic scripting of any kind - however, you still run the risk of a break-in to one site affecting all of your customers).

(EDIT: fixed jailkit link)

I’ve been doing some research to prepare for writing a new article on hosting reliability in general. In particular I’ve been brushing up on geographical failover, as well as routing users to the server that’s going to be most responsive for them (these two problems have a lot of solutions in common).

I am really surprised that there seems to be a lot of general information out there on Global Server Load Balancing (aka GSLB), and not a whole lot about multihomed setup using BGP (aka Border Gateway Protocol; this really just means announcing the same IP from multiple places).

(more…)

Much is written about reliability for computing services, web services in particular. “Five nines” uptime became a popular catchphrase a few years back (referring to 99.999% uptime, which turns out to be about 5.2 minutes downtime per year).

Reliability is obviously a good thing; you want your website to be up whenever your customers might need it. However this often leads people to spend way more time, energy, and money focusing on building out a large infrastructure (and excess capacity to handle peak load) than is really necessary or useful, and can in fact have a negative effect on your reliability if you’re centralizing too much.

Assuming you have the same amount of resources (human, financial, etc.) to spend on a centralized location with a small number of large servers, or on several locations with a large number of small servers, I’d almost always go for the latter. Also, having redundant machines and a way to remotely restart and diagnose your equipment should be a given; it doesn’t matter where in the world your servers physically reside.

(more…)

Isabel Wang’s blog feed is now carried on planet.anyhosting.com. I’ve been enjoying following her posts for some time.

Isabel has a ton of industry experience and I am very pleased to carry her posts on Planet.

Entry-level web hosts like AnyHosting tend to have fairly simple price structures designed to fit within their upstream provider’s price structure. Typically, there is a buffer such that the virtual hosting customer or the provider can go over limit temporarily, although some fees may be incurred (especially in the case of bandwidth charges, usually measured at the 95th percentile to allow for this kind of thing).

Provisioning more storage space or bandwidth for a particular customer is generally a manual process, and makes the pricing structure more complicated, so many providers tend to avoid it if possible.

But what if you could access (virtually) unlimited storage on-the-fly, or boot up a few more (or a few hundred more) servers to handle an unusually high load?

Amazon has launched a few services (under their Amazon Web Services moniker) that do just this - Simple Storage Service (S3) and the Elastic Compute Cloud (EC2). Both seem to use fairly straightforward web service APIs (EC2 looks like it supports SOAP and also simple HTTP queries).

S3 gives you (virtually) unlimited online storage, and EC2 lets you create a Linux disk image and boot up a (virtually) unlimited number of virtual servers.

EC2 is still in beta, and I haven’t my own account to start playing with it yet, but I have checked out the storage piece (S3). You can read/write files using the web services APIs that Amazon provides, and also link users directly to the files.

It looks like you can tie this all together with Amazon’s Simple Queue Service (SQS), the idea being that you could put the computing jobs you need done into a queue, which would send messages to your EC2 virtual servers, which could then read and write into S3. There’s a good illustration in this tutorial on doing mass video conversion using AWS:

The cost of all of these services is all per unit used (storage, CPU, messages sent, etc) as well as data transfered. These are all currently in the range of 0.10 to 0.20 cents, so if you have a good idea of your projected usage (or have infrequent need of large amounts of resources) it could be a really good deal.

This has been out for a while, and there are a ton of reviews and opinions out there, so I am going to hold off on saying much more until I’ve had a chance to try it for myself. That said, I am very much looking forward to this kind of service taking hold; it has the potential to shake up the industry and bring the cost way down on the website lifecycle idea that I’ve written about before.

(EDIT - “seem use” -> “seem to use”)

I’ve just thrown the switch on planet.anyhosting.com, a planetplanet-style blog aggregator. This gives you one place to go (or pull a feed from) to see a variety of web-related blogs.

Please send an email to admin@anyhosting.com if you have a blog and would like to be considered for inclusion. You don’t have to do any special setup, just include a link to your blog’s RSS or Atom feed in the email.

Mike Shaver makes some excellent points in his blog post “the high cost of some free tools“, addressing the new crop of “Rich Internet Application” or RIA platforms: Microsoft’s Silverlight, Adobe’s Apollo (and Flash), Sun’s JavaFX etc. versus the “open web” where the platform  is not under the control of a single vendor, but a set of specifications and drafts to define the protocols, recommendations from different groups to define the data formats, and a ton of other RFCs.

We’ve got multiple implementations of the server (Apache, IIS) as well as the client (Firefox, IE, Safari). “The web” ends up (in theory) being the lowest common denominator that you can support with the total combination, although in practice people only care about the top 2 or so implementations.

The so-called RIA platforms like Silverlight et. al. generally try to do an end-run around the client, and typically (if Flash and Java applets are any predictor) use the web protocols like HTTP, but eschew the client-side data formats like HTML, Javascript and so forth, the goal being to capture the client and be the only choice.

Part of the strategy of these “RIA” platforms is surely to lock web hosts, content providers, web developers and users to a particular technology stack, and tools are a big part of keeping the producer side happy, and the point I most resonate with from Mike’s post is that human-readable code and the decentralized nature of the web makes  it possible for “mash-ups”, user-side scrips and styles and so forth (not to mention the humble link) make it possible to put things together in ways the original designer could not have envisioned, that is more useful for the end-user.

However, a point I haven’t seen addressed is this - a large amount of revenue on the web right now is advertising-generated. Arguably many users do not want ads, especially pop-ups or flashing images, or other annoyances. However, with such an open system there’s nothing stopping clients from effectively stripping most ads from content, or showing the user the Javascript code behind your nifty new AJAX application. Pop-up blocking is already a feature in all major  browsers, and more complete ad-blocking software for each is just a Google search away.

That’s one thing these RIAs can offer that an open web cannot; they can embed DRM to make sure that your code cannot be viewed and that ads must be viewed. I am sure that some content providers will surely welcome this. This could also be done in a web browser, and I am frankly surprised that this angle hasn’t been tried yet.

But if you restrict the client this much, is it still the web? I agree with Mike’s assertion that distributed evolution and incrementalism is what made the web great, what made it win. Acting as a true collaborative medium, not passive like radio and television, but really interactive and respectful of the user’s choices is what makes the web great today.

(EDIT - fixed IE link)

AnyHosting has been in operation for over 8 years now, and we’ve accumulated quite a bit of knowledge (and a lot of opinions) on growing a website while staying within budget.

Following up on my comparison of different hosting technologies,  I’ve created the first post in our AnyHosting Articles section, the Website Lifecycle.

As it states on the main articles page, one of our key principles is to deliver useful, factual information, and not to only push our services, and especially not to push our services where we think someone else is doing better. The decentralized nature of the internet is one of its’ greatest assets, and we certainly use a large number of providers rather than trying to be a one-stop shop.

The number of choices can be pretty daunting, so especially for companies in the early part of the lifecycle, it’s valuable to have a company like AnyHosting to choose and plug together the pieces for you. As your site grows and you get more comfortable with evaluating and plugging together the parts yourself, we tend to move to an advisory/consulting role, and point you at services that we know and trust.