AnyHosting

I have not found much on this subject since my last post, so instead of continuing to wait for someone else to do it I have started working on a new open-source web hosting control panel (alternative to Plesk, cPanel, etc).

All the work is in my local repo, but I will be pushing to github as milestones are hit.

I want to get the basics right, and not worry right now about competing feature-for-feature with the big guys:

• basic file management
• configure apache, stop/start server
• allow (and enthusiastically support!) plugins. I am using django/python, should be no problem.

That’s for the user-facing side, the backend takes care of scaling across multiple hosts (on-demand scaling), billing, activating/deactivating accounts, you get the idea.

What do you want to see in a free, open-source web hosting control panel? Leave a comment or feel free to email me – rhelmer@anyhosting.com – Thanks!

I’ve been trying out the cloud computing service Google App Engine for a simple dynamic site. I’ll publish more details on this as it gets further along.

I have heard and read a lot about App Engine, so I knew roughly what to expect, but I am still impressed with it. It is a very simple model, it’s basically CGI with a 10-second limit. Only the Python programming language is supported right now (although they plan to add more), and the Django web framework is pre-installed. There is a nice little SDK for running the environment locally, which I just noticed is open-source as well (Apache license).

The really incredible thing about this is that it runs on and takes advantage of Google’s massive server infrastructure. In-memory or persistent storage is super fast and easy to use, and no need to worry about redundancy of individual servers (this is probably why they use the CGI+shared storage model, way simpler to distribute applications on-demand).

Today the roadmap was updated to include a few very cool features coming later this year:

• Support for running scheduled tasks
• Task queues for performing background processing
• Ability to receive and process incoming email
• Support for sending and receiving XMPP (Jabber) messages

This environment being so easy to use and the cost being low due, which is likely because the price of hosting so marginal to Google (I imagine that they are effectively outsourcing spare capacity) plus these new features pretty much replace the need for a traditional shared or dedicated server.

They haven’t yet started charging for the service, but proposed pricing is available, and they plan to start charging this year. The price is quite low considering the feature set, is pay-per-use, and is comparable with the popular cloud computing service Amazon Web Services (AWS).

The difference between this and something like AWS is that while it is much easier to get from start to finish on Google App Engine, one must (likely) re-write your application in Python, using Google’s libraries. You’ve got less flexibility than a shared PHP host, for example; you can’t easily take your code elsewhere. AWS is on the other end of the spectrum, more like dedicated servers where you can install anything you want: Linux or Windows, PHP or .Net, etc.

In any case I highly recommend checking out Google App Engine, especially if you’re doing any new development. If you’re looking to move your existing servers to the cloud, then I think Amazon Web Services still has the edge here.

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.

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.