HOST: Migrating to cloud can be intimidating with a ton
of things to worry about.
How can you build a solid foundation
for a seamless migration?
Well, keep watching to find out.
[MUSIC PLAYING]
Welcome to Cloud Migration 101, where we share migration tips
and tricks.
When planning your migration to Google Cloud,
you need to understand some concepts related
to cloud architecture.
A poorly-planned foundation can cause your business
to face delays, confusion, downtime,
and can put the success of your cloud migration at risk.
But today's episode, I have brought a friend
from Solutions Architect Team who
will walk us through building our cloud foundations.
Grasp as much as you can, and I'll see you on the other side.
TRAVIS: Hi, I'm Travis.
When migrating from an on-premises environment or colo
managed data center to the cloud,
there are many things to consider
from the IT, engineering, and business perspectives.
Today, let's cover the topics that an IT
manager needs to think about when migrating to Google Cloud.
There are a few questions you want to ask yourself.
First, how do your existing business
and organizational structures map to Google Cloud?
Second, who from your team will control, administer, and audit
access to Google Cloud resources?
Third, what are best practices for managing multiple teams
working simultaneously on multiple Google Cloud projects?
Let's start with the first question.
How do you model your existing business and organizational
structures in Google Cloud?
You'll want to map your existing lines
of reporting and communication to your resource hierarchy.
The resource hierarchy provides structure
to your cloud environment, determines
the way you are billed, and establishes a security model
for granting roles and permissions.
It's like the skeleton for all your cloud resources.
For example, a Compute Engine VM is a resource
which falls within a project and folder, and all of these
are contained within an organization.
Now, how do you control access to cloud resources?
Once the resource hierarchy is in place,
you can apply security permissions
at each of these levels.
These permissions are then inherited by any child objects
in the hierarchy.
For example, if you get full admin privileges
on Department Y's folder, you will
have full admin privileges on all of the projects
and resources below it.
These hierarchies can be as complex or as simple
as your organization requires.
A member is who or what you want to give permission to.
A role is a collection of specific permissions
to determine what operations can be performed on a resource.
And a policy binds one or more members to a particular role.
Once you have a policy, you'll be
able to clearly define who can do what on what resources.
As a simple equation, members plus roles equals policy.
Let's take a specific example.
An enterprise wants to create a policy for controlling access
to all of their virtual machines.
They might use Instance Admin and App Engine Admin roles.
Then they can create a Google group
for the Ops Team that will manage the instances.
And the policy would link the members and the roles together.
They could then create a read-only policy,
including Log Viewer and Instance Viewer
roles for their support team members
and, perhaps, a policy with the Pub/Sub Publisher
role for the service account of one of their microservices.
That would be three separate policies.
That's the relationship between IAM
and the resources, projects, and folders.
Now, once you have the resources in Google Cloud,
the question comes, how do your teams actually
interact with them?
There are four ways to interact with Google Cloud Services,
and your IAM permissions will control what
you can do with all of them.
First, we have the cloud console, the graphical user
interface that lets you interact with Google
Cloud within your browser.
Second, we have the cloud APIs that
provide programmatic interfaces for interacting
with Google Cloud from your application code.
Third, the cloud SDK, which is a developer-friendly software
library that enables your applications to interact
with Cloud APIs.
And lastly, we have the G Cloud command-line tool
that lets you make calls to the cloud API
directly from your command line.
HOST: That was great, Travis.
Thank you.
TRAVIS: Thanks.
You take it from here.
HOST: I got it.
Well, today, we learned about resource hierarchies,
access control, permissions, using IAM,
and the four methods of interacting with Google Cloud
Services.
Want more details?
Check out the entire guide linked below,
and stay tuned for the next episode where
we will talk about building a landing zone
and running your workloads in cloud.
In the meantime, give us a like and subscribe to NeverMiss
Google Cloud Migration Tips.
[MUSIC PLAYING]