fastmail infrastructure

[gmh]

there is a similar thread:
http://www.emaildiscussions.com/...hlight=servers

I was wondering about fastmail's reliability. The thread talked about the steps taken at the app level and the server hosting facility.

Is fastmail hosted on redudant servers? I'd like to start using the service, but I don't want to switch my mail to something fly-by-night. How long have you guys been around? How many people use the service? When are you looking to commercialize the service?

[princessmaeve]

I can't give you the full techie answer, but as a user and frequent reader of the board, I can answer at least a few...

I don't know anything about the servers, but I know that there is almost no downtime with fastmail.fm, and they are extremely dedicated to keeping the servers up and active.

Fastmail has been in existence for 2-3 years now, though they only opened it to the public a few months ago. Before that was extensive beta testing.

No idea how many people use the service, but AFAIK it's not a huge number, but very adequate.

They are planning to always offer a limited free service, and in a few months will introduce paid accounts, with added benefits and other fun stuff. Here's the link for that plan:

https://www.fastmail.fm/docs/about.html

Most frequent questions are answered in their FAQ, which is posted as a link off of www.fastmail.fm

Hope that helps!

[obwan]

Not speaking for fastmail.fm, but some of the info you're looking for is right here http://www.rackspace.com/infrastruct...rk_details.php

[Jeremy Howard]

Thanks for your help with answering so well, Princess and Obwan.

In the end what matters is how reliable we actually are, not how we achieve it. But if you're interested, I'll give a quick summary...

We aim for the best possible price/performance combination. That means that we stay away from expensive proprietary solutions like EMC storage and hardware load-balancing, and do lots of our own network infrastructure design using custom programming. We have enough real-world experience to know to stay away from complexity, and keep things really simple--this means that there's less to go wrong. We also avoid single points-of-failure.

We don't use redundant servers, because we find them expensive and complex. They obviously at least double the price of everything, and add the complexity of data replication, 'heart-beat checking', a 2nd set of hardware to maintain, and so forth. I've worked a lot in environments with redundant servers before, and in every case they resulted in more flakiness than if they had kept things simple.

But we have redundant components in our server. All IMAP data is on RAID mirrored disks--which means that if one fails the other kicks in. Our host uses triply-redundant power, and 5 separate network providers--our SLA with them specifies a max of 24 seconds of downtime per month. Our name services provider uses infrastructure in 5 geographically isolated locations with a large mixture of software and hardware to avoid a single point-of-failure (see http://www.zoneedit.com for details). Our mail delivery is handled by 2 servers, one in Europe (smtp.eu.fastmail.fm) and one in the US (smtp.us.fastmail.fm). It makes perfect sense for SMTP, proxy, and DNS to be on redundant servers, because they need to share minimal data and do not need heart-beat/failover systems, and they are based on well established protocols and systems.

Our infrastructure is highly scalable--as we get more users, we simply add more servers, with an extremely simple proxy front-end that passes requests to the server that looks after that particular user. This works really reliably, because if one server goes down, only the users on that server are effected. And if the front-end proxy goes down, another server can take over its job because it needs no unique data (each server stores the list of which users are connected with which server).

We're looking to commercialize the service in mid-Feb.

As to whether FastMail.FM is 'fly-by-night', I guess that depends on your definition. It's a project funded, built, and run by committed programmers. The people who answer your mail are the people you write the system are the people who own the business. We think that means that our chance of still being here in a year is pretty high, because there's no VC or corporate parent to pull the plug.

Also, we're not completely naive about corporate stuff either, so we're not about to die because of cash-flow problems or stupid business decisions. For instance, Rob has worked as a management consultant with AT Kearney, one of the world's leading strategy firms, and I have consulted with McKinsey & Company, worked as a manager with AT Kearney, and we also have two other non-exec directors with a great deal of business experience. We've spent 3 years before we've considered accepting money from anyone, and now have the operational data to know exactly what price points are required to sustain the business.

Finally, the software that runs the web interface was written entirely from the ground up in-house. That means we know every single aspect of it, and the role of every single line of every single file. You'd have to do a lot of searching to find another business that can say the same thing--everyone else I know in this business has customised one of the existing open source solutions around, or outsource to another provider (who themselves use customised open source solutions), or use software originally written by programmers who have long since moved elsewhere.

[gmh]

thanks for the quick and detailed answer. you probably get a lot of these questions, being relatively new.

i look forward to using your service. the existing features are great. the upcoming feature list looks great also.

[Sherry]

Hi alipensen,

Things have improved a lot since way back then. You might be interested in the following 3 links.

Article on FM's Beginning
FastMail reinvents a slicker, quicker wheel

Reliability

Features

Welcome to the EMD Forums

Sherry

[hadaso]

Originally Posted by Jeremy Howard

... We don't use redundant servers, because we find them expensive and complex. They obviously at least double the price of everything, and add the complexity of data replication, ...

This has changed. FastMail now has replicated infrastructure (and has spent a whole year on making it work, proving Jeremy knew what he was talking about when he said it was complex).

[William9]

That 2002 post is interesting. Redundant servers are "expensive and complex". Fastmail was my business email service provider (and my account was on the infamous server 4 when it failed) during the several day outage a few years ago. Boy, was that an eye opener. My messages are important to me and my clients. After that experience I wanted "expensive" -- because I also wanted business and professional class reliability and uptime. That need led to my finding another primary provider. I'm glad that FM made decisions to improve its reliability. Still, after the several day outage experience, I was left with a lingering apprehension that my email service may let me down again.

[hadaso]

I think that both long outages that FM had in the (now quite distant) past were not preventable by using "expensive and complex" hardware based redundancy. The long one that lasted several days happened despite of hardware based redundancy (hardware could withstand simultaneous failure of two disks, but three disks failed simultaneously, and recovery was long because of a combination of "lose no data" policy and hardware configuration that made recovery with no loss of data a long process).

As I understand it the replication we now have in FM is not what Jeremy's post from 2002 refers to. That kind of redundancy would have just duplicated the file system corruption that caused that outage.

Anyway, back then FM was 3 years old. Now it's 10 years old and several years of developer time has gone into building more reliability into their system by now.

[robmueller]

Like any service... things change over time! Costs change, income changes, requires change, priorities change, etc.

This is a reasonable description of where things are at these days.

http://www.fastmail.fm/pages/fastmai...liability.html

Rob

[David]

Originally Posted by robmueller

This is a reasonable description of where things are at these days.

http://www.fastmail.fm/pages/fastmai...liability.html

I am impressed, as that is one of the Fastmail doc's that I have not read. I do know though (based on past experience) that what I hear from the Fastmail development team is the truth.

[robmueller]

Originally Posted by David

I am impressed, as that is one of the Fastmail doc's that I have not read. I do know though (based on past experience) that what I hear from the Fastmail development team is the truth.

Really? What particular things. I don't think any FastMail representative has lied here or any any statement we've made.

Anyway, none of the things on that page are particularly magically. They're all straight forward and common sense things to do, and if you looked around, you'd see we've talked about all of them in the past at various points (eg what servers we're using, what RAID controllers, IMAP server replication, etc), that page really just brings together the things we've done scattered over years of work.

Rob

[Sherry]

Originally Posted by robmueller

Really? What particular things. I don't think any FastMail representative has lied here or any any statement we've made.

Hmm, I read that the opposite than what you may have? Or maybe it's just me and I need some sleep. So guess I'll do that now.

Sherry

[fhapgood]

Originally Posted by Sherry

Hmm, I read that the opposite than what you may have? Or maybe it's just me and I need some sleep.

No, your reading is right.

[David]

Perhaps it was an unexpected response. Fastmail have always been straight up (and honest) with their customers - is the point I wanted to make