Hello, and welcome to this lecture where we'll be looking at some of the different migration and deployment options to consider.

When you're in a position to begin migrating and deploying services to the cloud, or even create new workloads from within the cloud itself, there are a few options to choose from, some of which we shall discuss in this lecture.

Start by breaking down each of your services, as they will likely require a different approach. Let's take a look at blue/green deployments.

Blue/green deployments essentially comprise of two environments. One where your current infrastructure is up and running as expected. Let's call this blue. And another, and in this case where it would be hosted within the cloud replicating your on-premise service. Let's call this green. When you are happy with the service and solution you have created within the cloud and you have performed the necessary tests and checks, et cetera, then the green configuration is ready to replace the existing blue service currently running on-premise. Depending on the service and solution, to change from the blue environment to the green could simply mean a change of DNS entry or routine change or a load balance that are pointing to a different environment. Either way, it's a sudden and immediate change onto the new green solution. If there are issues experienced then it's very quickly and easy to change back to the existing and working solution of the blue environment.

Another method of deployment but on a more gradual scale than that of blue/green where there is an immediate shift of workload is by utilizing a weighted deployment offered by some DNS services, for example route 53 in AWS. This allows you to redirect traffic between environments based off of weighting. You could assign your current working on-premise environment a weighting of eight, and the cloud environment a weighting of two. This would effectively redirect two requests out of every 10 to the new environment. This allows you to analyze the new environment for issues when it's under a low demand. If there are problems, then it would only effect 20% of your users or customers whilst the remainder would be redirected to a system working environment. If there are no issues, then you can simply increase the weighting in the favor of the cloud environment until all traffic is fed through to the new solution.

A canary deployment method is very similar to the method we just discussed. However, with canary deployments you would issue a new release to a small percentage of your fleet to see how it responded to real workloads and demands. If successful, you could then slowly roll the same release out to the rest of your fleet until the entire environment had the same release. Again, this is with the intention of if there were problems, then it would only effect a very small percentage of your infrastructure until you resolve the issues.

You may have existing virtualized servers on-premise that you would like to host within the cloud, and there are some providers that offer tools to help you migrate these existing images onto their platform and into their environment. The transition of virtualized servers into cloud instances can save you a lot of time by performing in the import rather than having to recreate an instance from scratch, as you may have to do with some of your non-virtualized servers. Also it allows you to keep the existing configurations you have made, whereby you may have hardened the instance from a security perspective.

When it comes to application deployments, there are a range of different services from cloud vendors that offer great solutions for this. How each of these services work are out of scope for this course, but be sure your developers and deployment teams are aware that it exists, which can utilize automation, continuous integration and delivery methods. For more information into these concepts, take a look at the other courses here at CloudAcademy regarding delivery of services across cloud providers for deeper, in-depth technical content on how to achieve this, such as:

Introduction to Continuous Delivery

Introduction to Continuous Integration

Advanced Deployment Techniques on AWS

As a part of this migration process, you need to define how you're going to move your data and applications into the cloud, and this opens up a few considerations.

Firstly, how will transfer your data into the cloud? You may only have a small database or a few gigabyte's worth of data that you need to move to a storage service. Initially, this could easily be managed by internet connection. However, is this method secure? Is the data confidential? Should it be encrypted when performing this data transfer? And what if you need to transfer petabytes of data instead of just a few gigabytes?

Transferring data into the cloud is typically free, but how you do it depends on what data you are transferring and how much of it.

The amount of data you need to transfer into the cloud will require different methods of importing. Cloud vendors will provide a variety of options to help you achieve this. Like I mentioned, if you only have a few gigabyte's worth of data, then you could manage this transfer yourself, either through the vendor's portal or via an API or through your internet connection. However, if this is going to take a long time and you are lucky enough to have a direct connection into the vendor's platform and onto your own environment, you could utilize his high bandwidth connection to make the transfer quicker or to move more data.

In certain circumstances, you may have terabytes' or even petabytes' worth of data that you require in the cloud. In this instance, internet connection or direct connections will simply take too long. It could take weeks or even months to transfer that amount of data, which simply isn't efficient. In these circumstances, cloud vendors offer disk shipping services where your data is loaded onto physical disks from your on-premise environment, and then it is shipped directly to the vendor's data center where your data is then imported into the cloud environment. This method is far quicker to import huge data sets. These services also offer intense security feature sets, from being able to even request an import/export request to encryption protocols. For a full set of security features, see your chosen vendor's documentation.

If you are transferring sensitive data over the internet or via a VPN connection, or even direct connection into the cloud, then it's important that you apply the correct level of encryption to your data, both when in transit and at rest.

Define your data sets when migrating and ascertain which data requires that greater level of security and encryption applied.

You may have the need for synchronization and replication to take place between your cloud environment and the services on-premise. If this is the case, assure you have adequate bandwidth for this synchronization to happen. Will you need to perform asynchronous replications or synchronous? The difference between the two being that synchronous replications writes to both the primary and secondary storage points at the same time. This, of course, requires high bandwidth capacity. Asynchronous writes to the primary first and then the secondary storage point. Asynchronous replication does not require as great a bandwidth as synchronous.

This brings us to the end of this lecture. Coming up next, we will take a look at cloud optimization and cost management.