In the fall of 2010, the Douglas County, NE GIS Department (DCGIS) managed numerous servers in multiple locations throughout the county. The internal IT group did not yet offer a virtualized environment (i.e. multiple, configurable, disposable servers sharing physical resources with other servers), so DCGIS faced the purchase and setup of new server hardware. At the same time, Esri began to push the potential of running its GIS server software in the Amazon cloud. After reading up on Amazon Web Services (AWS) and how to deploy Esri’s software in the cloud, DCGIS officials made the decision to give Amazon a try.
We began by creating an Amazon account and registering a credit card for charges (it now offers a monthly invoicing option). We launched a new server instance using a pre-configured Esri AMI (Amazon machine image). This AMI included the ArcGIS Server and ArcGIS Desktop software pre-installed and configured. Amazon’s virtual server service is called EC2 (Elastic Compute Cloud). Once we launched and connected to our new virtual server, we registered the ArcGIS software with our developer license and we were up and running. Our first task was to copy an HTML file to the Web server and connect to it from the Web. That worked well and the Web page seemed fast. We then transferred some GIS data to the cloud server after installing Dropbox. We published some map services and consumed them with our desktop software and using ArcGIS Online. This worked well. Our next testing goal was to port one of our smaller FLEX applications to the new Web server and reconfigure it to consume map services running on that instance. This test also went off without a hitch.
Based on this early testing success, we wanted to expand our efforts to include a separate database server instance and install a third-party application, Cityworks, onto the Web server. Cityworks Server AWS is a GIS-centric, browser-based work and asset management system. These initiatives took us into 2011. By late winter 2011, we had two Amazon server instances running – a Web server and a geodatabase server. We also had Cityworks operational and running on top of ArcGIS Server in an Amazon cloud instance. We began moving some of our production applications and map services out to the cloud. In spring 2011, we deployed our Pictometry Online software to an Amazon EC2 cloud instance running MySQL. By summer 2011, we had 75% of our enterprise GIS operations running on Amazon cloud servers.
The Amazon Elastic Compute Cloud (EC2) dashboard
Today, we continue to create and modify geospatial data locally. We replicate these data to our cloud servers and run (almost) all of our Web services and applications in the cloud. Even though we believe the AWS platform is an affordable alternative to hosting your own servers, we are always seeking ways to drive down our costs. Recently, we have been tinkering with Amazon’s S3 storage platform for storing data and hosting Javascript Web applications. This platform offers reduced rates for data storage and provides increased performance. We are also utilizing scripting to automatically stop and restart non-critical servers that host “business hours” applications for additional cost savings.
From a GIS administrator’s perspective, our number one benefit derived from using the cloud has been flexibility. The flexibility to deploy a new server instance or an image of an existing server and only pay for the time we use it is extremely valuable. We are better prepared to test new versions of software and custom applications. From an organizational point of view, the biggest benefits have been reliability and the reduced dependency on internal IT resources. The costs are predictable and Amazon provides many options for driving those costs down.
Along the way, we have learned a lot of tips and tricks. The process included some hard lessons and plenty of stops–and-restarts. Successfully moving to the cloud includes careful planning, lots of testing, and resilience. We encountered numerous roadblocks, some large and some small. For example, hosting a production database in the cloud means desktop software users within your network need a way to connect. We tried solving this with database connections (ODBC), but found performance lagged. We then tried connecting via Web services but still didn’t get the performance we needed. Wherever we couldn’t convert a desktop user to a Web-based alternative, we eventually set up “micro” server instances on Amazon’s cloud where our user could login remotely and connect to the cloud database – kind of a cloud-based virtual desktop. This solution has proven to be very reliable.
Another consideration is Internet bandwidth. Like many organizations, we have remote sites where users don’t have the Internet performance we do at the main office. This should be considered ahead of time. Can you upgrade the bandwidth? Can you move the staff? Is remote connectivity an option? We have also spent a considerable amount of time on spatial data replication. Reliable data synchronization is critical to a cloud-based GIS solution. The DCGIS staff documents these speed bumps and all of the other tips and tricks learned along the way. Not surprisingly, our advice for success is detailed planning, thorough testing and a willingness to embrace change.
For the Douglas County GIS Department, running our GIS in the cloud has enabled us to become more flexible, reliable and scalable. Our performance has increased and our costs are roughly the same as they were when we purchased hardware ourselves. As we continue to expand our service and data solutions, the cloud is enabling us to work more efficiently and effectively.