AnyHosting

Not sure how I missed 3tera before, they look like an interesting entrant to the “utility computing” market, which everyone is excited about again since Amazon’s got into it.

I haven’t really done my due diligence on this company yet, but I checked out the slick demo  (bonus points that it shows their app running in Firefox, takes the worry of cross-browser compatbility off the table) and have been reading back issues of the blog, and it sounds like a pretty solid offering.

If you don’t have time to watch the demo, in a nutshell it looks like you can architect your own virtual datacenter using their browser-based drag’n'drop schematic editor, including things like load balancers, and they automatically instantiate everything for you.

The Dynamic Appliance idea sounds pretty cool, as the idea of being able to seamlessly tap into more supply when demand runs high (and not pay for supply when demand runs low) seems to be the whole point of the utility computing thing.

I worry a little about what happens to my servers if this company goes away, or if they’re bought and put into maintenance mode, etc. but this is a pretty normal worry for any company. I think open-sourcing more of their stuff would assuage this a bit since I wouldn’t necessarily have to reconfigure everything to move to a competitor, but I can certainly understand their business reasons for not doing this.

However, like I said I haven’t looked at them in-depth yet, so take these worries with a grain of salt. Hosting providers of all flavors are susceptible to this kind of thing, as they often have their own home-grown or customized administration software, so it’s generally a pain to move between different providers.

I think that to be a true commodity, switching between providers has to be no-brainer as it is for services like telephone and electricity: you get the same dial-tone and same voltage, just at a different pricing model. I think this issue will be forced if the utility computing idea really catches fire this time.

I’m thinking about doing series of how-to style articles on more technical subjects, here are some thoughts on a starting point: how to install and use Ubuntu Server, with AnyHosting as a case study.

AnyHosting currently uses Ubuntu Server (LTS) on a Rimuhosting.com virtual host. Ubuntu is very easy to install and use as a desktop, but if you haven’t done administration purely from the command line then Server can be a bit daunting. There are excellent starter guides and forums on the Ubuntu website.

Services

The following external services are provided (description followed by Ubuntu package name) :

• web server – apache2
• SMTP(+SSL) email server – postfix
• IMAP/POP(+SSL) email server – courier
• FTP – proftpd

Additionally, there are some internal services running, which are not visible from the internet (blocked by the “iptables” firewall):

• Database – mysql
• Monitoring/auto-recovery service – monit
• Automatic installation of security updates – cron-apt
• Log monitoring and reporting – logwatch logcheck
• Append-only network backups – rsync

Security

All unused ports are blocked. Any connection attempts are logged and reported. FTP and email services authenticate against the database, so clients do not need system or shell accounts.

For shared hosting, Apache is configured to proxy to chrooted installs which users have access to (as discussed previously). This is not as secure as having a real separate VM or better yet a separate machine for each web hosting client, but therein lies the dilemma of low-cost shared hosting versus moderate-to-high priced dedicated hosting.

The primary goal is to protect legitimate users from eachother; protecting the system from unauthorized intrusion (and detecting such intrustion) probably deserves it’s own series of articles, however the last few services listed in the “Services” section above should give some clues.

UPDATE link to secure shared hosting on ubuntu server part 1

If you run your own web, email, or other services, you need to be notified if these services are not up and running. There are tons of great choices available; which is right for you depends on your needs (how many operating systems do you support, what is your tolerance for complex configuration, how large of a system are we talking, etc). Two that I’ve used and can recommend are Nagios and Monit.

I’ve used Nagios in mixed Unix/Linux/Windows/MacOSX environments, and although it’s fairly time consuming to configure, it’s definitely very powerful. The workhorse of a Nagios system are plugins, which are simple Unix commands (they just return an exit code and optionally an informational message to tell Nagios whether the service is OK, in a warning state, or critical).

There are tons of Nagios plugins already written, which can check disk space, load average, monitor a specific TCP port, etc. Custom plugins can be written in any programming language that you like.

Nagios has a bunch of features like escalation (e.g. paging an on-call person if the service is down after an initial email), attempting to restart services, a web interface to schedule planned downtime and acknowledge outages, etc.

Nagios is great, but as I said it takes a little while to come up to speed on configuration, and if you only have one host it might be a bit more than you need. A much simpler system that I’ve been using on standalone hosts lately is Monit, which primarily exists to attempt auto-recovery and alert when service outages happen.

For example, if you want to try restarting your MySQL server before being paged, that’s really simple to specify in monitrc (the Monit config file):

check process mysql with pidfile /var/run/mysqld/mysqld.pid
  start program = "/etc/init.d/mysql start"
  stop program  = "/etc/init.d/mysql stop"
  if failed port 3306 then restart
  if 2 restarts within 3 cycles then timeout

You can also use Monit to restart or stop an application if it uses too much CPU, spawns too many children (as Apache does for each incoming connection), starts taking too much memory, etc. which can help to mitigate bugs and deal with denial of service attacks.

Monit isn’t a client/server system like Nagios, but this does not necessarily preclude you from configuring it centrally if you use a good deployment system (that’s a subject for a future blog post, though).

I’ve put up an article on Web Hosting Basics – the bare necessities of running your own site.

However this doesn’t really tell the whole story, so I’m going to start working on first blogging and then writing followup articles on the major themes, in no particular order:

• purchasing a domain
• choosing a hosting provider
• promoting your business

If hosting yourself:

• running a web server
• running an email (SMTP, POP, IMAP) server
• backups
• monitoring

I’ve just put up a new article in AnyHosting’s article section – “Reliable, scalable, and growable web services“.

This touches on a few of my previous posts,  just trying to distill it down for anyone out there searching for some basic information.

There have been decades-long arguments over which is better, the thin client or fat client approach the network computing. Many maintain that the Web is just another turn of the wheel back to the bad old days of computer terminals which are useless without a connection to the Big Computer in the Back; what good is a web browser without Google to search, or Flickr to see your photos?

Some of the real wins you get with a browser is that you can make it share the workload, through rendering and client-side scripting; the upcoming Firefox 3 supporting offline mode for applications, and the Google Gears plugin that does this right now for IE and Firefox are also great steps in the right direction.

The big misunderstanding here about both client-side scripting and offline mode are that it’s not about being on the plane and wanting to browse your photo collection (that’s just a side-effect), it’s about:

• seamlessness – if what the user is doing does not require the network, they shouldn’t be interrupted if their local network, the remote server, or anywhere in between is having problems
• responsiveness – local storage is generally faster than network; it’s also necessary to be local for interactivity and any kind of scripted animation (think gaming).
• privacy – some data you don’t want going across the network, period.

This is why I don’t really understand questions like “does offline mode still matter“  (or more harshly-worded criticisms of the idea) when you take the above into account. It’s about taking the best of the thin client world and the fat client world, and making applications that are always there for the person using them, and always responsive and fast, regardless of connection/network/server status.

The next big push has got to be blurring the line between web application and installed application, as well as the difference between online and offline. Using online office apps or webmail nowadays gives you an equivalent experience to running application, so what’s with the browser controls?

I’d like to be able to take my web applications out of the browser and manage them locally, and I’m not alone. Making apps more desktop-like seems to be the right way to get there.

One key to managing a small business that you do not spend full-time on is to spend the little time you have automating the processes that you know you will need, such as:

• billing
• account management (create/remove/update/delete)
• monitoring
• backups

It can be tough to know when you should do a particular task (say, moving records from one billing system to another) by hand, or take the time to automate it. My advice would be to do something by hand the first few times, and if you expect to have to do it again you’ll have the hands-on knowledge you’ll need to automate.

When I have a persistent task that I’ve had to do a few times, I first look for a system to suit my needs, before trying to write it on my own. Since I’ve done a bit of programming in the past, my priority is usually:

1. find an external service that can do this for me
2. find a suitable, well-supported, open-source application
3. create a custom application, using as many open-source modules as possible

#1 is a fairly new addition there, for me I prefer not to used closed-source software with my own business, because it means I can directly modify (or hire someone to directly modify) the processes that run my business. I’m less concerned with software and processes that other businesses use, as long as I can easily integrate and replace their services as necessary.

Google Apps is one example of #1 for email/calendaring services. On #2, for instance managing server rollout, I’d look to things like kickstart and cfengine (or maybe puppet) to keep my servers in sync and up to date.

Account creation and possibly billing can be an example of #3, depending on how your business works, exactly how you configure customer’s accounts, etc. For billing, some find that a spreadsheet or other “offline” software is enough; personally I need a system that reminds me.

The most important things, to me, when writing custom software are:

1. don’t do it if you don’t have to
2. do the simplest thing that could possibly work

Both of these will save a lot of time, energy and money down the road, both your own and in contractor fees.

A simple, custom system is easier for someone to get started with, understand, fix and modify than a complicated, custom system; a system that other people actually know and use will ideally save you more time still, and make people who already understand the implementation easier to find.

After finishing my post on customer focus, I found this blog entry by fellow planateer Isabel Wang. I wish I had found it before I wrote my previous post, as it’s a very insightful piece and I would’ve hit more on the customer focus versus “traditional customer service” aspect. Here’s an excerpt:

Which is why I don’t buy it when folks in web hosting say that they’re not worried about Amazon or Microsoft or Google – because they have “better customer service”. It’s also why I disagree with this Texan’s view that in order to build a better hosting company, you’ve got to make sure your employees understand the importance of customer service.

In my mind, there are two types of “customer service”. It’s great if you pick up the phone before the second ring, answer how-to questions with super human patience and respond to billing disputes with courtesy and generosity. But sooner rather than later, the need for this kind of generic support will be eliminated through innovation and automation.

On the other hand, there will be increasing demand for Rackspace’s kind of support, for helping the Slideshares and YouTubes of the world (aka the successors to today’s shared hosting resellers) plan and manage and scale their infrastructure. In fact, support might be the wrong word for their kind of requirement. Expert advice would be a better way to describe it. In depth knowledge from someone who understands your technology infrastructure – AND your business – at least as well as you do.

I totally agree, except that I think there is a further distinction – your customers (no matter who they are) should never need to contact your company for support, in the general. It’s not a user experience anyone wants, in almost all circumstances.

But no matter how redundant and automated and innovative your setup is, there are always bugs (or perceived bugs), network outages, and the like. Having appropriate communications channels with your customer is absolutely key, and one of those channels should always be a real human being (and they should have a “real” job as well, because they should almost never get calls ).

Hooking customers up with a knowledgeable person who has the authority to solve their problem is expensive, and should be treated as such. Their experience should be quick and easy if they are contacting you directly, because they have already run into something that is not working as they expect, and they are already frustrated.

In the end, it’s really all about the user experience. Everything should work seamlessly and easily as much as possible, and the last resort should  be getting a human to manually intervene for you. Customers really don’t want to be *forced* to interact with you (nothing personal!), so put effort into making it so they don’t have to.

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).