Journey to Google Cloud – Part -1

Let’s Begin the Journey to Google Cloud

While planning your migration to Google Cloud, you can start by defining the migration-related environment. Your starting point can be the on-premise environment, a private hosting environment, or another public cloud environment.

The environment on-premise is where you have full rights and responsibilities. You maintain complete control over every aspect of the environment such as air conditioning, body care, and hardware maintenance.

In a private hosting environment, like a joint venture, you outsource a portion of the physical infrastructure and its management to an outside party. This infrastructure is generally shared among customers. In a personal hosting environment, you don’t have to manage physical security and safety services. Some hosting environments allow you to manage a portion of the physical hardware like servers, racks, and network devices, whereas others manage that hardware for you. Generally, power and network cabling are provided as a service, so you don’t have to manage them. Hypervisors that can virtualize physical resources maintain complete control over the virtualized infrastructure you provide and the workloads you run on that infrastructure.

You don’t have to manage the entire resource layer by yourself in a Public cloud environment. You can focus on the aspect of the layer that is most valuable to you. As far as private hosting environment goes, you don’t have to manage the necessary physical infrastructure. Additionally, you don’t need to manage the resource virtualization hypervisor. You can create a virtualized infrastructure and use your workload in this new infrastructure. You can also purchase fully managed services where you only care about your workload and hand over the operational load to manage runtime environments.
Once you have defined your start-up and target environments, you define the types of workload and related operational processes intended for relocation. This article talks about two types of workloads and functions: legacy and cloud-native.

Legacy workloads and functions are generated regardless of cloud environments. These workloads and functions are difficult to replace, and expensive to operate and maintain because they generally do not support any size measurement.

Cloud-native workloads and functions are natively scalable, compact, accessible, and secure. Workloads and functions can help increase developer’s productivity and agility because developers can focus on real workloads rather than trying to manage development and operating time environments, or dealing with complex manual deployment processes. Google also has a shared responsibility model for cloud security. While you are responsible for the security of the workloads you use for infrastructure, Google Cloud is responsible for the security of the body and the security of the infrastructure.

The migration process depends on your starting point.

Types of migration

There are three main types of migration:

• Lift and shift
• Improve and move
• Rip and replace

Lift and shift

In a lift and shift migration, you move workloads from the original environment to the target environment with little to no modification or rearrangement. The changes you apply to relocate workloads are the minimum changes you need to make to run workloads in the target environment.

A lift and shift migration are best when operating in a workload target environment, or when there is little or no business need for change. This displacement requires the least amount of time because the amount of restoration is kept to a minimum.

At times, technical issues may also force a lift and shift displacement. If you are unable to rearrange a workload to relocate and reduce the workload, you should use a lift and shift displacement. For example, changing the source code of the workload is difficult or impossible. The creation process is not straightforward, so it is not possible to create new artifacts after rearranging the source code.

Lift and shift migrations are easy because no new expertise is required, and your team can use the same tools and skills. These migrations support off-the-shelf software. Lift and shift migrations are faster compared to improve and move, or rip and replace migrations as you move existing workloads with minimal adjustment.

On the other hand, the results of a lift and shift migration are non-cloud native workloads running in the target environment. These workloads do not fully utilize the cloud operating system features such as horizontal scalability, fine-grained pricing, and highly managed services.

Improve and move

In Improve and move migration includes modernization as the workload moves. In this type of migration, you modify workloads to utilize cloud-native capabilities, not just to implement them in the new environment. Each workload can be upgraded for performance, features, cost, or user experience.

If the current configuration or infrastructure of the application is not supported in the target environment, a certain amount of restructuring is required to overcome these limitations.
Another reason for choosing the improve and move approach is that you need a major update to the workload in addition to the updates you need to relocate.

Improve and move migrations allow you to improve the features of the cloud platform, such as scaling your app and higher availability. You can configure the upgrade to increase portability of the application.

On the other hand, improve and move migrations take longer than lift and shift migrations because they have to be rearranged for utility migration. Additional time and effort should be evaluated as part of the life cycle of the application. You need to acquire new skills to improve and move migration.

Rip and replace

In rip and replace migration, you delete an existing application, redesign it, and rewrite it as a cloud-native application.

If the current application does not meet your goals — for example, you don’t want to maintain it, migration using one of the previously mentioned approaches is too expensive, or it is not supported in Google Cloud — you can go for rip and replace migration.

It allows your app to make full use of Google Cloud features such as migration, horizontal scaling, more managed services, and high availability. As you rewrite the app, you will also remove the technical debt of the existing legacy version.

However, rip and replace migration can take longer than lift and shift or improve and move migration. Also, this migration is not suitable for off-the-shelf applications because it requires rewriting the application. You will need to evaluate the extra time and effort required to redesign and rewrite the app as part of its life cycle.

New skills are needed for rip and replace. You need to use new tools to provide and configure the new environment and deploy the application in that environment.

Stay tuned for the Part -2 of the Article.