It’s good to have choices. Too many options, however, can be a lot of work. When it comes to where your GIS and geospatial applications run, organizations have a myriad of possibilities. Recognizing that it can take a lot of time and energy to change existing setups, cloud computing platforms add a whole new dimension to hosting choices.
As opposed to renting discrete hardware elements, platforms like Amazon Web Services (AWS) and Google App Engine provide the ability to distribute computing services across physical assets. These virtual hardware options lower customer costs through:
- improved rates with shared hardware resources
- reduced labor required to setup, update, and protect applications
- improved flexibility to test and migrate new versions of an application
This two-part blog series will examine what to consider when evaluating a commercial cloud hosting environment. Today’s discussion deals with the business aspects of migration.
Rent or Buy?
Providers may offer computing services with both “reserved” or “on-demand” pricing models. Similar to wireless phone service, you receive a better monthly rate if you reserve services for several years. But “on-demand” pricing will give you more flexibility, particularly important in the initial setup and prototyping phase of a migration.
Always a topic of interest in hosting environments, security considerations are critical for multi-tenant cloud platforms. For security-conscious clients, a provider may offer options to “dedicate” resources to a single account, but usually for an additional fee.
If you have an existing site with existing licenses, you should check with vendors to determine requirements for moving to a commercial cloud environment. Each vendor has its own policies which may affect the business logic for making the move.
Licensing requirements also may give you reason to investigate other options from your cloud provider. For example, some providers provide distributed database services that allow you to access database functionality as a web service, as opposed to licensing, installing, and maintaining database software.
On the other hand, cloud services may not be financially feasible due to the licensing policies of the software using those services. While cloud environments offer great flexibility in terms of scaling resources, you may need to carefully review software licensing requirements necessary to use those additional resources.
Setup and Operation
Setup is a relatively straightforward process for typical Systems Administration staff. There are a few things to keep in mind however, to make the most of cloud services:
* Tip #1: use provider monitoring services (e.g., AWS CloudWatch) for metrics, alarms, and alerts. Most of these services are free to use and mimic the kind of options offered by most operating systems. Although the functions are not as detailed as Simple Network Management Protocol (SNMP), they are easier to setup and relatively easy to maintain. For instance, you can establish email alerts for key system issues to keep your team informed.
* Tip #2: check the Windows OS time zone configuration. Host hardware and Windows time zone differences may trigger problems with the DHCP lease times, rendering a machine unreachable. Your team should verify your configuration so that Windows knows the hardware is reporting time in GMT.
Disaster Recovery (DR) is a bad news/good news story. First, the bad news: you still have to do DR. Virtual Machines fail, instances die, storage can corrupt, host hardware can croak, and hosting sites go offline. The good news is that much of the planning and logistics for DR is easier. A cloud environment simplifies DR since the host provider takes on much of this effort.
You can even employ a database service such as Amazon Relational Database Service that will cover most of your database protection needs, separate from the other DR requirements that you may have. A database service will provide plentiful recovery points, reduce effort, and allow for snapshots to easily record code changes.
Keep in mind, however, that restore times will vary based on your setup. You will have a spectrum between recover and failover, depending on how much money you want to spend to reduce your recovery time.
We touched on database services earlier. While there are numerous business benefits to running a database service, particularly for small- to mid-sized operations, there are technical issues to consider before making this leap.
For one, the ability to fine tune performance-enhancing configurations may be limited. We know of at least one performance issue that would have been easily remedied with access to the full set of SQL server configuration parameters. However, since we were working with a limited set of tools in the database service, “forcing” a query to behave one way or another was not possible. You will also see less admin-level access to the database, and fewer tools for migrating data from the source database.
The takeaway? A database service is a trade-off that makes some efforts easier, while other activities can be more constrained or take longer.
The “cloud” is here to stay and, although it is not the right fit for all circumstances, it is being investigated and even embraced by more organizations. Barriers and prices continue to fall, while the possibilities and opportunities continue to rise.