Cloud Migration – Moving Applications to the Cloud

Over the last few weeks, as I have been talking with customers, it is becoming more and more obvious that the information customers have been given related to the moving of their Applications into the Cloud is getting very muddy. The most common term that Microsoft, Amazon, and Google like to throw around is “App Modernization” which does make a lot of sense and has an appeal, but it does not truly give you all the information that you need to determine how you should think about moving your specific application into the Cloud and what the different options are.

In this blog post, I want to talk about the four terms that truly cover the majority of the options and how you should think about them when considering them for your applications:

• Application Migration
• Application Modernization
• Application Containerization
• Cloud Native Application Development

Please be aware that this is just a conceptual discussion to help you determine what might be the best approach for you to consider when thinking about moving your Application into the Cloud. It is not meant to be a complete detailed walk-through of all possible options or services that you might need to learn.

Application Migration

This first one is pretty straight forward in that you are taking your application and moving it as-is into the Cloud. Most people consider this to be a “Lift and Shift” motion which typically implies that you will be moving the application into Infrastructure as a Service (IaaS) which is not always the most cost effective path nor does it provide any improvements with respect to administrative efficiencies. This is certainly a possibility and perfectly valid if it will be more comfortable for your staff that will be managing and maintaining the application(s) after migration.

However, when migrating an application into the Cloud, most customers prefer to take advantage of services that can provide cost cutting measures as well as those that can provide improvements with respect to the management and maintenance of the application’s architecture. For example, wouldn’t it be easier if your team didn’t have to worry about the patching and updates to the Operating System or Database software that are required to run your application? These are feature that you will typically find when leveraging Platform as a Service (PaaS) services within the major Cloud providers that can host your applications.

You might be reading this and looking at the list above and be asking yourself if I am not describing to you an Application Modernization effort with respect to your application moving into the Cloud. You would be correct, but only for the architecture, not for the application itself. By taking advantage of these PaaS services you are truly only migrating the application without making any changes, but you are still seeing some improvements in different areas. This level of Application Migration is just a starting point and one that all customers should consider when starting their Cloud journey.

Application Modernization

Let’s take this a step further and take the same application but make some improvements to it to take advantage of some Cloud Native services that will provide better Monitoring/Logging, better Security, or even better Performance for your application by making some minor modernization changes to your code base.

The first place that I typically like to start is from the security perspective. Most applications require some level of configuration and/or integration connectivity such as to a database, storage location, or messaging service. When working with any of these types of services, there is usually a very private and secure connection string or key that is required to make that connectivity work properly. This type of information is something that you do not want to hard-code into either your code or configuration file.

When deploying your application to a Cloud environment you should try to store these keys, connection strings, passwords, and other secure pieces of configuration data within a secure service of some kind. Both Microsoft and Amazon provide what is known as a Key Vault or Service where you can store, secrets, certificates, and keys that can then be leveraged throughout your applications and data storage services with only a few lines of codes in the worst scenarios and in a directly integrated way in some other easier scenarios.

Another type of modernization that could be easily considered on day one when moving your application into the Cloud is around Monitoring/Logging. All of the PaaS services that you will use to publish your code to have their own Logging and Monitoring capabilities, but that will not be application specific. What if you need some level of Application Performance Monitoring (APM)? In that instance, both Microsoft and Amazon have ways that you can add a few lines of code in different areas of your application and have that produce monitoring metrics for how your application is performing and then display that information either within the Cloud Provider’s portal or be made available as log files that you can consume in your own tools and/or engines.

These are just a couple of examples of how you could modernize your application as your move into a Cloud environment and these are just some of the easy ones. There are definitely some other examples that would require a lot more work. This also assumes that you application and its relevant code and possibly database are supported within the Cloud provider of your choice and this is something that you will need to research before moving forward.

Application Containerization

There are is a lot of hype around containers today, but most customers do not have any idea where to get started and the thought of trying to deploy into a Kubernetes cluster can be quite daunting. It just so happens that it really doesn’t have to be that big of a worry. Most of the Cloud providers today provide one or more mechanisms for publishing a container as you would any other application without having to take on the extra complexity of deploying to a container orchestration engine like Kubernetes, OpenShift or other such solutions.

With this approach, you are looking at your application in much the same you do in the Migration approach mentioned above. The difference is, you no longer need to worry about whether or not your code will work in the particular PaaS environment that the Cloud vendor provides. As long as you can create a container that matches what your environment looks like today without worrying about the OS or other specific VM configurations, then you can publish your application and make it available to your user base.

The hardest part of this approach is learning how to create Docker images which will then get published as containers within the different Cloud providers and this will require you learning the Docker command line tools in combination with the DockerFile format. The DockerFile format is what defines how the container should be displayed to the engine that will be publishing it and making it available through some type of endpoint. The great thing is that once you learn these tools, you will be able to not only create your own images/containers, but you will be able to automate the process through CI/CD pipelines any of the popular DevOps tools.

Once you are ready to attack this approach, all you have to do is create a container image that most closely matches your production environment today and then make sure that your code is pulled into that image. Once the image has been created, it will need to be published into a Container registry such as DockerHub, Amazon’s Elastic Container Registry or Microsoft’s Azure Container Registry. Once in a registry, the image can be published as a container in one of a number of different container engines that are not considered container orchestration engines such as Amazon’s Elastic Container Service or Microsoft’s Azure Container Server or App Service and these services will display your container as an endpoint within their service.

NOTE: Each Cloud provider makes this possible in different ways, so please make sure to read up on them before starting down this path.

Cloud Native Application Development

If you really want to take advantage of all that the Cloud can provide for your applications, then developing the application to use Cloud Native services would be the last and final approach. Be aware though that this approach will require the most amount of development or customization to your application and probably a complete re-architecture. It will require you to learn about certain technologies that you might not be familiar with, but would replace certain portions of your application in a great way. Here are just some of the examples that you might want to think about:

Replacing Full Text Search with a Cloud based Search Index

Rewriting REST APIs as Serverless Functions

Implementing Event based Programming for Backend Processes

Removing direct Protocol connectivity between areas of your Application and Implementing a Cloud Messaging service to provide better performance

Taking advantage of out of the box Artificial Intelligence Services that can provide new functionality to your Application

Each Cloud provider have their own versions of these types of functionality and many others that you might find useful as well, but be aware that once you decide to go down this route that you will be locked into that particular Cloud provider for hosting and supporting your application. That is one of the few disadvantages of the Cloud Native approach.