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.
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.
Through the exercise of creating your strategy, you’ll determine:
To make those determinations:
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.