10 services every developer should know to get the most out of Google Cloud

Image Credit: Author

Hey there! 👋🏼

If you’re reading this there’s a good chance that you’re considering using Google Cloud or you’re already using it and are interested in getting some basics down to start to take advantage. I’ve been using Google Cloud for years and have gone into the weeds a lot and even invented some tools around the various offerings such as the Cloud Workflows, where I connected various services together to build out a scalable serverless CI/CD pipeline.

Here’s a diagram showing how some of the services in the list below work together. This image is taken from one of the excellent talks at Cloud Next ‘23: What’s new in modern CI/CD on Google Cloud.

Let’s get into my recommended services you have to know about. Keep an eye out for some of the services listed in the diagram throughout this post!

1. Cloud Build

Number one for me has to be Cloud Build. It’s the service that is at the start of every good software release and it provides so much flexibility in what it can do. Google themselves describe it as a service where you can:

Build, test, and deploy on our serverless CI/CD platform

The build templating language is very straightforward and once you’ve built a few Cloud Build service runners, you can do it without even needing to look at the docs.

Here’s an example:

Let’s say you have a node application, and you want to have Cloud Build run continuous integration (CI) on your code. You might build a test run trigger with the following yaml.

steps:
  - id: Install dependencies
    name: node
    entrypoint: npm
    args: ["install"]

  - id: Run tests
    name: node
    entrypoint: npm
    args: ["run", "test"]
    env:
      - CI=true

2. Cloud Run

Cloud Run is, by far, my favourite service on Google Cloud. It really makes getting any code deployed the simplest process in the world. Let’s say you have a web app that you want to deploy. If you run gcloud run deploy in the CLI in the root of your app’s repo, then it will package up your code, figure out which language it’s in, create an image of your code and store it in artifact registry, then it will deploy it to Cloud Run and return to you a load balanced, HTTPS endpoint in a region of your choosing. All within a few minutes.

That to me is magical.

It completely abstracts a lot of steps for you that you’d otherwise need some platform engineering skills for, such as build tools, Dockerfiles, and so forth, and allows you, the developer, to focus on your code.

Of course, if you want to, you can absolutely control all those things too. If your repo has a Dockerfile for example, then by default, the build and deploy process will automatically use it. You can also set up your Cloud Run instance with Terraform or via the console and manually handle traffic splits to try out new versions. You can even attach custom domains to your Cloud Run backends too if that tickles your fancy.

There’s an absolute plethora of features that Cloud Run has, which you can dive into, but the last I’ll mention is that it can scale to zero, so if nothing is using the service, then it simply shuts off and won’t cost you anything. When a request does come in, Cloud Run will automatically start the container and hold onto that request until it can be served.

Image: Cloud Run console showing traffic splitting and https URL (source: Google)

3. Cloud Logging

Google Cloud Logging is a fully-managed service that makes it easy to collect, store, analyse, and search log data from applications and services running on Google Cloud Platform. Cloud Logging provides a number of features that make it easy to make sense of what's going on in your app, including:

• Log queries: You can use Cloud Logging to query your log data using a variety of filters and conditions.

• Metrics: Cloud Logging also provides metrics that you can use to track the performance of your app.

• Insights: Cloud Logging can automatically generate insights from your log data, such as identifying potential errors or performance bottlenecks.

Cloud Logging is a great option to make sense of the log data from your applications and services, it’s easy to use as it provides logging out of the box that doesn’t require any additional configuration from your applications.

4. Secret Manager

The amount of times I have seen API keys, passwords, encryption keys and who knows what other kinds of secrets stored in git repositories only to then be stolen for use by bad actors is way more than I would like. It’s time to change that behaviour.

Firstly, I try to avoid using secrets at all cost, by instead using service accounts and applying the principle of least privilege. If that’s not possible, say for example you’re using a 3rd party mailing service, then make use of Secret Manager. It will store the secret securely and encrypted by default. Secret Manager also allows fine-grained control and access to a secret. So you can limit who can access a secret, who can update a secret and so on. Even down to the secret version (secrets can have multiple versions). You can also implement useful secret rotation policies too which will help keep multiple-year-long secrets a thing of the past!

5. Cloud Load Balancing

Google Cloud Load Balancing is a service that distributes network traffic across multiple instances of your application. This can help to improve the performance and reliability of your application.

Load Balancing on Google Cloud can be used to serve your APIs quickly and with reduced egress costs by serving users with regional deployments. Regional deployments distribute your application across multiple regions, which can help to improve performance for users in different parts of the world.

Google Cloud Load Balancing also offers a number of features that can help to improve the security and reliability of your application, such as health checking and automatic retries. You can also attach a CDN (content delivery network) to your load balancer, allowing for assets such as js files or images to be stored at the edge, meaning websites and media loads faster for your users, and also further reduces your egress costs.

6. Firebase Hosting

Whilst not strictly part of Google Cloud directly, Firebase Hosting is a fully managed hosting service that allows you to deploy web applications and static files to the web. It offers a number of features that make it a great choice for hosting SPA (single page apps, like React or Angular) including:

• Automatic deployments: Firebase Hosting can automatically deploys your code changes to production as soon as you commit them. This means you can see your changes live without having to manually deploy them.

• Preview links: Firebase Hosting generates preview links that you can share with others to view your app before it’s live. This is helpful for getting feedback from others or for testing your app before you launch it.

• Cloud Run integration: You can connect Cloud Run as your backend for Firebase Hosting, which provides the serverless compute platform that we discussed as number two in this list.

The free tier of Firebase Hosting will get you a long way before you need to start paying anything.

7. Cloud SQL

As the name implies, you might have guessed that Cloud SQL is for databases that use SQL to store and retrieve data. In Google Cloud’s case, the managed offerings (flavours?) of SQL databases they offer are PostgreSQL, MySQL, and Microsoft SQL Server. By opting to use a managed service for your database, compared to spinning one up for yourself, is that you’ll save a lot of time, and get a lot of good security and operational configuration out of the box for free. It will cost you a bit more than the compute to run it yourself, but the time cost may not be worth it.

The managed service also offers a high-availability option, meaning that if the main database is to go down for some reason, then another will be able to take on the workload of the traffic and your app won’t be offline. Some of the other options available out of the box include automatic backups, replication (eg, you may want multiple read replicas if your application is read heavy), scalability. You can scale up or down to meet your application demands.

8. Kubernetes Autopilot

If you’ve ever used Kubernetes, or k8s for short, you’ll know it’s a lot of work to setup, maintain and run. Google Cloud exclusively has a mode of k8s called “Autopilot” whereby the model of operation changes from a self-managed, to a Google-managed version of Kubernetes.

They take care of configuring the cluster settings such as, scaling and setting up compute resources, as well as security to name a few. However, the model of pricing also changes. Instead of paying for the nodes provisioned, you’ll instead pay for the resources your individual workloads request. This can be useful in scenarios where you have a lot of unused overhead in your cluster nodes, and where the “bin packing” problem becomes Google’s problem instead. Amongst the other benefits listed earlier, it allows you to focus on your application delivering business value, rather than spending time configuring and maintaining a Kubernetes cluster.

Find out more about Autopilot with this video:

9. Artifact Registry

We’ve briefly mentioned it already, but as a developer one of the services in Google Cloud you need to know about is Artifact Registry. It’s not one of the ones you go into often but it forms one of the core services in your toolkit to deploy your application. It’s where we store the build artifacts from our Cloud Build jobs that we use to deploy onto Cloud Run or Kubernetes. But it can do other stuff too! Artifact Registry has recently become the new version of what used to be Google Container Registry. You may have even seen links to gcr.io which is where container registry used to host containers, but Artifact Registry can hold other types of artifacts. In addition to container images, it can store NPM modules, or maven packages & more!

If your org has a custom NPM module, say some kind of design library or similar, then perhaps you’ll want to store this in Artifact Registry, where it securely accessed only by those in your org. In addition, Artifact Registry can store artifacts in locations of your choosing, so if you’re going to deploy your code in a specific region, say australia-southeast2 then it would make sense to store the artifacts in the same region, especially since some container images can be in the gigabytes of size, saving considerable inter-region egress traffic costs.

10. Cloud Code

Last, and certainly not least in this top 10 is Cloud Code. Whilst not strictly a “service” that Google Cloud offer, according to Google:

Cloud Code is a set of AI-assisted IDE plugins for popular IDEs that make it easier to create, deploy and integrate applications with Google Cloud. Duet AI is integrated with Cloud Code, providing AI assistance directly on your IDE.

There’s a number of features in here which are worth discussion, but the main feature I’d like to talk about is the integration with your cloud infrastructure and ability to deploy and play with your code live in the cloud.

If you have a development environment in the cloud (and if you don’t, definitely consider it!), then you can do “hot reloading” of your code in the cloud where by you make a change and then you can see that change in the cloud, instantly (language dependent) and validate the change you made works as expected. Additionally, you can do things like attaching a debugger to your live-running code and interrogate problems as they occur.

The other feature worth mentioning is YAML syntax support. Working with YAML is fraught with risk because of the damn indents and spacing problems you’ll no doubt be familiar with. Cloud Code offers linting support for these files, which is especially useful when designing k8s templates. Not only linting, it’ll help with you “snippets” of text making the whole process easy.

Conclusion

There you have it, those are the top 10 tools that I believe every developer should know about to get the most out of Google Cloud. There are so many tools it was hard to narrow down the list to just 10, but I feel this is a great starting point. In addition, once you start to get into and use those products a bit more, you’ll find that others lend themselves really well toward integrating with your app, for example, Cloud CDN, we didn’t really talk about but is a natural fit and addition to Cloud Load Balancing.

Let me know what you think and if there’s anything you’d add to this list. I’d love to hear your opinions or recommendations in the comments.