The “World is Flat” Google Infrastructure

It’s easy for a user of free GMail or of Google Apps Standard or Premier Edition to take for granted the massive and highly sophisticated infrastructure behind what’s on their screen.  In fact, most people don’t really have any reason to think about what’s behind their user experience, any more than they care about what’s generating the electrical power that runs lights and appliances inside their house — as Nicholas Carr points out in his book, The Big Switch.

The people who are evaluating Google Apps for their organization are the ones who do care about what’s under the hood.  Google’s infrastructure, of course originally designed for search, is very different from the way in which traditional IT environments are structured. While the term “cloud” is an excellent metaphor for utility computing that’s served up from somewhere out in the ether, Google’s infrastructure is very much terrestrial, and it covers a lot of ground globally.

As a basis of comparison, let’s look at the environment that many Google Apps customers have come from — Exchange Server. With Exchange Server, each user within an organization typically connects directly to a single physical or virtual box from their Outlook client. There’s usually drive redundancy, such as RAID-10, built into that server (or group of servers) and then the server is in turn, backed up.  There’s nothing inherently wrong with this environment (as long as a proper disaster recovery plan is in place), and Exchange Server is an extremely robust application.  However, one perspective on this structure is that all users are connected up to a mother ship — a form of parent/child relationship.

In many ways, Google Apps is on the complete other end of the spectrum.  Users are wired into a very large, global infrastructure and data are widely distributed through Google’s Bigtable database and accompanying file system.  When a user sends an email, the write is to a number of different drives that are located in different physical locations — often on different continents.

What does this architecture translate into for practical purposes?

Google Apps Uptime

This architecture allows Google to guarantee 99.9% uptime for Google Apps Premier Edition.  As we all know, for email, users’ downtime tolerance thresholds are very low.  Email downtime can be very costly depending upon when it happens.

Application Cost

All Google Apps customers are on one, very large instance of Google’s application.  This makes for significant economies of scale in terms of sharing physical resources.  In addition, Google has designed their data centers around cheap, commodity hardware and free software — which makes their incremental expansion costs relatively inexpensive.  This allows Google charge only $50 per user per year for Google Apps Premier Edition — and presumably their financial people have run the numbers on this price point.

Google Apps Upgrades

The single, multi-tenant instance also means that upgrades are frequent and transparent, compared to event-based upgrades in a legacy environment.  Customers don’t have to pay anything extra for upgrades – they just happen in background.  Innovation occurs very quickly and newly released innovations are usable immediately.

Collaboration

Google Sites, which is part of Google Apps, can take the place of a wiki.  For example a Google Site can be used to collaborate on a project or on a set of best practices.  Google continues to enhance the more traditional document, spreadsheet and presentation categories — these are also highly collaborative in nature.

Third Party Innovation

Google Apps’s fledgling marketplace offers a variety of business productivity add-ons, some of which leverage the recently released GMail Contextual Gadget capabilities.  Google Apps customers can get incremental business value with just a few clicks.

Google’s unique, flat, global architecture represents a significant shift in thinking for many IT professionals and corporate decision makers.  Each day, thousands of organizations are embracing this new approach to corporate email and collaboration — and it’s still relatively early in the game.

In Cloud We Trust – The Tiers of Cloud Vendors

There’s no doubt about it, cloud computing is gaining some serious momentum.  Part of this momentum is due to the fact that the trust issues that were commonplace several years ago among buyers have been reduced to mere pockets of concern.  But, who are the most trustworthy application vendors in terms of customer data being safe and secure — and the application being available — should disaster strike one physical location?

Let’s look at the general tiers of trustworthiness.

Google – Big Table, Big Infrastructure

Google represents the top tier of cloud vendors.  Google’s infrastructure is massive, highly redundant and is designed for hardware failure and other types of failure.  If you use GMail, either as a consumer or as a business user, you may or may not know that Google will not complete a transaction, such as an email send, unless it’s confirmed that your data has been written to at least two places — often two different physical locations, even on different continents.  In addition, each of those two writes is backed up.

It’s also worth noting that Google Apps is one, gigantic, global application instance.  This is the ultimate in multi-tenancy, in which every customer is on the same instance.

This YouTube video provides an excellent deep dive into Google’s infrastructure.  I’ll term Google as having real-time, multi-location redundancy.

Salesforce.com – The Trust Infrastructure

Salesforce.com takes customer data incredibly seriously.  There are entire teams in place to make sure that customer data is secure, redundant and highly available for production use.  Salesforce has three, global data centers with a fourth one coming on line.  If one data center was completely taken out, customer data from that center would be available via one of the other data centers in very short order.

Details on Salesforce.com’s data security can be found here.  The same site tells us that Salesforce.com is running their entire customer base (of over 77,000 companies) on just eleven production instances.

I’ll call this near real-time, multi-location redundancy.

If you know of any other vendors with a similar architecture, please post details in a comment.  I suspect that Microsoft falls into this category for part of their infrastructure.

Disaster Recovery Mode Cloud Vendors

The next tier of vendors — and likely the largest tier — are those that have only one main data center location, but have a plan in place should disaster strike this location.

This tier of cloud vendor does not have either live servers or dedicated, standby servers in a secondary location.  Instead, they have access to a pool of server capacity in a secondary location that’s available to them should they need it.  Data are copied over to the secondary location in near real-time, or on a periodic (daily) basis.

If disaster was to strike the main data center, there could be a time lag of up to a day (or more, if things don’t go well) before the backup environment is available for application use and/or before DNS changes have propagated.

“All Eggs in One Basket” Cloud Vendors

There is a class of cloud vendors that is fully reliant on a single data center being available.  Customer data is mirrored and/or backed up within the data center, but there’s no specific plan should disaster strike the data center location.  These vendors are normally early stage companies that are still in beta test mode.  The economics at this stage of a company’s often doesn’t support having a failover data center.

“Dedicated Server In the Cloud” Vendors

Vendors that host each customer on their own dedicated physical or virtual server within a cloud infrastructure such as Amazon EC2 need to work within a different set of rules in terms of uptime and redundancy.  Unlike the multi-tenant vendors, for which moving a single database from location A to location B means moving thousands of customers from location A to location B, with the dedicated server approach, each customer is on their own, separate application and database instance.  This means a more individualized approach to uptime and redundancy.

If you have any concerns around your company’s data and its availability, it may be worth asking your vendor into which general category they fit.

Merging Duplicate Accounts & Contacts in Salesforce

Merging duplicate records in Salesforce is easy once you know the navigation. This video takes you through quick overview on how to merge Accounts and Contacts in Salesforce CRM.

It’s important to note that the “winning” record in a merge retains related information, such as Activity History, from both records.

Watch this video in 1280×720 resolution

Making the Move to Google Apps Premier

An increasing number of our clients have been making the transition to Google Apps Premier Edition for their email and other collaboration needs.  After recently weighing the pros and cons of upgrading our current email server, we decided to make the move to Google Apps as well.

Evaluating the Alternatives

Upgrading our email server would have been costly in terms of IT consulting hours and we would have still been responsible for keeping the server lights blinking at the colo where we keep our production and development servers.  Plus, our email uptime would still have been dependent on a single machine’s uptime as well as on the reliability of a colo’s power and Internet connectivity.

After looking at the $50 per user annual cost of Google Apps Premier Edition and about twice the per user, annual cost for hosted BlackBerry Enterprise Server (BES), we decided that this was more than a fair price for a scenario in which we could worry about one less spam appliance and two fewer [virtual] servers.

After a review of some of the “Geeking Out” videos on Google’s YouTube channel, Google’s distributed architecture started to look better and better.  The fact every Google write is to multiple drives — and even to multiple physical locations — convinced us that our all important email flow would be based on a significantly superior infrastructure than anything we could develop and support internally.

Migration to Google Apps Premier

Google provides both client side and server side migration tools, so importing email, calendar and contacts from standard apps is relatively straightforward.  However, if you need to import contacts from a non-standard source, you’ll find that the contact import is devoid of a mapping tool, and a “custom import” can be time consuming.  Also, if users want to maintain a multi-level folder structure in their email client, the emails associated with those folders need to be store on a user’s local drive. Google does not have a hierarchical folder structure, as their search engine effectively eliminates the need for this.

For BES, one option would have been to connect to a BES server that we still maintained.  Even though we already owned BES user licenses, we decide to go to BES in the cloud as well — and we signed up with ExchangeMyMail.  Their process of connecting to Google Apps is straightforward and their support was excellent.

Deployment Planning

As with any technology migration, proper planning is necessary.  Google provides a comprehensive Webcast video that gives an overview of deployment best practices, including how to run your legacy system in parallel with Google apps using split delivery.

With proper planning, the cutover can be extremely fast, even for larger organizations.  In fact, Google goes as far as to recommend a “big bang” deployment — which really means a rapid cutover rather than an overnight one.

Finally, Google stresses it’s important to get your users bought in to the process.  This includes building user enthusiasm for the process and providing users the proper level of support throughout the process.

Salesforce Web-to-Lead For Your Facebook Pages

You may want to have your Facebook Page visitors submit their contact information directly from your Facebook Page(s), versus having to first navigate to your Web site.  With Facebook Markup Language (FBML), allowing for this is relatively straightforward.  Your Salesforce.com Web-to-Lead form can be added within a tab and/or added as a Wall Box.

Adding a Web-to-Lead Form to a Facebook Tab

1. If you are a Page admin, go to the Facebook Static FBML Application page

2. Click Add to My Page and then select the appropriate Page from the box that pops up

3. Go back to the Page you just selected and click on Edit Page in the top left.  You will now see FBML listed under Applications

4. Click Edit under the FBML Application.  Give the box a name such as “Contact Us” and paste in your Salesforce Web-to-Lead HTML

5. You will want to align the field labels and text boxes with CSS or with table tags.  Also, you can add a hidden field so that Lead Source is populated with “Facebook”

6. Save your changes and then go back to your Page Wall

7. From your Page Wall, click on the + sign to the right of the tabs and drag your new “Contact Us” tab up to the main tab area

Here’s our tab. If you want to create an entire mini-site within a Facebook Page tab, check out WEBphysiology’s offerings.

Adding Salesforce.com Web-to-Lead in a Wall Box

If you’d like to add your Web-to-Lead form as a Wall Box in addition to (or instead of) having it within a tab, you can simply add another FBML Application under Edit Page | Applications.  If you edit the existing FBML Application, you’ll see a link in the bottom left that reads, “Add another FBML box”.

In this new FBML Application, format your Web-to-Lead HTML for the more narrow Wall sidebar, by placing the field labels on top of the fields.  Under the Application Settings for this FBML Application, remove “Tab” and then add “Box”.  Back on your Page Wall, click on the Boxes tab, click the edit pencil at the top right of the form and select “Move to Wall tab”.  This will put the Box in your Page’s left sidebar (below the “Friends Like This” and “People Like This” boxes):

To add form validation, you can create and host a PHP validation script.  In the simplest form, this would send the user to a validation error page with a link back to Facebook.  When there is no error the form would be posted to Salesforce.

A more elegant approach would be to use Ajax on the Facebook Page so that when an error occurs it just updates the FBML on the contact form to notify the user immediately and not bounce them around.  Also, on a successful submit, the PHP would still do the post to SalesForce but then also put the user back to the Facebook form Page with a success message.

Added Video:

Watch the video in 1280×720 resolution