June 23, 2011 |
Microsoft FAST versus Google Search Appliance 6.8
I was recently asked to compare Microsoft Search (FAST / SharePoint Search) to Google's Search Appliance Version 6.8. Both companies have solid search technology, but they are approaching the market very differently. This is reflected in their products making each better suited for specific types of search deployments.
Google shook up the Enterprise Search market back in 2002. The intent was to provide the market with a search solution that was easy to install and maintain. Surveys had revealed that generally speaking, users were not very happy with Enterprise Search. Google saw this as an opportunity to introduce a simpler search product. With the wind of Google's strong brand at its back, the message resonated and Google quickly gained market share. By 2006 they had gotten close to entering the visionary Quad of Gartner's Magic Quadrant for Information Access.
An important point to be made here is that if you look closely at the quadrant, Microsoft is nowhere to be found. Microsoft's search technology was not taken seriously at that time. In fairness to Gartner, Microsoft had not focused on search up until that point. Google's success did not go unnoticed by Microsoft. In 2006, they announced that Search was strategic to them and within three short years had taken a leadership position in Gartner's quad. If anyone doubted Microsoft's commitment to search in was dispelled in 2008 when they acquired best-in-class search provider - FAST Search and Transfer for $1.2 Billion.
So fast forward another three years to present day. Since the FAST acquisition, Microsoft has spent the bulk of its effort integrating FAST with SharePoint. Google has focused on increasing the scalability of the appliance and adding new features. So how do they stack up? As I did in the comparison between Microsoft and Autonomy last month, I think it's very important to recognize that there are two types of search deployments, and you should compare products through the lens of your organization specific needs. Are you deploying search as infrastructure, as a specific application, or both?
A search application is a search deployment designed to solve (or significantly improve) a specific business process. This typically includes business processes that are search intensive, such as customer service, or e-Commerce. The primary characteristic of a search application platform is flexibility. Search applications connect and surface data from several Line of Business Systems. The data in these disparate repositories are then presented to the user through a flexible, dashboard like interface.
Infrastructure search is a search solution deployed across an entire organization with the goal of improving productivity for as many information workers as possible. A search platform suited for infrastructure search will provide out of the box features that have broad appeal across departments. Additionally, infrastructure search platforms should be relatively easy to deploy and maintain, and provide integration with the organizations more commonly used business systems.
Search Applications
In my view, for organizations deploying search applications the choice between Microsoft and Google is relatively straightforward. By their nature, search applications often require heavy customizations to a search platform in order to achieve the desired functionality. By design, the extensibility of the Google Appliance is limited in order to reduce potential deployment and administration challenges. As an example, the Appliance is not designed to connect and surface information in Line of Business systems which is a key requirement of any Search Application. The Google Appliance has several limitations that hamper its ability here including:
- Connectors must run a separate Java Application server. Each connector requires a separate Java instance.
- The connection between the Java Application server and Google's Appliance is not secure. This could present serious security implications.
- The connectors do not provide index level security so are innately less scalable.
In contrast, Microsoft has provided a connector framework called Business Connectivity Services (BCS) which enable companies or Microsoft ISV partners to build robust connectors into all major ERP, CRM, ECM, Messaging, or custom applications: - Connectors install directly on the crawl servers.
- The connectors are highly scalable. BA insight's Exchange Connector for Private Email can index 200 email per second, for example.
- The connectors provide index level security and optional real time security.
For more information about the BA Insight's connectors, please click here: http://www.bainsight.com/sharepoint-fast-search-connectors/Pages/default.aspx
A second component of a successful Search Application is the need for a flexible interface. Search Applications often look more like dashboards than standard search interfaces. Microsoft clearly has the edge here. Google's interface is customizable, but provides less flexibility than Microsoft's web part framework. At BA Insight, we've taken full advantage of this. This 2:00 minute video shows just how far you can take it. http://www.bainsight.com/resources-for-sharepoint-fast-search/Pages/exchange-connector.aspx
Infrastructure Search
Organizations seeking an infrastructure search platform (When looking at Google) must carefully consider the impact of their organizations size on the project. Larger organizations seeking an infrastructure search platform will find that Microsoft provides a higher ROI and lower TCO relative to Google based implementations. This finding is based on several factors, but Google’s pricing model is the major contributing factor. Google’s pricing is based on the number of documents indexed. Typically the number of documents in an organization doubles every 18 months. As the volume of data grows, Google customers are forced to upgrade to more robust versions of the appliance. Another pricing factor is that Google leases the appliance. Customers must renew the lease every two years. This pricing model can in some instances make the price of Google’s offering higher than any of its peers. In contrast, smaller organizations would benefit from the ease with which the Google Appliance can be deployed and maintained while lower document counts would make the pricing more reasonable.
And again, Google inability to provide Index level security is a significant shortcoming which reduces the scalability of the product.
Obviously, as a Microsoft partner, my post will seem self-serving. I do want to point out that I have first-hand experience with Search Appliances. When BA Insight first released our product back in 2004, it was packaged as an Appliance. We learned the hard way that packaging Longitude as an appliance was appealing to smaller organizations, but seriously constrained the products scalability and flexibility in terms of features.
The Longitude Appliance 2004:
 To get more information, download this Google and Microsoft Enterprise Search Product Comparison document.
|