Mass Events Labs is an event production company that, for the most part, runs unconferences (like Mashup Camp and Startup Camp) and one of the important aspects of unconferences is how the attendees get to update a central Web site with event content as that content "happens." The typical flow involves attendees determining before and during event time what the event's agenda will be, recording those agenda items on the event's Web site, and then, for each session/discussion, basically taking down the minutes of what was discussed. To get a sense of that flow, you can look at the Web site we run for Startup Camp.
First, there's the empty agenda, which is little more than a grid showing the available rooms and time slots. Then, in advance of the event, the attendees start to add ideas for topics to a proposed discussions page as they are now doing for Startup Camp 2 (coming up on May 7 in San Francisco). During a general assembly that's held on the morning of the first day of our unconference, attendees take turn at the microphone discussing their proposed topics and the grid is finalized. Here's what that grid looked like after the general assembly was held for the first Startup Camp. And finally, here's an example of the minutes that were recorded in real-time onto the Startup Camp Web site by someone who was present in the discussion.There are three aspects of having Google do it for you that make the solution interesting.
As you can imagine, a bunch of IT decisions had to go into having this technology in place for the events. For example, wiki software is what makes it possible for multiple users to read and write to Web pages through their Web browsers. But which wiki software? And what operating system? And on what sorts of hardware? And how much do you invest in that hardware (or hosting service) to account for potential failures? And what do those choices cost? To acquire? To set up? To run over the long term.
As owners of a small company and as people with a limited amount of time to be worrying about things like hard drives failing, my partner and I agreed that even though it involved a premium, we'd go the managed hosting route. This is where physical systems that belong to someone else (the hosting outfit) are dedicated to you, but they're managed by the hosting company. If a hard drive fails on you, that's the hosting outfits' problem to get it fixed right away. Likewise, Internet connections to our servers are something I never have to worry about. In going with a managed hosting service, we were also afforded two choices for our e-mail domain (in other words, if the domain is masseventslabs.com, what e-mail server software ends up servicing in and outbound e-mails).
One choice was to run our own e-mail server software (I'm saying software so as not confuse it with some piece of hardware dedicated to e-mail) on one of the servers we're paying for under our managed hosting contract. The other choice from our managed hosting provider was to use their email servers instead -- a service that comes for free with a managed hosting contract. It seems like a no-brainer, right? On one hand, I could run my own e-mail serving software on my own servers (taking up processor and storage resources) which will also net me the additional headaches associated with e-mail server administration. On the other hand, at no additional cost to me, I can take advantage of the e-mail service provided to me by the managed hoster. It didn't take more than about 2 seconds to decide: one second to think about it, the other to say "yes."
Using an outside service is not completely without its headaches. I of course had to walk users through how to configure their e-mail clients and make suggestions for things like leaving e-mail on the server or deleting it (and when). At one point, my personal inbox simply stopped working with no logical explanation. As it turns out,
But that was the least of my worries. What was more problematic to us was spam. Not inbound spam, but rather outbound spam that was emanating from one of our managed hosting provider's other customers. As it turns out, when we elected to use our hosting provider's e-mail system over running our own, we also elected to use a physical system that was shared by our fellow customers who made the same decision. As it also turns out, one or more of those customers were engaging in e-mail practices that were found to be abusive by someone. Unfortunately, one result of sharing an e-mail system with someone else over whose e-mail practices you have no control is that that e-mail system could very well end up on one or more of the public Realtime (spam) Black Lists (RBLs) that are out on the Internet and monitored by other e-mail systems. The net result of that is that those e-mail systems -- the ones monitoring the public RBLs -- will automatically start blocking e-mail from any system that's blacklisted with no concern for whether there are other legitimate users on that system whose e-mail will also get blocked.Days may go by without knowing that anything is going catastrophically wrong with your e-mail.
For my company, this started to cause some major headaches. We'd get phone calls from people saying "How come you're not replying to our e-mails?" when we actually had replied to those e-mails. One problem with RBLs is that e-mail senders aren't always notified if something has gone wrong. I could send an e-mail to some person and the e-mail server that picks that e-mail up may check the source IP address of the e-mail, find a match on a public RBL, and then, without doing anything else, simply dump that mail into some black hole (get it?: black hole, black list) from which it or anything remotely close to a status report will never emerge.
In terms of running a business, days may go by without knowing that anything is going catastrophically wrong with your e-mail and then, once you find out (if you find out), there's almost no way to tell which of the e-mails you've sent over the last few days made it, and which ones did not. To make matters worse, the fix isn't immediate. There's no way to take matters into your own hands. You must go to the hosting service provider who in turn must convince whoever runs the various RBLs that a certain IP address should be removed. It's a process I personally went through at least a dozen times before I said "enough!"
Equally frustrated, our hosting provider started investigating the idea of putting us on a different e-mail server, one that wasn't shared with so many customers. But, by that point, I felt like it was time to try something else, something more drastic.
Last year, Google launched the beta version of an e-mail hosting service where the same back-end infrastructure being used for its public facing Gmail service could also be used to replace a company's e-mail server altogether. So, instead of running our own e-mail server software on our hosted server (which was starting to look like our only option since no one shares that IP address) or using the hosting service's shared e-mail serving infrastructure, all in- and out-bound e-mails would instead go through Gmail while preserving the "@masseventslabs.com" part of their address.
E-Mail hosting like this isn't a new idea. There are plenty of other service providers doing it. But there are three aspects of having Google do it for you that make the Google solution interesting. First, it's free. While that could and might change, right now, a small company like Mass Events Labs can get up to 25 users onto a Gmail-powered masseventslabs.com e-mail domain, and each gets up to 2 GB of storage at no charge. Second, I currently have a regular old Gmail account and one of the things I've noticed about Gmail is that I've never seen it go down.That's not to say it hasn't. Recently, Kevin Maney over at USA Today confirmed with Google that customers of the service were experiencing problems. But, looking back on the hosted version we were used to using, there were times when my POP3 email client (Thunderbird) couldn't connect to the server. Since we made the switch to Google, this has never happened.
Third, the spam issue. I'm not sure what it is, but I have a sneaky suspicion that the people who run RBL lists may have to think long and hard before blacklisting Google's email hosting service.Right now, the service is free. Is there some point at which the service won't be free?
So, I switched. The process of switching wasn't as smooth as I would have liked, but the switch is over. And since switching, we haven't had one problem. What were some of the switching issues? Before you can successfully cut over to Google's service, you have to do two things. First, you have to prove to Google that you actually control the root domain. This was simple. Google gives you a unique code and then it tells you to put that code onto a Web page that's served from that domain. Presumably, if you own the domain, then you're the only person who can do this. Google then looks for that Web page to authenticate that the person making the request is indeed someone who is authorized to make that request (for example, I have no access to the Web servers of other companies and therefore could not successfully ask Google to spark up an email domain for them).
The second and more complex step is to modify the Internet's DNS so that when something goes hunting for your email server, it knows exactly where to find it (even if it's Google). For us, this meant deleting any existing "MX" records (a special DNS record for routing to email servers) and adding a whopping seven others that are specific to Google (Google supplies you with all the gory details). This step didn't go as well as I had hoped. For starters, Google offers a detailed walkthrough on how to do this if your domain registrar is one of the more popular ones like GoDaddy. Although my registrar wasn't listed, I had an idea of how to delete and add MX records but for some reason it wasn't working. Fortunately, the folks at my registrar responded to my call for technical support by asking me to e-mail Google's instructions directly to them and then they'd take care of it, which they did.
What I didn't know (not being a DNS rocket scientist) is that changing the DNS entries for the Internet itself wasn't good enough. Even after fixing the DNS through our registrar, inbound e-mail was strangely still coming in through the old server. As it turns out, when something is seeking out an MX record, it goes to the Domain Name Server where ever the root of your domain is hosted. In our case, that was the managed hoster where our servers are. There, the DNS servers are locked down. Nothing can modify a customer's DNS entries but a request from the customers themselves. So, even though I fixed the public DNS, those changes were not propogating to the DNS at our managed hoster. Email that was looking for the masseventslabs.com domain would look in our managed hoster's DNS and see that our MX record was still pointing to the manage hoster's shared e-mail system. One e-mail to the managed hoster was all it took to make the MX record swap there as well.
Now, things are working fine. I'd show you a screen shot, but since we use POP3 clients like Thunderbird and Outlook, there isn't much to show. For all intents and purposes, Google is simply an email router. If we want, we can access the service through the Gmail interface, but we have a login address that's not just special to Mass Events Labs, I was even able to load our logo into it to personalize it to our company.
Once I was all done making the switch, I did have some questions for Google. Here they are and here's how Google answered:
When does Google anticipate the service coming out of beta? We're focused on building a great product for end users and for entire organizations. We have nothing more specific to announce about Google Apps at this time.
Is the 2GB limit per user in the domain, or for the enitre domain? With Google Apps Standard Edition and Education Edition, organizations receive 2GB email storage, for each user within the domain. With Google Apps Premier Edition [$50 per user per account] organizations receive 10GB email storage for each user within the domain.
Right now, the service is free. Is there some point at which the service won't be free? For example, I see there's a way to request the user limit of 25 be raised. Is that the point at which a fee is or will be incurred? Or, when the service comes out of beta, will current users get a notice that says they must start paying? Google Apps Standard and Education Editions are free services. Google Apps Premier Edition costs $50 per user per year. The Standard and Premier Editions of Google Apps deliver the same fundamental services for end-users -- hosted email, calendaring, start page, etc -- with all the same features. However, we've developed the Premium Edition for organizations that would like additional back-end functionality or support because of their particular technology environments or requirements.
[To avoid an RBL problem negatively impacting users of shared email systems] what is Google doing on the spam front? Google employs a variety of techniques to ensure that Google users do not abuse the system and to ensure that Google users are protected by abuse. If we detect abuse, we employ several means to stop it, including suspension of the account if needed.
It should be noted that, in the Web-based administrative panel that Google provides to people like me that handle a company's email domain, Google politely (it's not too overt) tries to upsell its users to a Premier Edition of Google Apps which includes the other applications such as scheduling, word processing, and spreadsheet (all browser-based of course). Since we're not using any of those (yet), suffice to say that we're happy to stick with free 2GB per user email service for now. So far, it's working way better than our previous arrangement. And, quite honestly, our hosting provider is probably happy to not be getting any nasty grams from me any more (even though we pay for that right).
One other point: I don't think that this is an idea that's just for small businesses. One of the more frustrating problems for e-mail users at larger companies is how their e-mail administrators have set inbox storage limits in the 100-500MB range. It doesn't take many multimedia files and/or Powerpoint presentations to eat through that. In seems really strange that, for no cost at all, Google is somehow able to supply users with 2GB of storage while corporations limit their users to a fraction of that. If you're an e-mail administrator in one of those companies, imagine how your users would feel knowing they had a 2GB limit. Granted, security (having all that e-mail outside the firewall) may be a concern and I have no idea what happens if certain compliance regulations enter the picture when a public service like Google's is getting used. But for some slice of the business world out there, Google's hosted email service may be the same ticket for them that it has so far been for us.