Managing GCP projects at scale — part 1

Adeline VILLETTE
Decathlon Digital
Published in
4 min readJan 27, 2022

Why does Decathlon need a GCP Project Factory?

Source

Since the beginning of 2021, Decathlon operates 100% of their workloads on Public Cloud. One of our Cloud Providers is GCP (Google Cloud Platform).

One recommendation on GCP is to have one project per application and per environment. Doing that offers many advantages: restrict access to your GCP project to a strictly limited & approved group of users, avoid quota issues (and potential impacts on your production), reduce the attack surface, and many more. In a large company, you can quickly have a large number of GCP projects to manage.

Decathlon, as a retailer, owns stores in more than 60 countries, located all over the world. Many time slots to cover, spanning 20 timezones. Each country has its own IT team. The team in charge of the management of GCP is based in France.

For the past 2 years, our users have already been able to request their new GCP project on an internal portal, dedicated to Cloud requests. Around 30 new GCP projects were created each month. With such a high number of requests, we had already automated the creation of new GCP projects, with the following limits:

  • Our Cloud Management team had to review each request to double check and approve some mandatory information like the cost center (who pays the bill) or the team in charge of the new GCP project, for instance.
  • We did not have SLAs for this process. Sometimes the request was approved within 5 minutes, and another time within one week. It could take even more time if some information was not valid.
  • As we are humans, we could make mistakes during the user request validation.
  • Most of the GCP projects were never requested for deletion. The process was too difficult, lengthy and not automated.
  • As we didn’t consider project updates at the beginning of the automation, it was hard to do them. By updates, we mean enabling a new useful API or adding a permission to a specific user for all GCP projects.
  • Following the evolution of our automation, we put together several different technologies, with a lack of skills for some of them.

Based on that, we decided with the team to build our own GCP Project Factory!

After discussions with our users and our teams, we defined the objectives of this factory:

  • Users should still be able to request GCP projects on our internal portal.
  • Some advanced users could automate project creation.
  • The introduction of a SLA, such as the capability to deliver a new GCP project in less than 15 minutes when requested.
  • All information provided by the user during the request has to be validated automatically, based on defined rules.
  • Our Cloud Management team has to be able to manage mass updates on our GCP projects easily and quickly.
  • A user has to be able to request the deletion of his GCP project through our internal portal (and only for his project).

Once the objectives are set, let’s explore and deep dive in the functional process. And a good diagram is easier to understand than words:

Creation process
Deletion process

Ok, we know how the lifecycle process works. Before designing the architecture, we have another key point to deal with: the type of GCP projects.

Indeed, there is not only one type of GCP project at Decathlon. We have several types to deal with based on several criterias (connected or not to our network for example).

Some criterias are mandatory whatever the kind of project, such as enabling a set of APIs or linking the project to a billing account.

Some of them are required only for projects connected to the Decathlon network: link the new project to our shared VPC.

Others are only related to projects not connected to the Decathlon network: give the Project IAM Admin role to the team responsible for the project.

Therefore, we decided to introduce 2 concepts to solve the issue:

  • Component: a component is a specific set of actions. Example: link the new project to our shared VPC.
  • Package: a package is a type of project. It’s the combination of different components.

Components can be used in several packages, some of them are only for a specific package.

Packages and components

And now we are ready to design the architecture of our GCP project factory. You will discover that in the next chapter!

Adeline Villette & François Betremieux

--

--