GCP Developer Sandboxes For All
We’ve recently rolled out a strategy for allocating GCP Sandbox Projects for our developers, and it’s another boost to the developer experience at Promevo!
As developers, there are a few things that are critical to unleashing us: Tools and Access. We need tools to do our job. We need access to apply solutions in the appropriate places. Productivity and innovation can be stymied in large organizations that have these things locked down.
In many ways, cloud native development solves these problems. Need a clean server to experiment on? Instead of submitting a request to your IT department, you go into Google Cloud Platform and provision one yourself.
Perhaps you just finished a QwikLab as part of some training, and you want to take a deeper look at Pub/Sub or Cloud Run. But your free GCP project has been dissolved back into the ether from whence it came. What are your options? It seems that they are: 1) Spin up your own personal Google Cloud Project; 2) Try to find a project that is sanctioned by your employer for learning and prototyping purposes.
Here’s the rub. You don’t want to use your personal credit card to add billing to a GCP project. Especially when it’s work related. Further, many employers don’t provide access to GCP projects where developers may incur costs.
At Promevo, every developer gets a personal GCP sandbox project. In this Project, they are Owner. That’s right. It’s not a watered down, kid gloves Project. Billing is enabled, and the developer has the Owner role on the Project. That means full access to all the powerful tooling available in the Google Cloud Platform.
Ok, so what risks present themselves? Well, there are a few immediate concerns. First is security. How do we ensure that these Projects are truly isolated sandboxes and don’t cause any unintended impact on business operations? Second, we want to make sure that developers are following an acceptable use policy. Third, how do we prevent a surprise monthly bill with an unexpectedly high cost?
These GCP Projects live under a completely different domain from our production Projects. This gives us a nice separation from production resources. The billing account is also dedicated solely to the developer sandboxes.
Further, we trust our people. With power and access comes responsibility, and we’ve given guidance on the do’s and don’ts for developers.
Developers acknowledge an acceptable use policy when it comes to appropriate use of IT resources. There is communication and understanding that a GCP Project is a privilege, and that any abuse may be cause for corrective action to be taken.
Lastly, the cost concern. Using guidance from Google, we have a control in place to disable the billing on a project once it exceeds its budget for the month. The nuts and bolts of this implementation are as follows.
As we can see, leveraging already available Google Cloud tools, we get budget alerts when a project exceeds certain thresholds. For example, once you’ve spent more than 50% of your budget for the month, you’ll see an alert in a Google Chat Space. You get more alerts as you approach your limit. This is the developer’s cue to dial down their spend. However, if the spend crosses the 100% threshold, then the billing gets shut off automatically.
So there we have it! It’s good to be a developer at Promevo, and have access to the full array of Google Cloud tooling. We can upskill and get the much needed exposure and repetitions inside GCP to achieve expert status. It is also empowering to be part of a culture where trust and mutual respect are fostered, and you’re given the tools and access needed for success.