Spatially Adjusted

Tag: weogeo

  • Cloud Agnostic

    Last week Apple announced it was moving some of its iCloud storage to Google’s cloud from Amazon. Earlier this month Dropbox moved from AWS to their own cloud hardware. The motives for both these moves are to get off of someone else’s cloud and and on to their own1. But it does bring up a good point for all hosted development, try and be as cloud agnostic as possible because you never know what you might have to do.

    Early on in WeoGeo’s life, we had a product called WeoCEO. You won’t find too much about it but it was WeoGeo’s way of managing S3, EC2 instances and balancing traffic. WeoGeo created this because Amazon’s EC2 tools weren’t robust enough to handle a business yet and WeoGeo didn’t know how AWS might turn out. The point of WeoCEO was it could be staged in any CentOS environment and handle the WeoGeo database, geoprocessing and websites. In theory that would have allowed WeoGeo to easily move off of AWS and on to Azure, Google or Rackspace. WeoGeo abandoned WeoCEO and started using AWS’s native tools because it made it easier to work with new technology such as Cloudfront, new storage solutions and database options. While there was zero chance WeoGeo would move off of AWS, having such a tool could have made it easier for the WeoGeo platform to be integrated into other technology.

    All this got me thinking about my current hosting GIS systems. I’ve got some on AWS and some on Azure. Could I move from one provider to the other and how much work would it be? Most of my stack isn’t proprietary to one or the other system2. Node.js, PostgreSQL and other open technology runs really well on just about any hosted system out there. But there is somewhat proprietary cloud technology out there you can lock yourself into.

    I don’t think that everyone needs to develop their own WeoCEO type management system3 but making pragmatic choices with how to deploy cloud applications can pay itself back in spades. I have clients who want their applications on AWS or Azure and I can’t deploy the same application there with little effort, but keeping it that way requires planning and a will to be cloud agnostic. I’ve always liked the term and I’ve always tried to prototype and develop applications that aren’t locked into to infrastructure. I’d love to keep it that way and you should too.

    1. In Dropbox’s case, they have already done so ↩

    2. Even my Azure stuff is all PostGIS and Node.js ↩

    3. Clearly even we didn’t stick with it ↩

  • ArcGIS Server Revisited

    Legacy GIS System

    We were talking this weekend about how much serving up GIS data has changed in the past 3 years.  GIS Server used to be so important to many of my friends companies to the point they spent tens of thousands of dollars on it a year.  But no longer, each one said that they stopped paying for server because they all use other options.  Now before I go on, I want to say this isn’t about sales data of Esri products.  It’s more about changes in how people are sharing spatial data.  Feel free to replace ArcGIS Server with your favorite GIS server package (Title is a bit of SEO, right?  Heck I’m not even talking about ArcGIS Server in this post).

    I gave a talk years ago about something we did at the GNOCDC mapping recovery from Hurricane Katrina.  You can see the slide deck here and watch the video here.  Basically it was the seeds of what we are going through right now.  It wasn’t that what we were doing back there was very unique, it was just a realization that GIS can’t be hosting “enterprise” data in a “workgroup” environment.  Just like Katrina basically broke the GNOCDC GIS servers, it has become clear that there is almost no way for an organization to use classic GIS servers without putting a lot of load balancing and networking decisions in front of them.

    For most companies this is just way too much infrastructure and licensing costs.  We’ve seen the rise of CartoDB, Mapbox and ArcGIS Online (or whatever it is called these days).  Each has pluses and minuses and while there is overlap, they all do things unique to themselves.  But what the big attraction for each is that you don’t have to manage the constellation yourself.

    The biggest drawback each said was the unknown in licensing.  Most hosted GIS plans are costed in ways that GIS people aren’t familiar with.  Mapviews?  Nobody has analytics on that until you put it in these services.  100,000 map views sounds huge doesn’t it?  But how do you really know?  Service credits?  We’ve wondered what that even means for years.  But I’d wager beers that even with the unknown, you’ll still save money over your ArcGIS Server license or other maintenance you pay for hosting your own GIS server.

    We’re at a crossroads here.  People have begun to start realizing standing up ArcGIS Server, Geoserver or other map servers makes little to no sense in the new marketplace.  Paying for hosting maps is cheaper in the long run, has more availability and is easier to use that classic self hosted mapping solutions.  ArcGIS Online for all it’s confusion is beginning to be leveraged by users and everyone I knew at the Esri UC knows what CartoDB and Mapbox do.  Back in the old days of WeoGeo, we had to prove what we know now every day.  The cost of “doing it yourself” is magnitudes higher than paying for hosting.

    Tide is changing…