Checklist: Managing applications in the cloud

Moving applications to the cloud is not for the faint of heart. Issues can crop up that may force you to re-architect the application, compliance requirements can create roadblocks, and bandwidth problems can occur if your cloud provider does not support low-level networking services such as multicasting.

After you’ve assessed which applications can run in a public cloud, there are other factors to consider -- configuration, data migration and monitoring. What are some of the most common configuration tasks you need to keep in mind when migrating an app to the cloud? This checklist outlines key points:

• Service catalogs may contain older versions of virtual machines (VMs) that are not sufficiently patched for your needs. Use base images that have the latest security and functional patches.
• Review all daemons and services running on an image and shut down all images that aren’t needed. This will reduce the attack service of all VMs.
• Configure firewalls between application layers to minimize network traffic between layers. For example, you should only open ports that are needed to accept and respond to queries and support management protocols.
• If you require strong encryption, such as PCI DSS, ensure your SSL/TLS encryption is strong. The client and server in an SSL session negotiate which cipher suite to use; they may not use strong encryption if not configured to do so.
• When using a hybrid cloud model, configure a virtual private network (VPN) to secure communications between internal and external resources.
• Use SSL server certificates to authenticate servers and support encrypted communications. Depending on your architecture, you might be able to use domain level or subject alternate name (SAN) certificates to help minimize the number of certificates you have to manage.
• Use configuration tools such as Chef or Puppet to automate cloud management tasks.

Methods for moving data to the cloud
In addition to configuring cloud resources, you’ll need a plan to move data from the existing system to the cloud-based system. There are several approaches to migrating data; the best option will depend on your enterprise’s requirements and architecture.

One approach is to use database replication to establish a copy of your database in the cloud before moving the system. If you’re using the cloud for disaster recovery (DR), a replica may already exist in the cloud. With this method, your production system remains live while changes are written to the replica. The time needed to switch from the current production system to a cloud-based system is minimized.

Bulk back and restore is another approach to data migration, which fits with non-transaction-based systems, such as data warehouses and other business intelligence (BI) databases used for data mining. However, this approach can delay the initial loading of the cloud-based database as well as incremental updates.

In addition, not all data is stored in relational databases. For file-based data stores, you may want to use rsync , a synchronization utility often used for mirroring and backup. Rsync is available for Unix/Linux and Windows platforms.

Effectively monitoring cloud-based appsMigrating applications to the cloud will extend your infrastructure and create additional resources you must monitor and manage. To keep all applications running properly, you should:

• Include logs from cloud servers in the central log management repository. You may want to maintain a separate log management repository in the cloud to reduce network traffic and changes from the cloud to your internal centralized log management repository. Remember, though, this can undermine some benefits of having a single point of access to log data.
• Use event triggers to generate alerts about significant events on cloud servers.
• Regularly use vulnerability scanning tools, such as Tenable’s Nessus, to check for security weaknesses on cloud-based VMs.
• If you are using a pay-as-you-go model of cloud computing, automate the tracking of CPU use across servers and shut down servers when usage rates drop below a defined threshold. Dynamically add servers when demand surpasses threshold rates.
• Use spot-pricing instances to save money. Amazon EC2 offers unused capacity at varying prices, depending on demand. For example, you make a bid to pay a particular price per hour for a VM, and as long as your bid remains above the set price, you can continue to use the VM. This model works well if you don’t need the job to be complete on a set date or time. Spot pricing also requires that your job recover without losing too much work if a bid falls below the spot price and your VM is shut down.

Before migrating applications to the cloud, review your system architecture. Pay particular attention to network services and traffic volume between internal servers and potential cloud-based servers. When it makes sense to move certain apps to the cloud, carefully consider system configuration, data migration processes and ongoing monitoring and management procedure.