Managing GCP projects at scale — part 3
What have we learned using the GCP Project Factory?
Last chapter of our story. In the previous posts, we explained why we need a GCP Project Factory and how we built it. More than 10 months after the delivery of the GA, it’s time to share our conclusions, what works well and what we would do differently.
Our conclusions
Our target was to deliver a new GCP project to our users within 15 minutes. We exceed our goal as it is delivered in less than 5 minutes.
Our team doesn’t have to do some boring tasks with low added-value. The process is fully automated, including the verification of the information provided by the users and we end up with higher quality data.
Our users are satisfied with the new process. We measured the satisfaction level and the grade is great: 4.71 / 5.
We also tested the limits of the creation process, and we were able to create 110 projects in less than 20 minutes. We didn’t try to go further.
It’s now super easy to manage a mass update on our GCP projects. We already did it to enable new services, and we only needed 30 minutes.
What works well?
Working together
First of all, we built a team of incredible people. Every teammate has a strong motivation to build this factory and we are all proud of what we did!
Every important decision has been voted on by the team. Each time, we did a workshop, we listed the different solutions and chose the best one together.
At different times, we asked the opinion of our key users. And we did well! Following one of these workshops, we changed the functional process of the project deletion. The way we are doing it fits our users expectations.
Versions
Before the GA, we launched alpha and beta stages to some specific key users. They provided us with important feedback and we made improvements before the GA. It was very easy to adopt for every user.
We adopted an iterative approach with incremental improvements to the platform. And more than one year later, this is the result:
Project management
We defined our SLAs and our KPIs at the beginning of our project.
We wrote documentation for everything, including the decisions we made. We didn’t ask the same questions again and again.
The documentation has been written as questions arose. We didn’t wait for the end of the project.
Never underestimate the architecture design. We took the needed time for this step, and it was worth it. The development was easier and faster. Making a new version is also easier.
In general
More than 10 months later, we do not regret our technical choices. Maybe, if we had to start from scratch again, we would probably make some minor changes (like moving our containers to Cloud Run or managing the update process before the deletion one). But it’s probably the case for every project in IT, technology is moving fast.
What we did for GCP, gave us some inspiration for AWS now.
What would we change if we did this project again?
Even if we decided the content of each version at the beginning, we didn’t create a backlog right away.
Same for the changelog. We recommend doing it at the delivery of your first version.
Don’t underestimate the workload of your project. Unless you have a team focused 100% on your project, the day-to-day business will invite itself in your roadmap!
Hiring a senior developer in your team will probably allow you to avoid some small mistakes and follow best practices from the beginning.
We hope you enjoyed our story and that it helps you to design your own GCP Project Factory.
Adeline Villette & François Betremieux
