Migrating to the Cloud

In this blog post I want to discuss how to migrate your applications to the cloud.
Specifically how to migrate your existing applications to the cloud using a “Forklift” approach. The intended audience are IT Architects and IT Managers who are considering moving existing applications to the cloud.

We see different triggers to migrate an existing application to the cloud. These are closely linked with important benefits when migrating existing applications to the cloud.
One important trigger is the desire to introduce more agility into an existing application stack. Development teams all over the world are adopting continuous delivery principles. Most existing old hosting platforms lack the flexibility to facilitate the requested agility. The cloud has been developed with exactly this flexibility in mind.
Other examples of cloud benefits are: zero upfront hosting investments, pay as you go, scalability, elasticity and automation.
The limits of your existing application determine whether your application can leverage one or more of these benefits.

There are several approaches to building a cloud strategy.
We’ve seen customers from all size companies, from all industries get started with the cloud in different ways.
Building a cloud strategy really depends on the your organization’s needs.

We see two main cloud strategies: one for new applications and one for existing applications.
New application should be build and designed with the cloud in mind.
These applications are designed using some or all of the cloud architecture patterns such as elasticity and loosely-coupled systems.

Existing applications require a different approach than new applications.
These applications require defining a migration plan and transitioning application by application. As you define your migration plan, you’ll find that some applications are ready to move right away. Other apps, however, might require a slower, more methodical plan.
This strategy has worked for several of our customers.

The existing applications fall into two groups. Easy to move applications and applications which require a full blown migration project.
Easy to move applications are easily migrated to the cloud with virtually no time or effort. Mostly these applications are, what I call, “flat sites”.
Sites with no database, no external connections, just information to share.
An example of such a site is a campaign site. Placing such a site in the cloud, apart from your corporate CMS, gives you a shorter time to market for the campaign team using the clouds build in continuous delivery facilities, pay only for the resources your campaign uses and maybe most important elasticity and scalability through auto-scaling. The success of your campaign is usually hard to predict up front. Auto-scaling in the cloud removes this architecting burden, as your platform will scale up and down with the presented load.

More complex applications should be migrated to the cloud in a phased project. Examples of such applications are eCommerce applications and enterprise CMS applications.
In my experience a key success factor when migrating these complex applications to the cloud, is to perform “Forklift Migration”.
In a forklift migration the infrastructure architecture of the existing application is mirrored into the cloud. I.e. the number and type of servers, shared storage setup, DBMS configuration are virtually identical between the old and the cloud platform.

To enable a forklift migration we must start with an preparation phase. During this preparation phase we determine whether the cloud can provide all components, functionalities and services needed to run your application. During this phase we also check how we can migrate the data to the new cloud platform. Another important check is if all licenses used are cloud compatible. Most standard software vendors nowadays have cloud compatible license models, but they often differ from the on-premise license model. Finally we have to make sure that the customer’s internal and external governance allows a move to the cloud. I.e. internal risk management directives could dictate in which country data needs to be physically stored. The intended cloud solution should meet these requirements.

The preparation phase is the first of six phases.

Fase_Pijl

At the end of the preparation phase, when all details of the existing application are known, a migration plan is created. The migration plan should contain all the details of the next phases. Key part of the migration plan is to define the success factors of the migration project. What is the goal of the project? When is the project a success? Make these success factors as SMART as possible. I.e. old OPEX are €25.000,- , new OPEX should be less then €15.000,- or the current time to market of new functionalities of our existing application is 3 months, after the migration project this should be 1 month.

The next phase of the project is the Proof of Concept phase. In the proof of concept phase we want to test and demonstrate that the existing application can indeed run successfully in a cloud environment. In the Proof of Concept phase we also want to test and the data migration process. Especially in environments with heavy data processing which are highly dependant on online data availability. I.e. migrating a products, customers and orders database of an eCommerce platform to the cloud, with minimal downtime of the online shop, requires intensive planning and testing of the chosen data migration strategy.
Last but not least we want to test connectivity between the new cloud platform and any external data source. I.e. API’s of corporate backend systems or payment providers.

During the application migration phase the new hosting infrastructure is build according to the designs from the preparation phase. Applications are installed and configured on the new cloud platform, load and stress tested, security scanned and application and functional monitoring is configured.

Next the data migration phase is either a small and easy step in the process or a delicate, high risk, daunting operation. It all depends on the type and volume of the data which has to be migrated. Migrating a 50MB content database of a CMS might be a simple backup – restore operation on the old and the new database servers. However migrating a 500GB products database of an eCommerce is a whole other ballgame.
As mentioned before, it’s all in the planning. If you’ve planned, tested and perfected your data migration process during the planning phases, you should be fine.

Now you’re live in production in the cloud. If all is well, you’ve met the goals you’ve set during the preparation phase of the project, and your project is a success. Congratulations! You’ve made a giant leap forwards opening up new possibilities for your application which weren’t present in the old environment.
These optimizations are part of the next phases of the cloud migration. They often require small to quite significant code changes to your application.
Based on my own experience I would suggest to plan these changes, build and test them, but don’t release them directly to the production environment.
Take some time as cooling down period after you’ve successfully deployed your application in the cloud. I.e. in case of an eCommerce application, wait until after your next big sale period.
Make sure that your application is successful in the new cloud environment before making big changes to your application code, which are related to changing how your application interacts with it’s infrastructure platform.

Optimizing your application for the cloud can be divided into two phases. The first phase is leveraging the cloud possibilities immediately available to your application. The low hanging fruit. I.e. auto-scaling, setting up rules to downscale your environment during off-peak periods and upscale during peak periods. Another example is shared storage. It’s very likely your application used some sort of shared storage solution in the old architecture, which you’ve replaced during the forklift migration with a cloud NFS server. The cloud however provides several shared storage options which are far better than maintaining your own NFS cluster. It’s possible that your application can leverage these without too much software changes.

After leveraging all the low hanging fruit in the cloud it’s time to consider bigger changes to your application to leverage even more cloud components. Lots of functionality used by your application is provided by your cloud provider as standard building blocks. I.e. distributed caching. Most applications have some sort of distributed cache built into the application. However most cloud providers offer standard distributed cache services. For obvious reasons a good case can be made to use these standard offerings instead of building your own bespoke components.

The last two phases are in fact an on-going process, as the development of the cloud and it’s components and functionalities is an on-going process.
Making sure you’re up to date with the latest developments of the cloud, is key for continuing to being successful in the cloud.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s