This post is part of a discussion around transitioning applications, as well as development and operations teams, to the Cloud. Read When It Comes to Cloud, First Things First – Strategy and Training >>

Previously, we discussed needing to have a strategy in place to move applications to the Cloud, as well as ensuring that your development, architecture, and IT teams have, and complete, training plans in order ensure a successful transition to the Cloud. We went into further detail around training and so now let’s switch gears and dive deeper on the application strategy.

The first task to complete as part of the strategy is to determine which of your applications would be good candidates for moving to the Cloud.

The Microsoft application platform is built of products and technologies that provide a continuum of targeting choices as you think about where your solution would be best deployed:

all of which use the development and same management tools.

image

However, though they are close to being 100% symmetrical, meaning you can run the same code without modification in each of the environments, you wouldn’t necessarily want such parity. Applications are built to solve specific business and technical needs, and as part of good architecture practices, the environment to which they are deployed must be built to meet those different needs. As such, not all application workloads are great candidates for a Cloud – private or public. Further, not all applications can be moved to the Cloud while maintaining the exact design and code as on-premise. The close symmetry of the target environments tends to encourage many to take a “forklift” approach – to move applications to the Cloud as-is without considering the subtle, but present, differences of the different technologies. This type of approach usually lends itself to surprises down the road, from performance degradation of function limitation, or unexpected costs. In order to truly take advantage of a Cloud platform (scale, reduced infrastructure and management costs, elastic storage, etc), portions of the application may need to be rewritten.

image

Through the exercise of creating your strategy, you’ll determine:

  • Which applications are candidates to move to the Cloud
  • Which ‘Cloud’ is the right ‘Cloud’ for the application
  • What is the optimal architecture of the application in the Cloud
  • Which areas of the application may need to be refactored and rewritten

To make those determinations:

  1. Consider where and how your application stores durable state. How it handles state will have a large effect on the suitability of the cloud as a target environment.
  2. Consider how (and even if) your application intends to scale. How your application is designed to scale determines whether your application should target specialized hardware (in a scale-up fashion), or whether commodity hardware is a better environment for your application (to scale out). In addition to the hardware capability question, how loosely coupled your application is and the demand patterns your application typically encounters also play large factors in evaluating applications for the cloud.
  3. Consider application latency and SLA requirements. Shared cloud systems may or may not guarantee uniform/low latency among components, and placing some parts of your solution in the cloud (say, the data layer or some services that extend your line of business application) may introduce new bottlenecks, and should be considered. On the flip side, the cloud may also allow you to reduce latency in a move, being able to geo-distribute your application closer to your customers – as opposed to all having to come into your data center.
  4. Consider legal implications around your application – which has to do with evaluating the sensitivity of the data that your application handles, whether there is any legal or compliance concerns around the data and the location (or locations) that the data centers are located in. Particularly if you are handling personally identifiable information (PII), you may need to pay close attention to how and where that data is stored – you may need to encrypt some data before storing it, or you may need to segment out the data, storing sensitive data on-premises and only storing transactional information in the cloud. Additionally, you may also need to consider broader regulatory impacts on the application and infrastructure, seeing if the geography of execution brings any additional legal restrictions or tax implications on your organization.

Next, we’ll continue working on the strategy, by looking at additional considerations in the following seven key areas: application design application scale, application dependencies, latency requirements, data sensitivity, SLA requirements, and regulation and compliance.