• Skip to primary navigation
  • Skip to main content

Michael Cizmar

Founder of an award winning consultancy

  • Open Source Projects
  • About Michael
  • Show Search
Hide Search

Spring

3 Reasons to Start Your Google Search Appliance Replacement Project – Today

michaelcizmar · Feb 21, 2018 · Leave a Comment

Every year, while I know winter comes, I am always somewhat taken back by its inevitable arrival.  So too is true of the Google Search Appliance (GSA) wind down.  The enviable wind down has begun, winter has arrived.

Given more than two years to find an alternative solution, the time to moved to a new platform is now.  Waiting until your GSA license later this year puts you at risk for the following:

1 – Unknown Unknowns

Even the simplest project can have unknown issues come up.  Some of these can be as simple as when the Change Management Board meets.  These can stretch out your project and delay your eventual cut over.

Additionally, there typically is more planning required to implement a replacement technology.  What could be done on the GSA can take factors time more.  Relevancy typically doesn’t not work as well out of the box but will after some simply tuning is completed.  Not having experience with the platform means you should consider that into your schedule.

We’ve experienced unexpected at all stages of the process and it’s fairly typical.  Remember, the Google Search Appliance is going to shut down.  Many customers still do not realize that.

2 – Other Priorities

Two years ago, not many people had changing their search technology on their 2018 plans.  Given this, there are other priorities and projects that will drain resourcing and focus.  The sooner you can re-platform the less risk you have to the level your resources and focus on the priorities.

3 – Lack of Resources

There are thousands of re-platformings happening this year.  Give this fact and the general lack of available resources means that you’ll be competing for experienced talent.  The longer you wait to begin, the smaller the pool of available resources.

As a general rule, I say that it shouldn’t take you longer to procure the technology than to implement it.  If it takes you weeks to purchase the software, then you should expect weeks to implement it.

Everything that Google should have asked me about Cloud Search (Springboard) but did not

michaelcizmar · Jan 8, 2017 · Leave a Comment

Based on Google’s announcement, Springboard should be entering general availability (Although most likely still in “beta”).  Not having being asked what should be in the product, I’ve put together my own short wish list.  Obviously this is a much much larger topic then can be described in a short blog post.  Nonetheless, here are a couple of thoughts:

1 – What should we use for our connector framework?

You should migrate from the existing Plexi Framework for a Microservices based architecture based on Spring or pure Google Cloud Platform.  Spring runs everywhere both on prem and in the cloud.  Microservices allow for a more pluggable / dependency injection model for traversal and processing of data to the cached store and the native Cloud Platform is excellent and processing larges amounts of data.

Some reasons to not use the current Plexi framework is that it does not use dependency injection and therefore requires complicated re-architecture / recoding for changes.  Further, crawling is slow and requires many http connections. Indexing things in batch and streams is much more efficient.  The connectors should sync data to a temporal storage system and use something like Cloud DataFlow for stream and event based processing.

2 – Where should that temporal storage system be then?

Google Cloud Storage should be the primary data source for external content ingestion.  The api is documented and performs very well under large data loads.  Connectors sync data to a variety of buckets.  As the system is updated or potentially requires reindexing, change event notifications can be wired to auto update (link).  The storage is encrypted at rest and provides low latency access from other GCP regions.

3 – How should we process the data

Data stored in Google Cloud Storage and be synced into the Springboard index via Cloud Pub / Sub and Cloud Data Flow.  Standard processing templates can be provided and users should be allowed to upload their own pipelines which leverage other Machine Learning APIs both in GCP and other areas.

4 – How should we display the result set?

I have a core belief that search should not be an “opt-in” experience.  What I mean by this is that you should not have to goto “springboard.google.com” but rather you want to take into the applications that you want to expose it contextually.  Search is simply a service that can be extended through whatever framework you like.

5 – What other things should we think about?

Don’t make search opt in

Forcing everyone into navigating to a search experience is dated.  The Google search algorithm and machine learning needs too extended into everyone’s application.  By participating the indexing and the event stream you have the ability to provide true Google Now type of events/cards that are useful.  
Springboard needs to provide its basic interface for an out of the box experience but its value truly is amplified if it can be extended into all enterprise applications.  This requires simply that Spring listen to an event stream, process that data and provide APIs that allow notifications to brought throughout the G Suite, Chrome Alerts and etc.

Integration with Other Google APIs

We are in an API economy and Google’s got the brand name around big data processing.  Integrating with the cognitive API suite is both competitive advantage and end user demand.  Google Machine Learning, Natural Language, Speach to text and image recognition APIs are just a couple of examples where integration into the larger services suite which could be leveraged.

Integration with Google Cloud

Currently Springboard seems to be integrated deeply within G Suite.  This potentially limits its use case in the way that Hangouts and Google Docs does.  Everything is tied to a G Suite user account and the G Suite underlying infrastructure.  Google Cloud on the other hand already has exposed  services and infrastructure which widen the use cases for which Springboard can be leveraged.

Copyright © 2019 · Monochrome Pro on Genesis Framework · WordPress · Log in