SpatialTau v1.4 – Backend Irrelevance

SpatialTau is my weekly newsletter that goes out every Wednesday. The archive shows up in my blog a month after the newsletter is published. If you’d like to subscribe, please do so here.


What We See

Do you care about the Google Maps backend?  I mean do you really think about how their server stack is run or managed?  Of course not, Google has successfully abstracted out the server part of Google Maps to the point we just assume it will always be available and running.  But it isn’t just Google, Esri and their ArcGIS Online (or whatever they call it) just runs.  Sure it has its idiosyncrasies that make us all angry and frustrated but as with Google we just assume it will always be available and running.  Back when I worked at WeoGeo, SLAs were very important to how we did business.  Our SLA and our data provider’s SLA were so important to how we did business.  Most people I talked to who wanted to build upon our platform were interested in what our SLA was.  I know Google and Esri have SLAs available but I rarely see people curious about what they are and build contracts around them.  They are assume it will always be there and always be available.

To the Nines

High availability is something that is always talked about with these services.  How many “nines” is your device available?  That was a point of pride.  Of course if you built upon Amazon or another provider, you could only offer as good as their SLA is.  One picked providers that have “high nines” in availability so that you could pass on that SLA to your own customers.  Heck, it was why you outsourced the hosting, even 3 nines is an incredible uptime level.  What about Esri’s SLA?  Well, I found this PDF dated from last year:

Esri will use commercially reasonable efforts to make the Covered Services available with a Quarterly Uptime Percentage of ninety-nine point nine percent (99.9%) (“Service Commitment”).

That’s “three nines” which is just about 9 hours downtime a year which is noot bad for most GIS applications.  But I wonder how many of us looked at it.  OK, what about Google Maps for Work SLA (Google renames this product way too much)?

Google will use reasonable commercial efforts to provide Maps API web and mobile interfaces that are operating and available to Customers 99.9% of the time in any calendar month.

Gee, pretty much exactly the same as Esri.  Now I have no idea what Esri’s or Google’s true availability has been over the course of the year.  I haven’t heard anyone complain about ArcGIS Online lately nor have I ever heard someone complain about Google Maps for Work.  One has to assume they are both running at least 99.9% availability.

Should We Care?

I think the answer is absolutely.  As we move more and more into hosting our services, we need to be more and more aware of what we are getting ourselves into.  I’d wager that 8-9 hours on average downtime a year is fine with most applications.  But that needs to be take into consideration when migrating your legacy self hosted GIS applications into “cloud-like” environments.  I know as a contractor, I’m always keeping my clients aware of what it means to be hosted in Google, Microsoft or Amazon’s cloud including the SLAs.  Eventually Google, Microsoft, Amazon, Rackspace, etc will have a downtime that will affect your applications.  Death, Taxes and a server crashing going down are the only guarantees in life.  We need to plan for this inevitability and have plans to alert our users/clients to this possibility.  Sticking your head in the sand and ignoring the problem is not going to help.  Being proactive and having a plan will.  Take a look at your hosted services, the SLA for each and what you can do to mitigate the failure or one or more.  You’ll be glad you did!