Just in time for the 2010 ESRI User Conference, our team has been doing some investigation and testing of several apps running against ArcGIS Server 10 in the Amazon cloud.  What follows is a summary of our experience building and deploying a couple of apps against ESRI’s cloud-based solution.

Background and Business Case

In several presentations, blog posts, and articles of the recent past, Dave and I have detailed some of the Flex API work we have been doing for the USDA Forest Service Forest Health Technology Enterprise Team (FHTET). Historically, the FHTET team has collected and analyzed data describing the effects of major forest pests on the landscape. To this point in time, information has been disseminated by means of an annual pest report in hard copy format. While GIS and hard copy maps play a role in the preparation of this report, as a static report it does not fully leverage the data exploration and analysis tools available within today’s geoweb applications.

The current software development initiative is utilizing ArcGIS Server 10 and the Flex API to create a series of Rich Internet Applications (RIAs) facilitating the distribution of forest health related information to a variety of audiences. In addition, the FHTET team has elected to use this initiative as a test bed to determine the ease and speed with which custom applications can be deployed to the Amazon Web Services (AWS) cloud with ArcGIS 10 for greater scalability and convenience.

Given the richness of the FHTET data and the desire for novel UX elements in the applications, the FHTET organization has elected to pursue a fully custom web implementation based upon ESRI ArcGIS Server 10 and the Flex API with a considerable number of custom widgets and extensions of the DynamicMapServiceLayer. We have based our implementation on our considerable background and experience customizing the ESRI’s Flex Starter Kit to produce a template that now serves as the starting point for many Flex-based applications leveraging ArcGIS Server 10.

The Forest Pest Conditions Viewer

A FHTET Forest Pest Conditions Viewer public application (http://fhtet.dtsagile.com/fhtet/Flex/FPC#), shown below) was first developed to assist public users in exploring the impacts of a number of forest pests for different forest service regions. The number and identities of the pests to be displayed within the Flex application are configurable by each forest service region so that users can see the “top N” pests for a given region based on the decisions and experience of forest health professionals.

Since the application is designed primarily as a data exploration tool, required interaction from the user is minimal. Once a region, state, or county is selected, the application makes a service call to get updated data as JSON and render the results for the user. Region and county selection can be done via the map or via pick lists in the search pane located at page left. In addition to the prominent bar charts rendered across the bottom of the map showing affected acreage and number of counties for each pest, data summaries and links to external information are also provided in the dockable left pane. Included in the tabular data summaries is a function to generate a chart showing pest damage trends for all years in the system and to view information on pests of interest. Functions to generate preformatted pest reports and to export raw data in CSV format are also provided.

The Disturbance Mapper

In addition to the public data explorer, FHTET has deployed a secured Disturbance Mapper Application (Figure 3) designed to use remotely sensed data to detect the presence of pests on the landscape. The application is targeted at individuals performing statewide and regional flight planning for aerial pest surveys. The goal of this application is to optimize flight planning and reduce total survey costs for aerial pest surveys by allowing planners to target areas of interest through map exploration in a web browser.

The basis for identifying areas of interest for pest surveys is based upon change detection data from Modis pre-processed imagery. An number of custom map layer extensions (extending the DynamicMapServiceLayer) have been implemented that allow flight planners to adjust thresholding settings on the change detection imagery to view differences in forest green-up and senescence that signal the presence of tree stressors.

Migrating to the Cloud: As Easy As…

For some time now, the proverbial cat has been out of the bag that at version 10 of the ArcGIS product stack, ESRI will be offering a cloud-based solution for ArcGIS Server. Based in the Amazon Web Services (AWS) cloud, this deployment option provides Amazon Machine Images (AMIs) preloaded with ArcGIS Server for ESRI customers desiring quick deployment, scalability, and flexibility in their GIS infrastructure. So what do we, as architects and developers, need to know to be ready to deploy our custom ArcGIS Server apps to the cloud?

The first thing readers to know is that the process is just plain easy and will simply require a few tweaks from your normal deployment patterns for custom apps built against ArcGIS Server. Figure 4 maps the major system components in a typical example ArcGIS Server solution to major system components used in an ArcGIS Server 10 AWS/cloud implementation.

Once an ArcGIS Server 10 AMI has been launched in the Amazon cloud and sufficient storage space has been purchased and configured, the deployment of an on premise application to the cloud is very straightforward.

· After RDP-ing to the running AMI, the developer simply pulls in (via FTP, copy/paste works for small items) the deployed application and updates any configuration settings

· The RDBMS instance supporting the application, SQL Server in our example, is detached from the on premise deployment database server, copied to the AMI and reattached as a SQL Express instance (we’re well under 4GB).

· In our deployment of this application, we split our geodatabase into operational and base layers. Base layers that do not get edited are stored in a File Geodatabase on the AMI guaranteeing acceptable performance, while operational layers that are editable are stored in an instance of ArcSDE Workgroup on SQL Server Express.

· Finally, any map documents required to support the ArcGIS Server map services are copied to the AMI and the data sources are reset to reflect the new data locations.

It really is just that easy and straightforward.

What about that data thing?

Some readers may be asking themselves why our migration story splits a perfectly good enterprise geodatabase running against SQL Server into a File Geodatabase and Workgroup instance of ArcSDE. The answer lies in that Enterprise Geodatabases are supported by another type of AMI in the cloud, and for our test bed project, another AMI means more money. In addition, the Enterprise Geodatabase AMI is PostgreSQL-based and while the migration process does not involve any magic, it would have required a little more time and effort to get our tabular data in there as well. So we elected to store static layers into a File Geodatabase to guarantee acceptable performance and store editable layers in ArcSDE Workgroup running against SQL Express on our existing AMI, safely under the 4GB file size limit. There are no tile caches used in this test bed deployment.

Conclusions

The cloud-based deployment option available under ArcGIS 10 is sure to present an excellent option to a variety of organizations who have wished for more scalability and flexibility in their existing ArcGIS Server infrastructure. Our experience to date has shown us that for organizations where rapid deployment is critical, ArcGIS Server AMIs can be deployed in approximately 20 minutes (exclusive of data and application loading and configuration times). The ability to create additional AMIs from an already configured instance when coupled with the Amazon Load Balancer means that gaining capacity rapidly when necessary is a real benefit of this new development in the ESRI product stack. This scalability on demand, when viewed against the backdrop of the typical software and hardware procurement process in many organizations is a very real benefit. Furthermore, the flexibility provided to the organization through the capability to deploy this additional capacity on demand, rather than having multiple ArcGIS Servers sit idle awaiting the next emergency response event or natural disaster reinforces this benefit.