Cutting infrastructure costs using Google Apps

Messaging infrastructure is the core component of almost all IT systems at various companies. E-mail communications are today so prevalent that often users and managers consider it as common sense that e-mail is always and everywhere available to them.

Due to legacy software or often incomplete or even, one could say, close-minded way of thinking about email many companies are stuck with inferior e-mail solutions be it open source or proprietary. Most importantly, those solutions in most cases cost a lot and they often have hidden costs that you take for granted but when you add them up you can come up to a number that can blow your head off.

E-mail infrastructure - the old way

Gone are the days of having 5 MB mailboxes at your ISP. Ok, you can probably still find those in offering but for various reasons almost nobody is using them anymore. First, for business purposes having @aol.com or similar domain is considered unprofessional. Second, only explanation for using such mailboxes is either utmost ignorance or, what's much worse, incompetence. Harsh truth is that Internet Service Providers suck at providing mail. Not because they lack the skills but because they simply don't want to mess with that. Even though at first glance one could consider e-mail as being part of the ISP's core business, when you think about it you soon come to conclusion that in fact it is not. When you think about it and try to decide reasons to categorize e-mail as an asset or as a liability for an ISP on one hand you've got a marketing material that has a line that says "Free e-mail account with 10MB mailbox". On the other hand, as a liability, they need to create and maintain infrastructure, create backups, maintain customer support and, as the most problematic, fight spam and maintain security. This costs a lot of money. When you consider on-premise e-mail infrastructure in most cases you can safely compare it to some poor and lonely patient who always requires some mending throughout his lifetime but never quite gets what he really needs and deserves. When I see some customer's e-mail infrastructure it's almost always built around:
  1. old servers
  2. old software
  3. unpatched software
Scary but equally important is that often there are no proper backup and restore policies.

E-mail as a commodity

Unfortunately, when you come with the above story to the managers they'll probably just throw you out of the office, in a more or less polite way of course. Why? Shouldn't one be worried about his core IT system? Well, they should but then again that poor old mail server runs for years now and will probably continue to do so happily so why worry? As good old Murphy's Law teaches us if something can go wrong it will do so. Things brake, computers too. Catastrophe is inevitable one day be it an evil hacker, flood or simple disk failure. Slowly, we come to the point where e-mail infrastructure is your inevitable pain. Someone feels it, many don't, but it costs the company a lot of money. Lets write down some costs of maintaining your own e-mail infrastructure:
  • Power costs
  • Environmental costs (server space, cooling, location security, etc.)
  • System engineers that maintain servers/software
  • Lost user productivity on managing spam
  • Lost systems engineers productivity on managing spam/security
  • Licenses
And these are just off the top of my head, I'm sure you can come up with a lot more but we've got plenty to prove the point. Not so long ago you were pretty much stuck with your own servers. Fortunately, recent years have brought us hardware commodity. Future inevitably brings us closer to the omnipresence of computing resources. There will come a day when you'll just point a finger and say "I need 150 CPUs plugged-in here!". Cloud computing is just that. What for example Amazon EC2 and RackSpace Cloud offer you is just that: "I need 10 servers here!" and in a matter of minutes you've got what you need. Having you're own servers just became more expensive (not always). This brings us to the point of this article. E-mail infrastructure is a commodity today. Once Google launched Google Apps corporate e-mail landscape felt an earthquake. You can start with the free plan, move on to the 50$ per user and really pay for only what you use. I did a rough calculation for my own company and we would get ROI in 2 years when considering ONLY power savings of not running that good old IBM server 24/7. When you add up everything else you can probably get ROI in a matter of months.

Is Google Apps good enough?

Answer of course depends on your needs. But as far as we stick to e-mail, calendar and sync with mobile devices I'm pretty much sure over 90% of users can be totally satisfied with available features. Perhaps the better question is if Microsoft Exchange or any open source/proprietary equivalent is worth the trouble? In my opinion in most cases it is not. Why should I worry about off-site replication? Why should I worry about power failures killing mail server? Why should my company pay at least three times more money for e-mail? Why should I worry about updating servers/software? The point that every company should consider is that in the end everything comes down to money and going Google Apps way can save a lot of money either through software licenses, hardware costs or overall productivity.

When not to use hosted e-mail

Last point is of course that proposed solution is not for everyone. There are legal or regulatory compliance rules that forbid such implementation at some types of companies (for instance banks). If you run a top secret business of course you want to keep all your stuff in-house. But in overall corporate space such requirements are actually a minority. While some might have privacy or security concerns what everyone must ask themselves is "Do I really think that my network is more secure than Google's? Are my data centers more secure than Google's and is my disaster recovery plan really better than Google's?"

You can leave a response, or trackback from your own site.


Leave a Reply