Integrating solution with existing systems
In this we learn and understand about integrating solution with existing systems.
However, when planning your migration to Google Cloud, you start by defining the environments that are involved in the migration. And, your starting point can be an on-premises environment, a private hosting environment, or another public cloud environment. Where:
- Firstly, an on-premises environment is an environment where you have full ownership and responsibility. You retain full control over every aspect of the environment, such as cooling, physical security, and hardware maintenance.
- Secondly, in a private hosting environment such as a colocation facility, you outsource part of the physical infrastructure and its management to an external party. However, this infrastructure is typically shared between customers. In a private hosting environment, you don’t have to manage the physical security and safety services.
- Lastly, a public cloud environment has the advantage that you don’t have to manage the whole resource stack by yourself. You can focus on the aspect of the stack that is most valuable to you. Like in a private hosting environment, you don’t have to manage the underlying physical infrastructure.
Types of migrations
There are three major types of migrations:
- Firstly, Lift and shift
- Secondly, Improve and move
- Lastly, Rip and replace
In the following sections, each type of migration is defined with examples of when to use each type.
Lift and shift
- In a lift and shift migration, you move workloads from a source environment to a target environment with minor or no modifications or refactoring. However, the modifications you apply to the workloads to migrate are only the minimum changes you need to make in order for the workloads to operate in the target environment.
- Secondly, a lift and shift migration is ideal when a workload can operate as-is in the target environment, or when there is little or no business need for change. However, there might be technical issues that force a lift and shift migration. If you cannot refactor a workload to migrate and cannot decommission the workload, you must use a lift and shift migration.
- Lastly, Lift and shift migrations are the easiest to perform because there is no need for new expertise and your team can use the same set of tools and skills. These migrations also support off-the-shelf software.
Improve and move
- In an improve and move migration, you modernize the workload while migrating it. However, in this you modify the workloads to take advantage of cloud-native capabilities. And, you can improve each workload for performance, features, cost, or user experience.
- Secondly, if the current architecture or infrastructure of an app isn’t supported in the target environment as it is, a certain amount of refactoring is necessary to overcome these limits.
- Another reason to choose the improve and move approach is when a major update to the workload is necessary in addition to the updates you need to make to migrate.
- Lastly, improve and move migrations let your app leverage features of a cloud platform, such as scalability and high availability. You can also architect the improvement to increase the portability of the app.
Rip and replace
- Firstly, in a rip and replace migration, you decommission an existing app and completely redesign and rewrite it as a cloud-native app.
- Secondly, rip and replace migrations let your app take full advantage of Google Cloud features, such as horizontal scalability, highly managed services, and high availability. However, rip and replace migrations can take longer than lift and shift or improve and move migrations. Moreover, this type of migration isn’t suitable for off-the-shelf apps because it requires rewriting the app.
- Lastly, a rip and replace migration also requires new skills. You need to use new toolchains to provision and configure the new environment and to deploy the app in that environment.
The migration path
It’s important to remember that a migration is a journey. However, there are four phases of your migration:
- Firstly, Assess. In this phase, you perform a thorough assessment and discovery of your existing environment in order to understand your app and environment inventory, identify app dependencies and requirements.
- Secondly, Plan. In this phase, you create the basic cloud infrastructure for your workloads to live in and plan how you will move apps.
- Thirdly, Deploy. In this phase, you design, implement and execute a deployment process to move workloads to Google Cloud.
- Lastly, Optimize. In this phase, you begin to take full advantage of cloud-native technologies and capabilities to expand your business’s potential to things such as performance, scalability, disaster recovery, costs, training.
Migration phase 1: assess
In the assessment phase, you gather information about the workloads you want to migrate and their current runtime environment.
Take inventory
A key to a successful migration is understanding what apps exist in your current environment–what databases, message brokers, data warehouses, and network appliances exist–and the apps dependencies for each of them. Moreover, you need to list all of your machines, hardware specifications, operating systems, licenses, and which of the apps and services are used by each of them.
Catalog apps
After you take your inventory, you can build your catalog matrix to help you organize your apps into categories based on their complexity and risk in moving to Google Cloud.
Educate your organization about Google Cloud
As part of the assess phase, your organization needs to start learning about Google Cloud. However, you need to train and certify your software and network engineers on how the cloud works and what Google Cloud products they can leverage.
Experiment and design proofs of concept
Another important part of the assessment phase is choosing a proof of concept (PoC) and implementing it, or experimenting with Google Cloud products to validate use cases or any areas of uncertainty.
Migration phase 2: plan
In this phase, you provision and configure the cloud infrastructure and services that will support your workloads on Google Cloud. Building a foundation of critical configurations and services is an evolving process. However, when you establish your rules, governance, and settings, make sure you allow room for changes later. Avoid making decisions that lock you in to a way of doing things.
However, to plan for your migration, you need to do the following:
- Firstly, establish user and service identities.
- Secondly, design your resource organization.
- Thirdly, define groups and roles for resource access.
- Lastly, design your network topology and establish connectivity.
Establish identities
In Google Cloud, you have identity types to choose from:
- Firstly, Google Accounts. An account that usually belongs to an individual user that interacts with Google Cloud.
- Secondly, Service accounts. An account that usually belongs to an app or a service, rather than to a user.
- Thirdly, Google groups. A named collection of Google accounts.
- Then, Google Workspace domains. A virtual group of all the Google accounts that have been created in an organization’s Google Workspace account.
- Lastly, Cloud Identity domains. These domains are like Google Workspace domains, but they don’t have access to Google Workspace applications.
Design resource organization
After establishing the identities you need for your app, you grant them permissions on resources, such as project, folders, or buckets, that your app uses. You can do this by assigning roles to each identity. However, a role is a collection of permissions. A permission is a collection of operations that are allowed on a resource.
Further, to avoid repeating the same configuration steps, you can organize your resources in different types of structures. These structures are organized in a hierarchy:
- Firstly, organizations are the root of a resource hierarchy and represent a real organization, such as a company. An organization can contain folders and projects.
- Secondly, folders are an additional layer of isolation between projects and can be seen as sub-organizations in the organization. A folder can contain other folders and projects.
- Lastly, projects are the base-level organization entities and must be used to access other Google Cloud resources. Every resource instance you deploy and use is contained in a project.
Migration phase 3: deploy
After building a foundation for your Google Cloud environment, you can begin to deploy your workloads. You can implement a deployment process and refine it during the migration. However, you might need to revisit the foundation of your environment as you progress with the migration. New needs can arise as you become more proficient with the new cloud environment, platforms, services, and tools.
Further, when designing the deployment process for your workloads, you should take into account how much automation and flexibility you need. There are multiple deployment process types for you to choose, ranging from a fully manual process to a streamlined, fully automated one.
Fully manual deployments
A fully manual provisioning, configuration, and deployment lets you quickly experiment with the platform and the tools, but it’s also error prone, often not documented, and not repeatable. However, for these reasons, we recommend that you avoid a fully manual deployment unless you have no other option.
Configuration management tools
A configuration management (CM) tool lets you configure an environment in an automated, repeatable, and controlled way. You can use a CM tool to configure the environment and to deploy your workloads. Further, some CM tools let you implement your own deployment logic and can mimic those missing features. However, using a CM tool as a deployment tool can add complexity to your deploy process, and can be more difficult to manage and maintain than a dedicated deployment toolchain.
Container orchestration
If you have already invested in containerization, you can go a step further and use a service such as Google Kubernetes Engine (GKE) to orchestrate your workloads. However, by using Kubernetes to orchestrate your containers, you don’t have to worry about the underlying infrastructure and the deployment logic.
Deployment automation
By implementing an automated artifact production and deployment process, such as a continuous integration and continuous delivery (CI/CD) pipeline, you can automate the creation and deployment of artifacts. Moreover, you can fully automate this process, and you can even insert manual approval steps, if needed.
Reference: Google Documentation