Cloud Migration Strategy

I’ll discuss the cloud migration strategy. One consideration is whether we’re going to be migrating existing virtual machines or applications that we currently have running on-premises to the cloud.

We have to account for the fact that performance, security, and reliability must be maintained when we do migrate this and run it in the cloud. In the cloud, often we end up with increased resilience. One of the reasons for this is due to the replication between different datacenters.

We also have the option of load balancing and auto-scaling in the cloud, whereby we can respond to increased demand for a specific service. When we’re building new virtual machines or applications in the cloud as opposed to migrating the existing ones to the cloud, we can employ many resources that are made available from the cloud service platform such as application programming interfaces.

There are many APIs that are exposed to developers that let us access and work with Amazon Web Services resources. We can also provision EC2 instances, either programmatically through an API or using the interface in the web console. We can provision database instances, S3 storage, we can configure CloudWatch alarms, and so on.

It’s important that we identify which applications that we might be running and depend upon that can run in the cloud. Not every application is a good candidate for running in a cloud computing environment.

A good candidate for a pilot initially would be some kind of a non-critical application, whether it’s a development type of environment or a testing or some kind of a non-crucial web site. But moving an app to the cloud also normally means moving data.

So we have to think about how we’re going to securely get a sample dataset in the cloud that will be used by an application that we might pilot. We can also identify IT resources and tools that we can reuse in a cloud computing environment.

Bear in mind that Amazon Web Services has a number of different programming models and languages available for selection. We should also consider the fact that if we have EC2 instances running in the cloud, we can load pretty much any software that we wish within those running instances. It would just be hosted on the cloud provider infrastructure.

If we decide to migrate existing systems from on-premises to the cloud, then we should think about the removal of any existing hardware, software, or service contracts that were required when we were running things on-premises. Those may no longer be required, and instead, we might be running things in the cloud where the service level agreement would come into play. In some cases, software licensing would require us to use our own licenses, as in BYOL – bring your own license. But in other cases such as when provisioning certain types of databases in the cloud, there might be cloud supplied licensing already made available.

Migrating IT systems to the cloud should be done incrementally. This means that we could run components or systems in parallel. For example, we could run some components on-premises as well as some in the cloud. This way the components could still communicate with one another, perhaps through an AWS Direct Connect link or through a VPN.

Migrating to the cloud means that we will incur one-time costs to prepare, evaluate, test and then actually do a migration of our production system into the cloud. Often, there’s a resistance to change from staff. The resistance could be based on cultural or socio-political impedance issues.

Often, once we have proper training, then a lot of those resistant to change can be reduced or go away.

A part of a cloud migration should also include training that is provided to technicians as well as end users that will be affected by moving IT systems to the cloud. It’s important that we focus on the long-term return on investment in the cloud and not look at just the short-term costs in initially doing a migration.

Remember that with the cloud, we are often working with operational expenses over time instead of an up-front capital expenditure for IT infrastructure and services. We also need a way to measure how successful we were or were not in migrating IT services to the cloud.

Cloud Migration Benefits

Here are some common scenarios that will be benefited from cloud migration.

• If your application is experiencing increased traffic and it is difficult to meet the demand.

• When your clients need faster deployment and access to applications ( cloud increases focus on development rather than infrastructure implementation).

• When it’s becoming more difficult and expensive to keep up with your growing storage needs.

• Benefits startups (cloud computing shifts IT expenditure to a pay-as-you-go model).

Costing the Cloud

Costing is broadly categorized as:

• CAPEX (Capital Expense)
• OPEX (Operational Expense)

Given here are certain scenarios that illustrate the usage of CAPEX and OPEX:

• In traditional Internal IT Infrastructure environment where everything is set up and managed internally, high CAPEX and OPEX are incurred.

• In case of a colocation facility, where a location that hosts the infrastructure is owned or rented from a third party, high CAPEX and a slightly lower OPEX is incurred.

• Consider an environment where services are managed by outsourcing them, it incurs reduced CAPEX and increased OPEX.

• Now, if you consider a public cloud in which the infrastructure is fully outsourced, it incurs only OPEX and CAPEX is cutoff.

Cloud Cost Models

If you plan to adopt a cloud model, you need to consider reducing the operational cost as against reducing the capital expenses.

Given here are some commonly used cloud models:

• Free Payment Model: Majorly used in marketing or advertising type of companies where consumers will be able to register and use the service freely. It helps the companies to market their product based on the usage metrics.

• Plan Payment Model: Subscription-based usage, where users will be allowed to access the cloud for a specific period/cost.

• Pay as you use: As the name suggests in this model, you will pay based on what you have used.

Applications Suitability for Cloud

Cloud computing can certainly provide a number of benefits. But when considering a move to the cloud, you’ll also have to consider your applications. And certain applications, like anything, are better suited to cloud computing than others.

So you want to consider applications that are required may be only for a limited period, maybe your organization is going through a developmental phase that is only going to be temporary and you require some kind of software application to support that phase.

Well, a cloud implementation of that application might be much more cost effective than purchasing and licensing that software and then dealing with the distribution, the deployment, and the configuration, and the upgrades, and the maintenance, and all of that.

So definitely, you might want to look at a cloud-based solution there or any application that needs to be scaled often or that might have variable loads.

This is a good candidate because it’s so fast and easy to scale in a cloud environment and then to distribute that load because new virtual machines, for example, can be provisioned within minutes. At the end of the day, you are still relying on your Internet connectivity when accessing the cloud services.

So an application that is non-critical is a little better suited to the cloud because if you do lose your Internet, you, of course, lose access to the cloud and hence that application. So public cloud models are definitely a great solution for startup companies, particularly because of that minimal initial capital outlay and the scalability that’s offered.

You know, a lot of startups just cannot come up with the funds necessary to outright purchase an IT infrastructure. So with cloud services, the infrastructure is already there. You simply subscribe to it and there’s your IT solution.

Not only is that a better option in terms of cost, but it is very fast and very flexible. So this agility enables a quicker time to market for new products because you just don’t have to spend the time or the money to implement your infrastructure.

Now it may not be the ideal solution with things like legacy systems, mission-critical applications, or applications that handle sensitive data. So with the legacy, there might be an increased cost in dealing with any kind of outdated technologies or proprietary hardware and software that’s required to drive them.

They may not be compatible with the cloud platform, so that’s always something to consider. And again, for mission-critical applications, it might not be suitable for a cloud type of adoption here because again you are relying on the Internet.

So real-time connectivity for these mission-critical applications may be required and if your Internet goes down, well, you lose connectivity to that application. So that could be disastrous. And applications handling the sensitive data, there is an increased risk with transferring or storing highly confidential or sensitive information in the cloud because, again, it is no longer under your physical control. So you always need to be aware of that.

Those are some of the limitations and considerations in terms of assessing your application compatibility for a cloud type of environment.