Posted by Matt Cowger, Global Head of Startup Architects

I really don’t love developing on my local machine. Compared to what’s available on a cloud provider like Google Cloud, it’s not as fast, drains the battery more quickly, and generally has lesser network connectivity / performance. Historically I’ve accepted those limitations because developing on a remote machine meant a bunch of tradeoffs around my IDE of choice, etc. However, the recent advances that Visual Studio Code has made with Remote Development Extension means that much of that pain is mitigated. As a result, I wanted to find a way to run my development environment on fast machine in Google Cloud, but not waste a bunch of money running said machine when I’m asleep or it’s the weekend :).

I had some requirements and constraints going into this:

The machine needs to be faster than my own — this negates the use of Cloud Shell, as those systems are g1-small class at best. The machine should only be running during my work hours The machine should be persistent (e.g. installed software stays installed) The machine should not shutdown while I’m using it — this prevents me from using Preemptible VMs.

In short, I made the decision to use on demand VMs (which meets items 1, 3, 4), but find a way to schedule them (#2).

To schedule them, I wanted to avoid using tools that run all the time (thus causing an increase in cost), and wanted to avoid running tools on my laptop (which could be off, and I might be using a different terminal device). Ultimately, I decided the best scenario to be using Cloud Scheduler to send a message via Pub/Sub at the correct time to a Cloud Function that starts the appropriate VM.

From the diagram, we can see that Cloud Scheduler is configured to push a Pub/Sub message on the ‘autoonoff’ topic with the ‘start’ command every weekday at 8am, along with some other metadata about my project name, zone, etc. It also includes keys for the Pushover API, so I get a notification when it starts:

Next, I configured a Cloud Function that takes the message from PubSub, and uses the Google Cloud APIs to start the VM:

Because this function is very small, we allocate only 128MB of memory, have it listen to the same topic (autoonoff), and run the short code pasted below. You can get a full copy of the code on my GitHub. Whenever a correctly formatted Pub/Sub message is sent, this code will execute and start my VM.

Change the Cloud Scheduler options and the Pub/Sub message for the stop side (I stop the VM at 6pm local), and you have a fully automated, low(er) cost dev machine!

An exercise left to the reader: there’s no reason you’d have to specify machine names. It would be entirely possible to select compute resources by tag instead of name, and start/stop entire fleets of systems (say a LAMP stack) only during working hours.