You have something in your pocket right now that possesses more computing power than spacecraft fifteen billion miles away from Earth. No, not your mobile phone — the key fob for your car! Voyager 1 and Voyager 2 launched in 1977, and forty five years later, these little rascals still work and send data back to Earth while moving through cold, empty space at over thirty thousand MPH. Think your key fob will still be going strong in 2068? It’s also amazing that the Romans created a concrete so long-lasting that two thousand years later, structures built with it are still in use. Meanwhile, the roads outside my house develop potholes if a rabbit sneezes on them. 

I’m a fan of durability because it allows you to think outside the box. If I know that my foundations are safe, I’ll be more inclined to push the boundaries to innovate outside my comfort zone because the environment can handle it. Durability needs to be a cornerstone of the application modernization conversation, as each application and environment we create for our customers is the first step of their next-generation technology and business strategy. An entire organization’s goals and dreams rests on the shoulders of the technology architectures we are building, and we need to ensure that the foundation has the strength to withstand everything the future can throw at it — and then some.

When it comes to selecting the appropriate foundational technologies for modern applications, it’s crucial to consider the longevity and reliability of the technology. Will an exciting new open-source large language model be around in a year? Or that interesting new database from PayPal? How do I choose something from the ever-growing CNCF landscape diagram? This is where the strength of open-source communities and vendor backing comes into play. For instance, Kubernetes, PostgreSQL, and Java have stood the test of time, thanks to their robust feature sets, dedicated communities, and strong vendor support.

Kubernetes provides a scalable solution for managing and deploying applications, with Google’s strong backing: As of July, we’ve made over 1,000,000 contributions to the k8s project — 2.3 times more than any other contributor. PostgreSQL, meanwhile, is one of the world’s most advanced open-source databases and offers a comprehensive set of features that cater to a wide range of data processing needs, with a vibrant community constantly enhancing its capabilities. And Java, a general-purpose programming language, has been a staple in the development community for decades, providing a reliable platform for building robust applications.

Choosing an established technology not only brings the benefit of a mature feature set but also the assurance of continuity. A new database or language model may be promising, but they lack the track record of these tested technologies. The risk of adopting such new technologies is their potential discontinuation or lack of support, which could jeopardize your application’s stability and longevity. 

The Voyager team’s use of aluminum foil is a great illustration of this principle. They chose a simple, reliable, and available solution to protect sensitive instruments during their mission. The choice of aluminum foil might not have been the most cutting-edge or exciting, but it was practical, reliable, and ultimately successful. Similarly, when choosing foundational technologies for your modern applications, sometimes the “boring” choice is the best one. It’s not about chasing the latest trends; it’s about choosing what works and stands the test of time.

Vendor backing is another critical consideration when choosing foundational technologies. A reliable platform provider that runs these technologies ensures a high-uptime Service Level Agreement (SLA). For example, Google Kubernetes Engine (GKE) offers a 99.95% uptime SLA, while Bigtable “just works,” and Cloud Storage doesn’t lose data thanks to a design that supports 99.999999999% annual durability.

Boring doesn’t mean blah

That’s not to say we shouldn’t experiment with new technologies and encourage our customers to do the same. Everyone needs an innovation strategy. The concept of an ‘innovation spectrum’ is helpful here. This spectrum represents different degrees of technological innovation that companies can employ based on their specific needs and capabilities. On one end of the spectrum, there’s incremental innovation, which involves making small improvements or extensions to existing products, services, or processes. On the other end, there’s radical or disruptive innovation, which involves creating entirely new products or services that can potentially disrupt entire industries.

A classic example of balancing cutting-edge technology with “boring” or legacy technology is seen in many financial institutions. They might use AI and ML for fraud detection or predictive analytics while still relying on tried and true technologies for their core banking systems. This blend of newer and older technologies allows them to benefit from the latest advancements without jeopardizing the stability and reliability of their critical operations. However, as the banking industry is finding out, that can also come at a risk of stifling innovation and can cause customers to look elsewhere.

For developers, Google Cloud’s Kubernetes-based platforms present a similar balance between innovation and stability. For example, researchers can leverage cutting-edge GPU sharing in GKE to explore the origins of the universe, while the BBC uses Cloud Run serverless containers to keep up with demands of a very busy news day. 

Adopting best practices like platform engineering can provide a robust foundation for rolling out new technologies. Platform engineering focuses on creating a stable, scalable, and secure platform that allows for rapid deployment of applications. GitOps is another important practice that involves using Git as a single source of truth for declarative infrastructure and applications. With Git at the center of the delivery pipelines, developers can use familiar tools to make pull requests. Changes can be rolled out or rolled back easily, making the process of adopting new technologies smoother.

When it comes to modern application development, developers need to be able to trust that the foundational technologies they choose will be reliable and durable. Without this assurance, developers may be hesitant to take risks or explore creative solutions. To give them the confidence they need, an effective platform engineering strategy can provide a strong foundation for rolling out new technologies while ensuring stability and security.

Boring can be beautiful, especially if you’re building for the long haul. Regardless of what you’re developing, from roads and rocketships to microservices or network architecture, the fundamental structure needs to withstand everything the conceivable future can throw at it. A solid, durable foundation offers developers the capabilities they need to push the boundaries, and the reliability they need so their brainchild is still humming along, 15 billion miles away.

When banks and other financial institutions make their products available via non-banks, we call that Embedded Finance. Think, for example, of a retailer offering financing for people buying goods; or a budgeting app gathering bank transactions to help you categorize and understand your spending patterns. The finance – the money management – has been embedded into the retailer or the budgeting experience.

This last example falls under the Data Exchange category of Embedded Finance , and it’s often also called Open Banking. In many countries this active data exchange is actually mandated by law, with specific Open Banking standards encoded into law for all financial institutions. As of this blog post, there are approximately 37 countries with such laws already in place or currently being worked on.

In an Embedded Finance scheme there are three main players: The financial institution offering their products and services, a third party provider (TPP) making use of those products or services, and an end user who is a customer of the financial institution and is interacting with the TPP.

The most important ingredient for these schemes is consumer trust. If a consumer does not trust that their data will be safely shared with a third party, and that they can easily understand the terms they have agreed to and stop sharing their data whenever they want to, consumers will simply not participate. When a consumer agrees for their data to be shared, this is called consent.

What components do I need for a successful Embedded Finance solution?

Banks’ products and services are made available to other parties via APIs, thus a fundamental component is an API Management platform. An API Management Platform lets you design, secure, analyze, and scale APIs anywhere with visibility and control.

Also, we need a component to manage consents given by end users. Consent Management refers not only to the capability of checking whether a certain action by a third party (eg: access an end user’s account balance) is valid according to the consent granted by the end user to that TPP,  but also the availability of tools for end users to check existing consents, modify them or revoke them, as well as tools for financial institutions to perform similar actions on behalf of their customers.

Finally, we need an Identity Platform capable of authenticating an end user and establishing their identity.

A Google Cloud based embedded finance solution uses Apigee as the API management platform, Identity Platform or your own identity platform of choice, and a consent management service (CMS).  Google Cloud has partnered with two leading providers in the consent management space: Clarip and CloudEntity.

How do these components work together?

The main roles and responsibilities of each of the three components are quite clear, but there is a certain degree of flexibility on how to orchestrate the interactions between the components, and which component performs which function when there is an overlap of functionality between them.

Google Cloud has tested the following interaction patterns:

• Interaction Pattern #1: Apigee as the main orchestrator

In this interaction pattern, Apigee interacts with both the consent management service and the identity platform, coordinating end user authentication with the identity platform, and authorization and consent with the consent management service. Apigee acts as the “broker” between users, their identity, and their consent.

• Interaction Pattern #2: The consent management service abstracts the identity platform.

In this case, the consent management service manages all the interactions with the identity management platform, and the identity platform acts as the “broker”. Apigee only interacts with the consent service.

The three components share a common pool of client apps and end users. One of the components is typically designated as the source of truth for these entities, while the other components that need to know about these entities synchronize that information from the source of truth. 

The identity platform is typically the source of truth for end user identities and the consent management component will synchronize that information by pulling it from the identity platform. 

The consent management service is the source of truth for user opt-in and current consent status. Apigee will either check with the service the validity of a consent every time a request comes through, or to make it more efficient, it will validate the main attributes of the consent based on information stored in Apigee. To maintain consistency, the consent management service should tell Apigee to invalidate any tokens associated with a consent when it is revoked via other means (for example, if an end user revoked consent from a consent dashboard).

For client apps, either Apigee or the consent management component can act as the source of truth, with the other component synchronizing the information. In the context of Open Banking in particular, standards often mandate that financial institutions support Dynamic Client Registration. This means having endpoints that new clients can use to register themselves as clients for the Open Banking APIs. In this case, the synchronization of clients can easily be incorporated into Dynamic Client Registration.

Let’s look now into more detail about how the three components interact. There are two user journeys that are particularly relevant:

Authentication/Authorization/Consent

This is the beginning of the typical consumer client journey, when an end user starts using a third party app that requires access to that user’s data. The third party app needs to authenticate itself, and request authorization to access the user’s data. This will trigger the authentication of the end user and consent granting: Consent granting being the process of, the user authorizing the operations the app will execute on their behalf, and establishing the list of accounts on which these operations will be performed. The authorization is represented by an access token, which the app will need to include in all subsequent requests.

This is quite a complex journey with many steps involved in order to make this as secure as possible. To make it easier to understand, we will simplify some of the steps (apologies in advance to you OIDC/FAPI experts out there!).

At a high level, these are the steps involved in this user journey:

1. End user starts using an app
2. The app requests permission to access user’s data
3. The identity platform (IdP) authenticates the end user
4. The consent management service obtains consent from end user
5. An access token is issued for the app, encapsulating the authorized permissions, accounts, etc. A refresh token is also issued – the access token normally has a short life (measured in minutes), but the app can use the refresh token, which typically lasts much longer (days or months), in order to obtain a new access token without the need of going through the end user authentication/authorization/consent process again.

The way these steps are orchestrated varies depending on the interaction pattern among the components.

Pattern #1: Apigee orchestrates all interactions
When the client requests permission, Apigee will record the request and then redirect the client app to the IdP login page. Once the end user logs in, the IdP will return an authorization code to the callback URL that Apigee registered in the IdP configuration.

Apigee will then redirect the client app to the Consent Management service, so that the consent form is displayed. Once the user grants consent, selects the desired permissions, and selects the accounts it will apply to, the Consent Management Service will update Apigee with the status of the consent, via a callback Apigee registered in the consent configuration.

Now that the end user has authenticated and granted consent, Apigee can now issue an authorization code, and associate all the necessary information, for instance, details about the consent, the authorization code issued by the Identity Platform (IdP), the identification of the end user in the IdP, etc. Apigee will return this authorization code to the client app via a callback endpoint that the app provided when registering with Apigee.

The app will then exchange the authorization code for an access token. Apigee will obtain an access token from the IdP, abd update the status of the consent before issuing an access token to the client.

Pattern #2: The Consent Management Service is the center of the Architecture
In Pattern #2, Apigee will only communicate with the Consent Management Service, which acts as an authorization server for the app and will also coordinate all interaction with the IdP.

When the client requests permission, Apigee will forward the request to the CMS. The CMS will record the request and then redirect the client app to the IdP login page. Once the end user logs in, the IdP will return an authorization code to the callback the CMS registered in the IdP configuration.

The CMS then displays the consent form. Once the user approves the consent and selects the desired permissions and accounts it will apply to, the Consent Management Service will return an authorization code to Apigee, via a callback Apigee registered in the CMS configuration.

From now on, the flow is the same as explained above. Apigee will issue an authorization code, associate all the necessary information and will return this authorization code to the client app via a callback endpoint. The app will then exchange the authorization code for an access token. Apigee will obtain an access token from the CMS, before issuing an access token to the client.

Let’s now look at the other relevant user journey:

Access shared data 

Once the third party app has been authorized, it will then start requesting that end user’s data. For instance, it may request the list of accounts or the balance of a particular account. 

When that request goes through, a series of checks need to be performed: Is this third party app still authorized? Has it been granted the right permission for the operation being requested? Is the account involved included in the list of accounts authorized by the end user? Apigee can perform all these checks by inspecting the access token presented by the third party app. 

There is, however, one other check which cannot be done simply by inspecting the token. Imagine for a moment that in-between the user granting consent and the app requesting the user’s data, the end user decided to revoke that consent. This could be done by other means than the app itself, for instance by checking all consents granted to all apps in a consent dashboard accessible via other channels such as an “Internet Banking” site. When the app requests the user data, the token is still valid, however the consent has already been revoked. Therefore, in this user journey, Apigee will check with the Consent Management service to check if the consent is still valid. This adds a bit of overhead, which can be minimized by other means. For instance, one popular optimization is to make sure that the Consent Management service asks Apigee to revoke any access or refresh tokens associated with a given consent when that consent is revoked via other channels. If that guardrail is in place, then Apigee can determine if a request should be allowed simply by validating the access token and using the consent information stored alongside the token.

The following diagram summarizes the interactions required between Apigee and the Consent Management component. The interaction is essentially the same in both interaction patterns.

What’s next?

In this article we have described how Apigee, a Consent Management service, and an Identity Platform are the fundamental ingredients of a successful and secure Embedded Finance solution. We have also looked at how these components interact with each other to keep user consent consistent and available. Both interaction patterns described are valid and have been proven to work. So which one may be right for you? The answer ultimately depends on your particular requirements, the choice of consent management service, and your choice of identity platform. As a rule of thumb, if you have multiple application experiences, identity systems, and sources of consent, an Apigee-centric architecture is a great solution. If you are looking at a Consent Management service in the context of an Open Banking implementation mandated by a centralized authority (eg: Open Banking Brazil, Consumer Data Standards in Australia), CloudEntity is a good choice for consent management, as their product is also Certified Financial-grade API (FAPI) OpenID Provider, with profiles for the various Open Banking standards. CloudEntity integrates with Apigee using Pattern #2. 

For more details on both Clarip and CloudEntity’s offerings and how their particular solution works with GCP please check:

• Clarip: Universal Consent Management Platform – GDPR
• CloudEntity: Certified OpenBanking  & Consent (UK, Brazil and Australia) at scale

For more details on Apigee API Management, see https://cloud.google.com/apigee

You can also learn about our solutions for retail banking or contact sales.

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