Team assessment/skills readiness

In this tutorial we will learn and understand about Team assessment/skills readiness.

Assess

However, the assessment phase is the first phase in your migration to Google Cloud where you determine the requirements and dependencies to migrate your apps to Google Cloud. The assessment phase is crucial for the success of your migration. But, you need to gain deep knowledge about the apps you want to migrate, their requirements, their dependencies, and your current environment. Also, you need to understand your starting point to successfully plan and execute a Google Cloud migration.

Building an inventory of your apps

Building the inventory is a non-trivial task that requires a significant effort, especially when you don’t have any automatic cataloging system in place. However, to have a comprehensive inventory, you need to use the expertise of the teams. These teams are responsible for the design, deployment, and operation of each workload in your current environment.

The inventory shouldn’t be limited to apps only, but should at least contain the following:

Firstly, dependencies of each app, such as databases, message brokers, configuration storage systems, and other components.
Secondly, services supporting your app infrastructures, such as source repositories, continuous integration (CI) tools, and artifact repositories.
Thirdly, servers, either virtual or physical.
Lastly, physical appliances, such as network devices, firewalls, and other dedicated hardware.

When compiling this list, you should also gather information about each item, including:

Firstly, source code location and if you’re able to modify this source code.
Secondly, the deployment method for the workload in a runtime environment. For example, if you use an automated deployment pipeline or a manual one.
Thirdly, network restrictions or security requirements.
Lastly, licensing requirements for any software or hardware.

Categorizing your apps

After you complete the inventory, you need to organize your apps into different categories. This categorization can help you prioritize the apps to migrate according to their complexity and risk in moving to the cloud.

However, a catalog matrix should have one dimension for each assessment criterion you’re considering in your environment. Choose a set of criteria that covers all the requirements of your environment, including the system resources each app needs.
Also, next to each app you should add a migration complexity indicator. This indicator estimates the difficulty rating to migrate to each app. The granularity of this indicator depends on your environment. For a basic example, you might have three categories: easy to migrate, hard to migrate, or cannot be migrated. Further, to complete this activity, you need experts for each item in the inventory to estimate its migration complexity.
Lastly, when the catalog is complete, you can also build visuals and graphs to help you and your team to quickly evaluate metrics of interest. For example, draw a graph that highlights how many components have dependencies or highlight the migration difficulty of each component.

Experimenting and designing proofs of concept

To show the value and efficacy of Google Cloud. then, consider designing and developing one or more proofs of concept (PoCs) for each category of the app in your app catalog. Experimentation and testing let you validate assumptions and demonstrate the value of the cloud to business leaders.

At a minimum, your PoC should include the following:

Firstly, a comprehensive list of the use cases that your apps support, including uncommon ones and corner cases.
Secondly, all the requirements for each use case, such as performance and scalability requirements, expected consistency guarantees, failover mechanisms, and network requirements.
Thirdly, a potential list of technologies and products that you want to investigate and test.

Calculating total cost of ownership

When you have a clear view of the resources you need in the new environment, you can build a total cost of ownership model that lets you compare your costs on Google Cloud with the costs of your current environment. Further, when building this cost model, you should consider not only the costs for hardware and software but also all the operational costs of running your own data centers.

However, a commonly overlooked cost when considering cloud migrations is the use of a cloud network. In a data center, purchasing network infrastructures, such as routers and switches. Then, running appropriate network cabling are one-time costs that let you use the entire capacity of the network. In a cloud environment, there are many ways that you might be billed for network utilization. For data intensive apps or those that generate a large amount of network traffic. Then, you might need to consider new architectures and network flow to lower networking costs in the cloud.

Choosing the apps to migrate first

The apps you migrate first are the ones that let your teams build their knowledge and experience on Google Cloud. Greater cloud exposure and experience from your team can lower the risk of complications during the migration phase of your migration, and make subsequent migrations easier and quicker. For this reason, choosing the right first-movers is crucial for a successful migration. You can pick one app, or put many apps from across your apps matrix in your first-mover list.

Business value

Choosing an app that isn’t business-critical protects your main line of business, and decreases the impact on business from undiscovered risks and mistakes while your team is learning cloud technologies. For example, if you choose the component where the main financial transactions logic of your eCommerce app is implemented as a first-mover, any mistake during the migration might cause an impact on your main line of business. A better choice is the SQL database supporting your apps, or better yet, the staging database.

Edge cases

You should also avoid edge cases, so you can discover patterns that you can apply to other apps to migrate. A primary goal when selecting a first mover is to gain experience with common patterns in your organization so you can build a knowledge base. For example, if most of your apps are designed following a test-driven development methodology and are developed using the Python programming language. Then, choosing an app with little test coverage and developed using the Java programming language. As it doesn’t let you discover any pattern that you can apply when migrating the Python apps.

Teams

When choosing your first-movers, pay attention to the teams responsible for each app. The team responsible for a first-mover should be highly motivated, and eager to try Google Cloud and its services. Moreover, business leaders should have clear goals for the first-mover teams and actively work to sponsor and support them through the process. For example, a high performing team that sits in the main office with a proven history of implementing modern development practices such as DevOps and disciplines such as site reliability engineering can be a good candidate.

Dependencies

Also, you should focus on apps that have the fewest number of dependencies, either from other apps or services. The migration of an app with no dependencies is easier when you have limited experience with Google Cloud. However, if you have to choose apps that have dependencies on other components. Then, pick the ones that are loosely coupled to their dependencies. Further, if an app is already designed for the eventual unavailability of its dependencies. Then, it can reduce the friction when migrating the app to the target environment. For example, loosely coupled candidates are apps that communicate by using a message broker, or that work offline. Or that are designed to tolerate the unavailability of the rest of the infrastructure.

Refactoring effort

A first-mover should require a minimal amount of refactoring, so you can focus on the migration itself and on Google Cloud, instead of spending a large effort on changes to the code and configuration of your apps. The refactoring should focus on the necessary changes that allow your apps to run in the target environment instead of focusing on modernizing and optimizing your apps. That further gets a tackle in later migration phases.

For example, an app that requires only configuration changes is a good first-mover, because you don’t have to implement any change to codebase, and you can use the existing artifacts.

Licensing and compliance

Licenses also play a role in choosing the first-movers, because some of your apps might be licensed under terms that affect your migration. For example, some licenses explicitly forbid running apps in a cloud environment.

When examining the licensing terms, don’t forget the compliance requirements because you might have sole tenancy requirements for some of your apps. For these reasons, you should choose apps that have the least amount of licensing and compliance restrictions as first-movers.