MAX SACK: My name is Max. This is my colleague Greg. And we are both program managers
on our billing support team. So what do we have in
store for this session? Well, we'll start
with an overview of resource organization
and access management. We'll talk about what that
is, why it's important, what resources are involved,
and how those resources relate to one another. We'll then spend some
time taking a look at each resource in a
little bit more detail, as well as the
key roles that are necessary to manage
those resources, and share some of those
key configuration best practices to think about when
you're actually setting those up. We'll then take a
little bit of time and look at an example
of how the organization of those resources as well
as the role assignments will evolve over time for
an organization that's growing in size. And then we'll wrap up. We don't have a ton of time
to talk to you all today and cover this content in a
detail that we would like. And so, we're going to point you
to some key documentation that will go into a lot more
detail, a lot more depth, that you guys can use with
your teams after the fact, and actually step by step
go through this process when you're configuring
your accounts. Resource Organization
and Access Management. It's a bit of a mouthful. So we're just going to
refer to this as resource management for simplicity. OK, resource management--
what is this? In the context of
cloud, the term resource is thrown around a lot. You've probably heard it
here at the conference. We felt it would be pretty
helpful to define what we mean by resource and
resource management, first by talking about
what we don't mean. In the context of GCP when
people hear the term resource, they often think of
those service resources that are used to
process your workloads-- your VMs, your databases, all
of the underlying products and services that you
consume using GCP. But that's not really
what we're talking about. When we talk about
resource management, we're talking about
the resources that sit above those services,
the ones that are involved and actually managing and
configuring your accounts, such as those you see here. Now, I want to note that
we're not explicitly talking about or looking
at these resources through the lens
of cost management, such as how you can or
should be organizing your various resources,
your projects, your folders, your labels, for purposes of
separating out and tracking your various cost
considerations. That's a super
important topic, and one that's really well-covered
by our colleague James and his session on
resource organization for cost management, which
he gave yesterday. So if you didn't get a
chance to check that one out, that's totally fine. That session and
all the other ones will be available on
YouTube after Next. And we highly encourage
you to check that one out, because it's actually a
really nice compliment to what we want to cover here. Our purposes in this
session are to give you some prescriptive guidance
on how you should be thinking about these resources and
the roles that are associated with them so that you can
configure account and maintain good account hygiene. That's really our purpose here. So why is this important? Not configuring an
account correctly can lead to some really
common and problematic states that impact your team's
ability to use GCP. You may be wondering, why are
we up here from the support team talking to you about
account configuration and resource setup? The reason for that is, when
customers don't do those things correctly, it often impacts
their billing, their invoicing, their payments, and they reach
out to the billing support team for help. So we're really well positioned
to see all the different ways that this can go wrong based
on the upstream decisions that our customers are making. So we thought we
were in a good place to provide some of this guidance
and sort of fill in those gaps when you are making those
decisions to sort of guide you through that. It's pretty telling here
actually that about a third of all the customer cases,
the customer inquiries coming into the billing support
team, are related in some way to resource management. So it's super common, affects
really large customers and really small
customers as well. What's at stake? What happens if you
don't do this correctly? What can actually go wrong? These problems with
resource management can manifest in
a number of ways, ranging from an inability
to retrieve information from your accounts, to changing
settings on your resources, billing accounts,
projects, to losing access to those resources completely,
all the way up to disruption of service and termination
of your account, which unfortunately
has actually happened. Oftentimes, though, it's some
combination of these things. It's a garbled mess of
problems sort of stacked on top of each other,
and to fix them requires sort of untangling
this ball of yarn. So we thought the
best way to address these issues was to help you
avoid them to begin with. All right. Let's zoom out a little bit and
take a look at these resources and how they relate to
each other in this resource hierarchy. Starting at the top
in the red boxes, we have the domain
and the organization. These things collectively
create this sort of umbrella that lets you more
easily manage your users as well as your resources
within the organization. In the green box, we
have the billing account, which is responsible for
tracking all of your charges that you're accruing as
you use GCP services, and helps define how you pay for
those services in combination with the payment profile, which
is the yellow box over there on the left. Uniquely, the payment profile
is not a cloud-level resource. It sits outside of that
resource hierarchy, and it is responsible
for, among other things, holding and actually containing
your payment instrument. So if you use a credit
card or debit card, that would reside within
your payment profile. Lastly, we have the blue boxes-- projects, folders, and labels. And collectively, you
can think of these things as this flexible
mechanism that helps you manage not only your
cost, but also your access to the various
underlying services that you're going to be using. All right. So let's dig into these
a little bit more. I want to start by noting
each of your teams, each of your companies, is going
to have various considerations when you're setting
up your account and setting up these resources--
business considerations, financial, legal,
organizational. That's totally fine. Those things are going to
influence the way that you actually know the decisions
you make when you're actually configuring and
setting this stuff up. What we want to focus
on is providing you with some common best
practices and a general order of operations that you
should be thinking about when you configure these resources. Everyone's is going
to look different, but there are some
common things that we want to encourage you to do. In this section, we'll
introduce each resource, we'll talk about what of those
key configuration details and best practices
are, and we will introduce the core
roles that are necessary to manage each one. So let's start with
domains and organizations. Like we said,
together these create this umbrella under which
all of your cloud resources are nested, helps you manage
those resources and your users. These things are different,
domains and orgs, but they map on a
one-to-one basis. So you can sort of
think about them as two sides of the same coin. A good way to conceptually
break these out is think about domain as the
mechanism to manage your users, and the organization
is the mechanism to manage your resources as well
as the access to the resources. Starting with domains-- in the
same way that your web domain sort of names your website, your
domain in the context of cloud names your organization,
and it's at this level that you can define
that directory of users you have within
your organization. You can enforce a
universal policy across those users such as
two factor authentication, and you can even help
your users recover access to their accounts
if they lose access and they need to reset
their password, for example. All that stuff can be managed
within the Google Admin Console. When you create a domain,
that will automatically create your organization,
like I said, one-to-one. We'll talk about how
to do that in a moment. On the organization
side, you can think about this as that root
node in your GCP hierarchy. It's by virtue of
this that you have control over all of those
subordinate resources that sit underneath the org. This is really important
for a couple of reasons. The first one is
proactive management. So if your company is
expanding, if you're going to acquire
another company, if you're going to
spin up a new division, if you didn't have
an organization, you would have to individually
communicate and coordinate between all of the
individual resource owners to achieve some larger vision. If you had an organization,
it makes that really easy because you can
sort of quarterback those changes from
a central point, and that goes really quickly. The second reason
it's really important is for reactive management. If you have a really important
project that you're working on and only a single employee,
key employee, that's managing that project,
and they win the lottery and never come into work
again, you're out of luck if you don't have
an organization. You have to get in
touch with them, sort of beg them to add
somebody else to the project. It's kind of a mess. If you have an organization,
it sort of functions as an insurance policy. It allows you to really
easily go back in there and assign that project to
another person on your team. All this stuff with
the organization is related to your
GCP resources. So logically you can control
that using the GCP console. So how do we create this? How should we think about
sort of setting this stuff up? The first best practice
that we have for you all is to use a domain
and an organization. It's completely voluntary. There's no forcing
you to actually use one of these things. So we want encourage
you to use it. There's not really a
good reason not to based on what we just discussed. So to set up a domain
and an organization, you'll start by
creating the domain. You have a couple
options to do this. You can use G Suite or you
can use Cloud Identity. We won't go into the
details of these, but you have a couple options. They're just great. One of them is free. Once you've set that
up, the next step will be to provision your users,
and you have a couple options here as well. You can do this individually
at the Google Admin console, or you can use a tool,
which we would suggest if you have a large user
base already, Cloud Directory Sync, if you want to
import a bunch of users and provisioned them em masse. Once you've set that
up, you'll sort of shift focus over to the organization. Like we said, when you
create your domain, it will automatically
create your organization. So you'll shift over to that
GCP console and you will migrate any projects that
you've been using if you've happened
to be using GCP prior to setting up your work-- project and billing. Here again, if you have a
large number of resources that you're going
to be migrating, we highly suggest you use
the organization setup wizard to streamline that process. OK, lastly-- so at this
point, you have your domain, you'll have your org, you have
users, you have your resources. Now you're going to sort of
connect the dots and grant permissions for those
resources to those users. And here, we want to call this
out, really important tip-- by default leave
the billing account creator roles on
your organization for everyone within it. We want to strongly
encourage you to remove that, to turn that off. And the reason for
that is it will lead to a proliferation
of billing accounts if you don't do that, and it
becomes really problematic, and you see a lot of different
ways that this goes wrong. There's not really a good
reason to have that turned on. You want to restrict
the access to who is able to create billing
accounts because of all the tie-ins to other resources,
like payment profiles, which we'll discuss in a moment,
and it's best to sort of just get ahead of that and remove it. So what are the
key roles involved in setting up and managing
your domain and organization? On the domain side we
have the super admin. This person has the
ability to administer that directory of users. They are the person that
will recover accounts, and if your users lose
access and get locked out, they can reset those passwords. They can also enforce that sort
of domain-wide policy like 2FA, and they can grant the
org admin privilege. On the other side
with the organization, you have the org admin. This person has the
ability to administer all of those resources. They're also the individual
that will do that migration if that becomes necessary. And it's worth noting that
by default, the first domain super admin, the person that
actually sets up the domain, will also be the
first org admin. And a couple of notes on who
typically fills these roles within an organization, it can
be very different depending on the size your organization. When you're first
starting out, very common had the same individual across
both of these roles, someone that has IT responsibilities
for your team, for your company. As organizations get
larger, typically we see org admins sort
of peel off from that, and might be someone
more directly involved in the use of cloud
services at your company. Could be a CTO, head of
product, head of engineering, something like that. Quick note on roles. This applies not
only to the roles we just discussed, but
also the ones that we're going to discuss for
the other resources. Avoid single points of
failure, like that situation we just talked about with the
employee that wins the lotto and never comes back. It's a good idea to assign
multiple individuals to these key roles, especially
administrator roles, in practice what we're
calling reasonable redundancy. That's half the battle. You also want to make sure that
every other individual, all the other people
on your team, know who those administrators
are, because they oftentimes have special privileges
and permissions and access within your
company and within GCP. And so, they sort of function
as its first line of defense when problems come up, and
they can help troubleshoot. So it's really important. We see this all the time
in larger organizations. People don't know who
the billing admin is. People don't know
who the org admin is. And they're coming
to support, and it creates this sort
of telephone game, and it gets pretty complicated. And then, lastly, we know
we know teams change, we know companies evolve, people
leave, and people come in. And so, sort of kick the tires
on this rolls and permissions list every six months,
or every quarter even, to make sure it's up to date. All right, billing accounts-- So as we said before,
the billing account is responsible for containing
all of your charges, tracking all of your charges
from the usage of your GCP services. And it's all those charges that
hit that billing account that ultimately make its
way onto your invoice. So there is one invoice
for every billing account that you have. The billing account also
is responsible for defining how you will pay for that
invoice in combination with the payment profile,
which we'll discuss shortly. And like all of the other
resources we're talking about, has its own roles
and permissions. And that's kind of
the core reason, one of the core reasons, why
things get really dicey when setting this stuff up. Because if you're doing it in a
silo in a way that's not really paying attention to
how you're configuring your other resources
and who you're putting in those key roles, it
creates a lot of confusion within customers' companies. Also important to note here
that billing accounts can only operate in a single currency
per billing account. So how should you configure
a billing account? The first step is to decide how
many billing accounts you need. And this is kind
of a trick point, because we want to strongly
encourage you to have only a single billing account. That will be appropriate for the
vast majority of our customers, and probably most the
folks in this room. We see oftentimes customers will
use multiple billing accounts as sort of a hack
for cost management if they want to
separate out costs. But we have other
great resources like projects,
folders, and labels, that we should really be
relying on for the heavy lifting for all of our cost
management practices, and let billing accounts kind
of just be billing accounts. There are a couple
situations where it does make sense to have
multiple billing accounts. If you operate separate
legal entities, if you operate in
different geographies and different currencies, in
those cases it will make sense and you will need to have
separate billing counts. But otherwise keep it to one. The reason for that,
again, with a proliferation of billing accounts, it
creates a lot of overhead to make sure that you're
tracking things correctly, that you have permission
syncs correctly, if you have preferential pricing
it creates a lot of problems. So we strongly suggest
keep it to one. All right. So first step is deciding
how many you need, but also making sure
that it's just one. The second step is defining and
creating that billing account. So if you've already
been using GCP, you can choose the one that's
going to be the primary one. If you haven't pre-set
up your main one, call that your primary. At this point, we want to call
out as well turn on or enable BigQuery billing
export on day one when you create your
billing account. You can't do this retroactively. And so, to make sure that you
have as much data as possible you have access to,
it's always a good idea to turn it on as soon as
you've created the account. Next, you're going to migrate
any resources, any projects specifically, over to this
billing account that you may have been using previously. And then lastly, you're going
to settle any final balances you have on older billing accounts
you are no longer planning on using and close them down. We've seen this
quite a bit where a customer will
have a stray billing account with a single
project attached to it, a little bit of usage, and
the credit card associated with that one sort
of lapses and then it creates account
closure protocols, and that has a domino effect. It ends up affecting their
other live billing accounts. And so, it's really best
to just shut those down if you have any
extra ones, and just focus on that primary
billing account. All right. Key roles in managing
your billing account-- So the billing
account administrator is going to be the
primary role here. This person has the ability
to manage those payment instruments. They can enable BigQuery export,
like we just talked about as the best practice. They can view costs. They can also setup cost
reports or budget alerts, which are great cost
management tools that you should be taking advantage of. They can link projects,
unlink projects, and manage all of
the other users and permissions are related
to that billing account. Really important here
like we talked about-- certain administrators
of certain resources have special
privileges and rights. And so, for the billion count
specifically, we require-- we as in the building
support team-- require any individuals
reaching out to us to ask about a billing
account, that that person be a billing account administrator
on that particular account. The reason for that is to
protect our customer's privacy. We don't want to
disclose any information to an individual that
wouldn't otherwise have access to that information. So again, make sure that
you have multiple billing administrators, and
also let everyone know who those people are. If they have a
question about billing, they're going to need to
funnel that through the billing administrator. We have another role up here. And there's more
than just these two, but we thought these were
probably the most relevant. The billing account
user-- this person, a lot more limited in scope. They can basically view costs
for the billing account, and they can link projects
into the billing account, but they can't unlink them. So this role's often
granted in tandem with a project creator role. So it gives the individual the
ability to create a project and then fund that project
by connecting it back into the billing account. Oftentimes, people
in organizations that we see filling the billing
account administrator role are folks that are working
in finance and accounting, or oftentimes people that
have PNL responsibility for a particular product line. So it could be someone
in product management. All right. And with that, I'm going
to pass things over to my colleague Greg,
who's going to talk to us about payment profiles. GREG GULLEN: All right. So thank you, Max. So once again, my
name is Greg Gullen, and I'm a program manager
on the billing support team. So before we even talking
about payments profiles, just a quick show of
hands, how many of you have actually heard of
this resource before? Just a quick show of hands. What about the Google
Payment Center? Literally, I think I
see like three hands. So this is great. This is great, because
as you can see, the payments profile sits
outside of your GCP resources. And you need to understand
why this is important, because there is a huge
connection between the payments profile and the billing account. We'll talk about
why it's important and why you should
take note of it. So the payments
profile is actually managed in a completely
different console. It's not managed
in the GCP console. If you go to
Payments.Google.com, you will actually see what
the Payment Center looks like. I want to include a screenshot
because I want you all to be very well aware that the
payments profile permissions and notifications are
handled completely outside the GCP console. There is some sections that are
iframed into the GCP console, chaining certain
email preferences, but however, the
majority of settings should be handled that
Payments.Google.com. So the payments profile is
a Google-level resource, and what that means is that
you utilize the payments profile to pay for your Google
services beyond just GCP. So you can use your
payments profile to pay for things like AdWords,
GCP, Chrome, Google Play. As it's a Google-level
resource, you are able to manage
different payment methods within that payment profile. So if you're an
online customer, you can manage things such as debit
cards, credit cards, or bank account information. Within the Payment
Center, think of it as a holistic location to
view a lot of your invoices and documents. There's an actual section
called the document center where you can see credit
memos, debit memos, and master agreements. But the thing to take away
from the payments profile is that it is managed completely
separate outside of your GCP console, and I think
a lot of customers are not aware of this. So we'll talk about
the implications of what it means to
configure your payments profile correctly,
and how it can be successful for
your organization. So when you're thinking
about the payments profile, think of these four steps to
follow our best practices. Step one-- create a
business payments profile. A business payments
profile allows you to go ahead and enter
your tax information. We are assuming that
your organization is a business is treated
as a separate legal entity. If you were to create an
individual payments profile, you would not have
that functionality. But most importantly is that
the business payments profile allows you to manage a lot
of the permissions and email notifications for all of
your users in your company. That doesn't happen with the
individual payments profile. We recommend that you limit
it to one, if possible. Very similar to
billing accounts, what we've seen in billing
support is that whenever customers create multiple
payments profiles and they call in to
GCP support, it's very hard to diagnose
where the issue lies, in which payment profile, in
which billing account could be the root or
could allow access to troubleshoot that issue. So we recommend limit to one. There are different
scenarios where you would have multiple
payments profiles, and we'll walk through
those scenarios later on in the presentation. Step two-- setup your payments
profile administrator. Now, we recommend that you
mirror this payments profile administrator to be
your billing account administrator, the exact
same permissions if possible, for the reason that I stated. It's that if you call in two
billing support today, one of the ways that we
authenticate and verify you is that we ask you if
you are the billing account administrator. Now, if the issue does lie
with the payments profile, it's always best to
ensure that you're the administrator of
both of those resources so we can troubleshoot
the issue from end to end. Step three-- configure users
to receive invoices and account notifications. We can't stress enough
how many times we've seen fire drills
for customers where you've got someone
in accounts payable and you have someone
in engineering, and they're receiving different
types of notifications based on the account. And when that happens,
there's fire drills within organizations
as to why is my bill not being paid, what's
going on, how come I can't access these resources. So ensure that
everybody is receiving the right level
of notifications, and more importantly,
can pay the bill. Step four-- add a
secondary payment method. So we've seen historically
that credit cards for online accounts,
credit cards expire. Individuals leave
organizations, and in doing so, sometimes your GCP
resources do not get paid. So we recommend please add
a secondary payment method. So if the first one
fails you have a backup. For offline accounts, also known
as terms or invoice accounts, we recommend that you have
a secondary individual setup as a payments profile
administrator. And not only that, but
you also take a look, log into the center, and you
can actually assign individuals within your organization,
such as finance, accounting, to just receive
the invoice itself. We recommend that you review
this every six months. It's just good hygiene to have. Like I said, we
understand that people go on and do great things
and leave organizations. So please just make sure this
information is kept up to date. So the payments profile
has two important roles you should take note of. One is the payments
provide administrator. This individual has the
keys to the kingdom. This individual can go ahead
and change the actual business name, the legal address,
different payment methods, change the entire
notifications for everyone receiving invoice information. So it's important
that this individual within the
organization is someone who usually has senior level
visibility into not only what your organization is interacting
with Google from a GCP perspective, but across
our entire portfolio of different products, like
ads, or Google Play, or Chrome. Now, if you don't want to
give full access to a user, we understand that. You have the option of
the read only access. Now the read only access,
as the name implies, is just for someone who just
needs to see the invoices, just needs to see the
transaction history. Historically, what we've
seen is that an individual with this role will be someone
in accounting, finance, or accounts payable. All right. So switching gears to
projects, folders, and labels. So as Max had mentioned before,
projects, folders, and labels are really a flexible mechanism
to help you with your cost management needs. If they're structured correctly,
they help you answer questions such as, how am I spending
my GCP resources today, or where can I
shift my resources to get the most use out of GCP. So projects,
folders, and labels. Projects-- if you
had to think of them, think of them as a bucket. In this bucket it stores a lot
of service-level resources. And these
service-level resources could be things
such as Kubernetes, compute, storage, and so on. Now, on top of those
projects, you have folders, and the folders allow you
to organize your resources in a logical way. What we've seen companies
utilize in a structure perspective is, you can
structure your folders to mean things such
as environments-- so your staging environment,
your production environment-- or you can even
structure them to be actual teams-- so your
engineering team, your support team, et cetera. Labels, on the other hand, are
great for being able to track your costs across GCP. If applied correctly,
they'll allow you to answer a lot of
your fundamental questions as to how much is application
A spending from a maintenance perspective or from a
development perspective. So we encourage
you to use labels. So when setting up
these resources, we recommend these four things. One is organize your
folders and projects to mirror your organization. We can't stress enough-- please
use a naming convention that works for your organization. While I personally think naming
a project CoolRider87 makes sense, someone in
finance might not be able to tie that purchase
order to that invoice and might not be able to
make sense of that project. So use something that makes
sense for your organization. Step two-- protect projects
that are mission critical. We appreciate that all of you
have placed a lot of trust onto GCP to run your
mission critical projects. In order to respect that, we've
created a functionality called placing a lien on a project. When you place a
lien on a project, it prevents it from
accidental deletion. This can be done
through an API call, or it could even be done
through a command line tool. Step three-- add labels for
more granular cost management. Now, as we said before,
if you apply labels at the right level
of resources, you can answer some of your
most basic questions. You can even answer as to how
much are my database costs-- how much am I incurring
from a database cost perspective across
all my projects, or specific to just one project? When creating these resources,
these GCP resources, we recommend that through the
workflow you actually-- there's a section where you can add
a label to that resource early on. Now, if you already have your
hierarchy set up, that's OK. You can actually retroactively
go back and apply those labels to those resources. Step four-- assign appropriate
roles for folders and projects. We recommend that you use Cloud
Identity and Access Management, also known as Cloud IAM. So Cloud IAM allows
you to centrally manage all of these permissions
and identities and roles all at once. As an administrator
it's very difficult to be applying and
removing permissions per each individual. But with Cloud IAM you
could do it holistically. But most importantly is
that Cloud IAM allows you for audit and tracking purposes. So for your
organization, it might be very important
to know who made the changes, who gave individual
X, Y, permission and so on. So it's good from a security
and compliance standpoint. Now, with project folders and
labels, we have two roles-- one being the
project creator role, and the second being
the project editor role. As the name implies,
the project creator allows you to create projects. This individual will not only
be able to create projects, but will also manage all
of the service resources underneath it. At organizations, we've
seen that an individual with his permission
usually is in charge of developing the application. So it could be anyone from an
engineering lead to a project manager, but someone who
has access and visibility into budget cycles and so on. The second role is the
project editor role. Now, if you don't want to
give full permissions of being able to create projects willy
nilly around the organization, you can go ahead and give
the project editor role. And as the name implies,
you can go ahead-- the project editor allows
you to manage and edit the resources
underneath that project. So this individual,
usually at organizations, is someone such as a developer
or a project manager. So Max and I spent
a great deal of time talking about all these
different resources, right? And we figured that it would
be important to provide some concrete
examples as to how you can follow these best practices
for your organization. We're actually going to walk
through a startup called Digital D0nut. Now, Digital D0nut
has figured out a way how to break down donuts
into zeros and ones and send them over
the internet-- completely revolutionary,
and they're making waves. So what you see in this
organizational structure is that it's very basic
to follow a startup. You've got one
organization, one project, some service resources
underneath it, and a billing account
and a payments profile. And with every startup, you've
got a couple of individuals just working really hard
to gain that next customer and grow the actual business. So you have a founder
and a developer. Now the founder ends up becoming
the organizational admin as well as the billing account
admin and payments profile admin. The founder really wanted
to let the developer focus on what they do best, and that's
developing the application for Digital D0nut. So as you can see, the
developer becomes the project administrator/owner. And this developer is focused
on building the chocolate application for Digital D0nut. So as Digital D0nut has
expanded beyond markets, they started
realizing that there was more of a need than
just chocolate donuts. The founder ended up working
with some industry analysts to go ahead and analyze
their customer base, and they found that customers
not only love chocolate donuts, but also jelly-filled donuts. So as you can see
in this hierarchy, you've got project
one and project two. Because the founder decided to
build out a new product line, they hired an
additional developer to become the project
administrator. So here, you've separated
the responsibilities by product line-- the chocolate product line
and the jelly product line. So project one is chocolate. Project two would be jelly. Now, the founder
has not had a chance to hire any
additional resources. So they remain the
org admin, as well as the billing account and
payments profile administrator. Now, Digital D0nut has not only
expanded from state to state, but it's just expanding
all across the country. And with this expansion,
as you can see, the organizational structure
is starting to change, it's starting to morph. You see the introduction
of folders-- folder one and folder two. With this new found success, the
founder decided to hire a CTO. This Chief Technology Officer
comes from an organization that has deep expertise in
business-to-business-- to handle
business-to-business markets. One of things the
CTO started doing as they came into the
organization was they wanted to understand and
see if Digital D0nut can move beyond a
business-to-consumer market. And they found that
there was a huge need to sell donuts to businesses
at catering events. So folder one will be the
business-to-consumer division. Folder two will be the
business-to-business division. The engineer that
started at the company has now moved up
the ranks, ended up becoming an
engineering lead, has a few folks working under
them, and becomes the folder administrator. As the folder
administrator, they have full rights and access
to all the projects, chocolate and glazed underneath that, and
all the service-level resources underneath. But with that growth into
the new business division, we hired an engineering manager,
and this engineer manager is going to be tasked
with building out the business-to-business
division for Digital D0nut. They become the folder
two administrator/owner. Also with this success we hired
a chief financial officer. As you can see, the
chief financial officer becomes the billing account
administrator and the payments profile admin. With this hire,
the founder wanted to really understand
how am I spending my GCP resources today. I'm growing out all these
different product lines. I need to understand
where I'm spending the majority of my
development costs, my maintenance costs, and so on. So the founder, the CTO,
and CFO got together and started applying labels. As you can see, labels are being
applied at the product level as well as the service
resource level underneath to measure the
health of Digital D0nut. So Digital D0nut has not only
expand across the country, but now they're looking
at global markets. And with these global
markets, the founder and all the leadership started
analyzing which markets would make sense for Digital D0nut. And they found that there was
a huge need and a huge market in the European market. So as with this, instead
of introducing a brand new product, they decided
to acquire a company who had a similar business model-- Digital Croissant. Now, Digital Croissant
was a great acquisition because they also
use GCP services. And with that they brought
their own leadership team-- their own CTO, their own
engineering leads and managers. Now, in some slides
back, we discussed that there was certain scenarios
where it would make sense where you would have
multiple billing accounts and multiple payment profiles,
and here's that example. Because Digital D0nut
functions in a US currency and has its own legal entity,
it has its own billing account and payments profile. But Digital Croissant
is functioning in a European market. They're going to be
having their own tax code and acting as its
own legal entity. They're going to be
receiving separate documents separate invoices. So it makes sense to have
this structure today. But as you grow as
an organization, as with every mergers
and acquisitions, we recommend that
eventually you start merging a lot of
these organizations and folders and
resources that make sense to your organization, for
the reason that it helps from a cost management
perspective, from a security and permissions aspect as well. Now, with that
consolidation, we notice that the payments profile
and billing account had no administrators during
this mergers and acquisition. So we brought over our
Chief Financial Officer to also become the billing
account two and payments profile two administrator. So what we wanted to do is
provide some concrete examples of how to follow our
best practices that we both mentioned today. Now we understand that
these examples might not mirror your organization,
and that's OK. We understand that. But what we want to do is just
provide you as many resources as possible and as many concrete
example examples as possible to make your
organization successful. So I'm going to go ahead
and pass it off back to Max. Thank you. MAX SACK: All right. So we covered a
bunch of stuff today, from domains, organizations,
billing accounts, payments profiles, projects,
folders, and labels. So we wanted to consolidate all
of the best practices and tips that we had that
were interspersed throughout all of that. So we created this
slide of goodness you can take photos of. If you came in here with
the best of intentions, got your seat, got your
paper and your pen out, your tablet maybe, ready
to take some notes, and then you
immediately fell asleep and heard nothing that we said
the entire time, that's OK. First off, good on you. It's pretty boss move,
and I respect that. [LAUGHTER] Second of all, that's
fine, because everything that we talked about and more we
included in a guide, the Guide to Resource Organization
& Access Management. So we want to strongly
encourage you, if you knew one thing, if you
take one thing away from today, check this out. Go here when you have
some time after Next in the next week, next couple
of weeks, with your team, with the core folks
that are likely going to be in those
administrative positions that we discussed, and walk
through this with them. We have a checklist on
each of the resources, and we go into a
lot more detail. We have a lot of extra links
on additional information and references for all
of the resources and sort of guides and decisions,
key decisions that you need to make. So please check this
out and go through that.
