There are hundreds of thousands of companies around the world that are already using the Cloud platform to build successful global business. Their early adoption of the Cloud is helping them to accelerate time to market in rolling out their customer offerings across the world. Developers and architects looking to build new applications in the Cloud can simply design the components, processes and workflow for their solution, employ the APIs of the Cloud of their choice, and leverage the latest Cloud-based best practices for design, development, testing and deployment. In choosing to deploy their solutions in a Cloud-based infrastructure, they can take immediate advantage of instant scalability and elasticity, isolated processes, reduced operational effort, on-demand provisioning and automation.
At the same time, many businesses are looking for better ways to migrate their existing applications to a Cloud-based infrastructure so that they, too, can enjoy the same advantages seen with greenfield application development. One of the key differentiators of Cloud-based infrastructure services is its flexibility. It gives businesses the freedom of choice to choose the programming models, languages, operating systems and databases they are already using or familiar with. As a result, many organisations are moving existing applications to the Cloud today.
Most applications, data or IT assets within an organisation can be moved to the Cloud today with minimal effort. This 2-part series will help you build an enterprise application migration strategy for your organisation. The step by step, phase-driven approach, shared high-level insights on how to identify ideal projects for migration, build the necessary support within the organisation and help you migrate applications with confidence.
Figure 1: The phase driven approach to Cloud migration.
Cloud assessment phase: Phase 1
This phase enables you to build a business case for moving to the Cloud. It includes examining the costs, security and compliance, and identifies the gaps between your current traditional architecture and next-generation Cloud architecture.
Weighing the financial considerations of owning and operating a data centre or co-located facilities versus employing a Cloud-based infrastructure requires detailed and careful analysis. In practice, it is not as simple as measuring potential hardware expense alongside utility pricing for compute and storage resources. Indeed, businesses must take a multitude of options into consideration in order to affect a valid comparison between the two alternatives. Cloud providers have published whitepapers to help you gather the necessary data for an appropriate comparison.
If your organisation has specific IT security policies and compliance requirements, we recommend that you involve your security advisers and auditors early in the process. Data security should not be an issue in the Cloud when handled properly. It is important that you understand your risks, threats (and likelihood of those threats), and then based on sensitivity of your data, classify the data assets into different categories (discussed in the next section). This will help you identify which datasets (or databases) to move to the Cloud and which ones to keep in-house. Be aware of the security guidelines from major Cloud providers. In the case of Amazon Web Services (AWS), for example:
- You own the data
- You choose which geographic location to store the data. It doesn’t move unless you decide to move it.
- You can download or delete your data whenever you like.
- You should consider the sensitivity of your data, and decide if and how you will encrypt your data while it is in transit and while it is at rest.
A technical assessment is required to understand which applications are more suited to the Cloud architecturally and strategically. At some point, enterprises should determine which applications to move into the Cloud first, which applications to move later and which applications should remain in-house. Perform a thorough examination of the logical constructs of your enterprise applications and start classifying your applications based on their dependencies, risks, and security and compliance requirements.
Figure 2: Example of a whiteboard diagram of all the IT assets and its dependencies (Dependency Tree).
After you have created a dependency tree and have classified your enterprise IT assets, examine the upward and downward dependencies of each application so you can determine which of them to move to the Cloud quickly.
It is also important to iron out licensing concerns and work with a Cloud provider that has teamed with a variety of vendors. If your enterprise applications are tightly coupled with complex third-party enterprise software systems that have not yet been migrated to the Cloud provider or if you have already invested in multi-year on-premise licensing contracts with the vendor, you should consider refactoring your enterprise applications into functional building blocks. Run what you can in the Cloud and connect to the licensed software systems that still run on-premise.
CIOs will need to set specific success criteria that are customised to organisational goals and culture. For example, the following is a table of comparisons on how to measure success:
Proof of Concept: Phase 2
Once you have identified the right candidate for the Cloud and estimated the efforts required to migrate, it’s time to test the waters with a small proof of concept. The goal of this phase is to learn about the Cloud provider features and ensure that your assumptions regarding suitability for migration to the Cloud are accurate. In this phase, you can deploy a small greenfield application and, in the process, begin to get your feet wet with the Cloud provider.
Build a proof-of-concept that represents a microcosm of your application, or which tests critical functionality of your application in the Cloud environment. Start with a small database (or a dataset); don’t be afraid of launching and terminating instances, or stress-testing the system. In this stage, you can build support in your organisation, validate the technology, test legacy software in the Cloud, perform necessary benchmarks and set expectations. After this stage, you will have far better visibility into what is available with Cloud providers, make careful assessment on the appropriate provider that has a good track record of experience and innovation to give you the most flexibilities. You will get hands-on experience with the new environment which will give you more insight into what hurdles need to be overcome in order to move ahead.
Data migration: Phase 3
In this phase, enterprise architects should ask following questions:
- What are the different storage options available in the Cloud today?
- What are the different RDBMS (commercial and open source) options available in the Cloud today?
- What is my data segmentation strategy? What trade-offs do I have to make?
- How much effort (in terms new development, one-off scripts) is required to migrate all my data to the Cloud?
When choosing the appropriate storage option, one size does not fit all. There are several dimensions that you need to consider so that your application can scale to your needs appropriately with minimal effort. You have to make the right tradeoffs among various dimensions - cost, durability, query-ability, availability, latency, performance (response time), relational (SQL joins), size of object stored (large, small), accessibility, read heavy vs. write heavy, update frequency, cache-ability, consistency (strict, eventual) and transience (short-lived). Weigh your trade-offs carefully, and decide which ones are right for your application. The beauty about AWS is that it doesn’t restrict you to use one service or another. For example, Amazon Web Services offers variety of data storage options today:
This is part one of CIO's two-part guide on migrating enterprise applications to the Cloud. Read part two: Application migration, leveraging the Cloud and optimisation.
Jinesh Varia is the technology evangelist for Amazon Web Services (AWS).