This is the first of a three-part series of blog posts, which together will form a solution guide for developers using the Cloud Spanner emulator. In this series, after a quick introduction to the Cloud Spanner emulator, we will explore the usage of the emulator with a Cloud Spanner sample application called OmegaTrade.
We will manually deploy the OmegaTrade application’s backend service with a Cloud Spanner emulator backend instead of the Cloud Spanner instance and compare the pros and cons of running an emulator locally vs a remote GCE instance vs Cloud Run. But first, let’s talk about what the Cloud Spanner emulator is and how it can simplify your development process.
Cloud Spanner is a fully managed, distributed relational database offered on Google Cloud. Since its launch in 2017, Cloud Spanner has seen great interest and adoption, with customers from industries like gaming, retail, social media, and financial services running production workloads on Cloud Spanner. In addition to the recently-announced support for more granular instance sizing, which can be very handy for small or non-production workloads, Cloud Spanner offers a no-cost option that supports light-weight, offline environments, such as Continuous Integration and Continuous Delivery/Deployment (CI/CD).
This option is the Cloud Spanner emulator, which enables application developers to emulate an instance of Cloud Spanner locally for development and testing.
Introduction to the Cloud Spanner emulator
The Cloud Spanner emulator enables a no-cost experience for developers to quickly build and test applications with Cloud Spanner without the need for a GCP project, a billing account, or even an Internet connection. The emulator provides the same APIs as the Cloud Spanner production service with some limitations. An important thing to note is that the emulator is in-memory and does not persist data across restarts. All of the configuration, schema, and data are lost upon a restart.
The emulator is intended for local development and testing use cases – e.g., stand it up for a test suite with a known state, run the tests, verify its new state, then shut it down. It is also possible to deploy an emulator on a remote GCE instance and use it as a database for learning, development and testing purposes in a shared environment.
The Cloud Spanner emulator should not be used for performance testing and while the emulator can be used in development and test environments, it is still a good idea to verify your application by running it against the Cloud Spanner service before it is deployed to production.
For a complete list of supported features and limitations of the emulator, take a look at the README file in GitHub. For a more detailed introduction to the Cloud Spanner emulator, read this post.
Running the Cloud Spanner emulator
There are multiple options available for running the emulator – a pre-built Docker image, pre-built Linux libraries, Bazel, or by building a custom Docker image. Below is a comparison between multiple ways of provisioning and starting the emulator and their respective use cases.
For most of the development and testing use cases, this is the quickest way to get started. All configurations, schema, data etc are lost upon a restart of the emulator process(es).
Deploy the emulator on a Remote GCE instance:
Manual / gcloud deployment
Provision via Terraform
Provide a free (in terms of Spanner cost) experience of Cloud Spanner for multiple team members
Although the configurations, schema and data are lost on a restart of the GCE VM or emulator services, the services on the remote instance allow multiple developers to troubleshoot a specific problem collaboratively
In organizations that have segregation of Dev, Test and Prod GCP projects, a remote deployment on a GCE instance within the VPC can serve as a Cloud Spanner or Test environment, which can result in cost savings
Continuous unit and integration tests can be run against the Cloud Spanner emulator, which saves costs. However, note that the emulator service is not intended for performance tests
In a GitOps driven environment, provisioning the emulator using a Terraform template can make it easier to set up CI pipelines
Minimal (emulator itself is free, cost depends on the GCE instance type chosen)
Deploy the emulator on Cloud Run
Since the emulator is available as a pre-built image on GCR, it can be deployed on Cloud Run as a service. Note that you can only bind one port on Cloud Run and the emulator has two services – a REST server that runs on a default port 9020 and a gRPC server that runs on port 9010
Cloud Run can be a good choice if you want to use either the REST gateway or gRPC
All client libraries are built on gRPC. Cloud Run supports gRPC (after enabling HTTP2). If your application uses client libraries or the RPC API, an emulator can be deployed to accept connections on port 9010
If you would like to use the REST interface alone, you can configure Cloud Run to send requests to port 9020
Minimal (emulator itself is free, so the only cost is that of running this service on Cloud Run)
Sample Cloud Spanner application: OmegaTrade
Throughout this series, we will use an application called OmegaTrade to demonstrate the configuration of the Cloud Spanner emulator both locally and on a remote GCE instance or Cloud Run. OmegaTrade is a stock chart visualization tool built in NodeJS with a Cloud Spanner database backend. For this series of blogs, we will use the backend service of the OmegaTrade app along with the Cloud Spanner emulator.
You can find the sample app repository here. To learn more about the app and its features relevant for Cloud Spanner, see this blog post.
In the next part, we will learn about running the Cloud Spanner emulator locally and containerizing and deploying the sample app on an emulator running locally. Stay tuned!
Cloud BlogRead More