Many of today’s games are rich, immersive worlds that engage the audience in ways that make a gamer a part of a continuing storyline. To create these persistent experiences, numerous storage technologies are required to ensure game data can scale to the standards of gamers’ demands. Not only do game developers need to store different types of data—such as saves, inventory, patches, replays, and more—but they also must keep the storage system high-performing, available, scalable, and cost-effective.

Enter Open Saves, a brand-new, purpose-built single interface for multiple storage back ends that’s powered by Google Cloud and developed in partnership with 2K. Now, development teams can store game data without having to make the technical decisions on which storage solution to use, whether that’s Cloud Storage, Memorystore, or Firestore. 

“Open Saves demonstrates our commitment to partnering with top developers on gaming solutions that require a combination of deep industry expertise and Google scale,” said Joe Garfola, Vice President of IT and Security at 2K. “We look forward to continued collaboration with Google Cloud.”

Game development teams can save game data against Open Saves without having to worry about the optimal back-end storage solution, while operations teams can focus on needed scalability and storage options. Here’s how it looks in practice:

With Open Saves, game developers can run a cloud-native game storage system that is:

• Simple: Open Saves provides a unified, well-defined gRPC endpoint for all operations for metadata, structured, and unstructured objects.
• Fast: With a built-in caching system, Open Saves optimizes data placements based on access frequency and data size, all to achieve both low latency for smaller binary objects and high throughput for big objects.
• Scalable: The Open Saves API server can run on either Google Kubernetes Engine or Cloud Run. Both platforms can scale out to handle hundreds of thousands of requests per second. Open Saves also stores data in Firestore and Cloud Storage, and can handle hundreds of gigabytes of data and up to millions of requests per second.

Open Saves is designed with extensibility in mind, and can be integrated into any game—whether mobile or console, multiplayer or single player—running on any infrastructure, from on-prem to cloud or a hybrid. The server is written in Go, but you can use many programming languages and connect from client or server since the API is defined in gRPC.

Writing to and reading from Open Saves is as simple as the following code:

  // To write
	record := &pb.Record{
		Key:      uuid.New().String(),
		Tags:     []string{"tag1", "tag2"},
		OwnerId:  "owner",
	}
	createReq := &pb.CreateRecordRequest{
		StoreKey: storeKey,
		Record:   record,
	}
	_, err := client.CreateRecord(ctx, createReq)
	if err != nil {
		t.Fatalf("CreateRecord failed: %v", err)
	}
	// To read
	getReq := &pb.GetRecordRequest{StoreKey: storeKey, Key: recordKey}
	response, err := client.GetRecord(ctx, getReq)
	if err != nil {
		t.Errorf("GetRecord failed: %v", err)
	}

We are actively developing Open Saves in partnership with 2K Games, and would love for you to come join us on GitHub. There are a few ways to get involved:

• Install and deploy your Open Saves service
• Check out the API reference
• Read the development guide and start contributing
• Join the open-saves-discuss mailing list

Mailjet allows companies to create, send, and track millions of emails to their customers and prospects around the world each month. The company’s offerings range from routing these emails to tailor-made tools that allow clients to design and send marketing campaigns with messages related to sales, user clubs, coupons and discounts, and promotions, as well as transactional emails such as purchase confirmations, shipping confirmations, e-tickets, or password resets.

“All of our services are accessible through programming interfaces. We use the same APIs for ourselves and for our customers. This is part of our unique selling point, which is to make life easier for developers and marketers,” explains François Fanuel, IT Operations Manager at Mailjet.

The company scrupulously monitors its service quality to help ensure that emails sent on behalf of its customers don’t trigger spam filters, and that they obtain the best possible open and click rates.

From hosting to the cloud

In its early years, Mailjet used hosted servers. This model had several disadvantages. It was impossible to instantly activate or deactivate computing power; the company could not be charged for actual, to-the-minute usage; and it lacked the flexibility to add disk space or scale servers in real time.

At the beginning of 2016, Mailjet decided to switch to the public cloud in order to improve technical and economic flexibility. “This two-year evolution required us to review our developments. If we use a virtual machine even for just one hour, our computer code must be able to support it in order to preserve the consistency and integrity of the data and processes,” says Fanuel.

“We needed a way to port our IP addresses to Google Compute Engine. In less than a month, the feature had been developed by Google engineers. This reactivity really impressed us and was definitely a deciding factor.”

—François Fanuel, IT Operations Manager, Mailjet

Mailjet and Google were already partners. The marketing and transactional email specialist is one of only three providers in the world, and the only one in Europe, accredited by Google to send bulk emails through Google Cloud Platform. The choice—based on three main factors—was obvious.

Financial and technical considerations

Factor 1: the right price proportionality. “We are able to activate Google Compute Engine virtual machines on demand, without needing to reserve these instances. While the machine remains active, a sliding-scale price is applied, which is particularly attractive to us,” explains Fanuel.

Factor 2: the quality and level of technical communication. Mailjet has direct access to Google Cloud Platform engineers when required. The company has its own IP addressing infrastructure, which is the foundation of its service quality. “We needed a way to port our IP addresses to Google Compute Engine. In less than a month, the feature had been developed by Google engineers. This reactivity really impressed us and was definitely a deciding factor.” Since then, via specific tunnels, Mailjet IP addresses have been ported directly into Google Compute Engine.

Factor 3: conformity to international data regulations. Mailjet is the only email service provider to be ISO 27001 certified and GDPR-ready, enabling the company to offer its clients the highest level of data security and privacy. Google Cloud Platform is also ISO 27001 certified, which was an important factor for Mailjet.

Power through minimalism

In mid-2016, Mailjet replaced its 30 or so email sending servers installed at a hosting company with smaller Google Compute Engine virtual machines, using the automatic load-balancing function. “Using smaller virtual machines—but more of them—optimized our computing power.” This precision mechanism accompanied an increase in activity for the company, with the number of emails sent doubling every year. As for the company’s some 300 TB of data, this is stored in Google Cloud Storage.

The flexibility and power of Google Cloud Platform helps ensure that Mailjet can adapt to peaks in activity that can reach up to 20 times the normal flow—our customers usually send their messages at the same times and during the same peak periods. “Previously, we had to reserve a lot of computing power with our hosting company, equivalent to 150 servers. Moving to an on-demand infrastructure means we can avoid paying a disproportionate fixed annual cost.”

Google Cloud Platform also provides Mailjet with the infrastructure needed to process events centrally, which facilitates technical support. A new analytics dashboard in the making will provide customers access to their campaigns’ key metrics in real time—a circulation report, open rates, and click-through rates, as well as invalid email addresses— regardless of the volume of emails at stake.

From distribution to development

Following routing operations, the development environment is currently being ported to Google Cloud Platform, and will eventually represent 100 virtual servers. “The addition of any new code is iteratively tested in Google Cloud Platform. We benefit from machines that are custom made for our needs, from machines with one core and 3 gigabytes of memory, up to machines with 64 cores.”

Mailjet uses the Google Cloud Interconnect virtual private network to tailor sending flows by geographical location. “For customers who only use our routing service, we will soon have worldwide load balancers. This will help ensure their API requests are received and their emails are sent to Europe and America from one single IP point, thus avoiding transatlantic latency issues.”

Mailjet also uses the Google Identity Aware Proxy authentication tool. All its employees around the world benefit from unique, more secure access, whether they use Google Sites intranets, or the development, or production environment. “Google Cloud Platform delivers on all the promises of a public cloud: service customization, real-time computing power adjustment during periods of high and low demand, and instant activation of computing resources. For us, it’s the best possible ratio between price, performance, availability, and quality,” concludes Fanuel.

We’re excited to announce that Spring Cloud GCP version 4.0 is now generally available! In this post, we’ll be describing what the new major version has to offer, and demonstrating the process of using the migration guide on one of our reference architectures, Bank of Anthos.

What’s new?

With this release, Spring Cloud GCP officially supports Spring Boot 3.x. However, this migration involves a number of breaking changes as outlined in the migration guide. The full list of changes made is available on Github, but the one of the most significant differences is that Java 17 is now a minimum requirement.

Another notable feature of this release is the addition of starter artifacts – Spring Boot starters for Google Cloud – that provide dependencies and auto-configurations for 80+ Google Client libraries. Just as the name suggests, these starters can serve as helpful starting points when working with a new client library. For now, they’re in preview. 

These starters are not included in the BOM by default and need to be added as a dependency to your project before they can be used. For example, if you wanted to get started with Cloud Text-to-Speech, you would include the following:

<dependency>
    <groupId>com.google.cloud</groupId>
    <artifactId>google-cloud-texttospeech-spring-starter</artifactId>
    <version>4.0.0-preview</version>
  </dependency>

The upgrade process

We prepared a migration guide to help answer any questions involved with moving from 3.x to 4.x.  Let’s follow those instructions to migrate Bank of Anthos.

We’ll start by cloning and building the application before the upgrade, according to the quickstart and development guide:

PROJECT_ID=<YOUR-PROJECT-ID>
gcloud services enable container --project ${PROJECT_ID}

git clone https://github.com/GoogleCloudPlatform/bank-of-anthos.git
cd bank-of-anthos/

gcloud services enable container.googleapis.com monitoring.googleapis.com \
  --project ${PROJECT_ID}

REGION=us-central1
gcloud container clusters create-auto bank-of-anthos \
  --project=${PROJECT_ID} --region=${REGION}

gcloud container clusters get-credentials bank-of-anthos \
  --project=${PROJECT_ID} --region=${REGION}

skaffold run --default-repo=gcr.io/${PROJECT_ID}/bank-of-anthos

At the end of this, you should see a “deployment stabilized” message:

Deployments stabilized in 9.657 seconds

With the environment set up for development, we’re ready to move on to the actual migration. The migration is already complete at time of writing, but here’s the full list of changes made:

• We began by checking the current Java, Spring Boot and Spring Cloud GCP versions.
  • Our Java version is okay, but the other two are out of date, and will need to be updated.
    We can also add the Spring Cloud GCP BOM to manage our versions going forward while we’re here.
• Then, in no particular order, we can make the following code changes:
  • Remove the explicit type declarations from our ResponseEntity instantiations.
  • Replace all javax.* imports with Jakarta.* counterparts, since Spring 3.0 makes use of Jakarta EE 9.0

With those changes in place, the app is upgraded and ready to re-deploy!

Live example

For a finished example of this migration, check out the Bank of Anthos repository on Github. It’s an excellent sample application that showcases a polyglot Java & Python app, served on Kubernetes and Google Cloud. All CI/CD and configurations are open source, so it may be instructive as you approach this migration.

Thanks for reading, and feel free to provide comments or feedback on Twitter, or in the issues section of the repository.