Friday, March 1, 2013

EucaStart 2.0 Stage 2 - Cloud Architecture: Application Stack Considerations

In the previous entry in this series, we took a look at networking considerations when designing a Eucalyptus cloud. In this entry, we will take a look at application stack considerations.

Application Stack Considerations

The second area to be probed in terms of a Eucalyptus Solutions Architecture is the application stack. This is just as, if not more important than networking as many application workloads are not optimized for the cloud. With the assumption that the use case has been properly qualified as a valid use case for cloud, this moves down the list to second in terms of data acquisition and design. The application stack has to be understood in several ways.

First, we must understand how the current applications function and what the current infrastructure they sit atop looks like. We also want to know if these applications will be carried over to the new cloud, ported in some way, refactored or sunsetted in favor of newer 'cloud-enabled' applications. Assuming that we are moving the existing applications into the new cloud or are able to gather metrics for the new applications that will replace them, we start to look at certain metrics to gauge the size of the new cloud. We gather data on the aggregate amount of CPU and memory usage of all applications that will migrate to the cloud. We gather data on the current networking load of these applications; both nominal and peak. We gather information on disk usage; both space and IOP count. Questions and considerations:
  1. This can disqualify the cloud as a viable alternative because of poor fit - it’s important!
     
  2. There are multiple ways to bring apps to cloud. How does the customer plan to do this?

    * Move them over as legacy in a virtual machine and try to use Eucalyptus like Vmware (not optimal, but ok if it’s a small percentage of intended usage)

    * Containerize the applications -- stick applications inside virtual machine applications such as ThinApp (Again, not optimal, but ok in small doses for overall cloud usage)

    * Refactor the applications - Change the code to make it cloudified vs. a persistent nature. (Not often done.)

    * Replace legacy apps with new, cloudified applications (best use case)

    Note: For existing apps that are going to move, there are existing metrics we can gather to help size the cloud correctly.

    * What is aggregate CPU/RAM usage for apps, and estimates for the new apps. Pay attention to peaks in addition to averages.

    * What is the networking load for these apps? (Again, nominal and peak - must plan for peak. tradeoff is cost.)

    * Disk and storage usage - how much disk space in use, disk bandwidth (IOPS).

    * Are customers actually aware of their own performance metrics?

    * Is there an application or group of apps that have unusually high requirements in any of these areas? 90% might be low utilization, but might have a few apps that thrash the system

  3. Misc. --- Ask deeper questions...
In our next post for this series, we will take a look at cloud storage considerations.

No comments:

Post a Comment