At Google Cloud, we’re committed to making artificial intelligence (AI) accessible to everyone and easier to harness for new use cases.  That’s why we’re excited to announce the general availability of our intuitive, new visual user interface for Google Cloud’s Speech-to-Text (STT) API, right in Google Cloud Console, which makes the API much simpler and easier for developers to use.  

The STT API lets developers convert speech into text by leveraging Google’s years of research in automatic speech recognition and transcription technology. As advancements in AI continue to bring speech to new interfaces and devices, the STT API helps developers add speech functionality to their applications in order to better meet consumer demands. 

The STT API covers a wide variety of use cases, from dictation and short commands, to captioning and subtitles. Getting the most of STT, however, can be a complicated process. To achieve the highest accuracy on any AI use case requires careful testing and tuning. 

Previously, developers building on the STT API had to do this work manually by carefully experimenting with our API. Just to get started, developers needed familiarity with GCP integration concepts and had to either build their own tools or manage various scripts and API calls to fully understand the API documentation.  These actions required cumbersome and time-consuming effort and made measuring, customizing, and improving models even more difficult.  

Today’s announcement significantly simplifies the process, facilitating iteration and integration of models into developers’ applications by letting developers perform every API function from within the Google Cloud Console.  These tools will make it easier for developers to integrate the STT API with their products or services. This update also gives developers the ability to manage and quickly iterate on their STT model customizations with Model Adaptation.

Model Adaptation allows developers to customize STT specifically for their domains or use cases. Developers can maintain lists of words and weights that will be applied to either every request or just single requests, depending on their needs. Model adaptations are reusable and composable, so once developers have seen good results in the STT Cloud Console, they can deploy to their entire solution. 

The Speech-to-Text Cloud Console and Model Adaptation API is available now in all Google Cloud regions and languages and is accessible to all GCP users with no additional cost to that of the underlying API usage. The STT API supports over 70 languages in 120 different local variants. If you’re a developer looking for an easy to use, easy to integrate, and high-quality STT experience, sign up for our free trial and try our new interface on your own datasets today!

Apps play a critical role in an ever-expanding range of healthcare services, as patients and providers increasingly expect streamlined, engaging digital experiences. This means that IT must become faster, more agile, and free from the constraints of everyday infrastructure management.

At Cardinal Health, we are continuously enhancing our technology to empower innovators across our organization as they strive to build connections across the continuum of care. Through our efforts, we have adopted a continuous integration and continuous delivery (CI/CD) pipeline that powers breakthroughs and drives innovation. Our CI/CID pipelines use a combination of Cloud Build for foundational elements, as well as our internal DevSecOps platform, NitroDX, to deploy our application workloads built on Google Cloud.

This CI/CD pipeline powered the development of our Pharmacy Marketing Advantage (PMA) Commerce, which was built from the ground up on Google Kubernetes Engine (GKE), to provide independent pharmacists with a digital platform that expands online shopping capabilities for patients by offering more than 11,000 over-the-counter products. We also replatformed our Order Express tool, which is a simple, reliable web ordering application for independent pharmacists, from on-prem to Google Compute Engine and GKE, which allowed us to shift from quarterly releases to weekly on-demand releases.

Our application teams work in close alignment with our product teams and handle everything from basic software updates to more advanced cloud-native app development. We place tremendous value on our ability to empower our application teams, and we invest in tools and technologies to make them as efficient and successful as possible.

As part of our efforts to optimize applications and deliver engaging digital experiences for our customers and their patients, we saw the value of rethinking our approach to storage and overall IT administration. Working with the NetApp Cloud Volume Service (CVS), a fully managed storage service, and Google Cloud, we fundamentally changed our IT capabilities.

Accelerating app development

As a cloud-first company, Cardinal Health has embraced a managed approach to IT provisioning in many areas. When we offload responsibilities like infrastructure maintenance, patching, and updates, we enable our developers to focus on continuous innovations that directly impact the quality of patient and provider experiences.

We’ve made measurable progress in automating our CI/CD pipelines to simplify provisioning Virtual Machines (VMs), managing firewall rules, launching Google Cloud projects, and more. Our NitroDx platform also significantly reduced development time from weeks to minutes, improving the software delivery process and accelerating digital transformation.

Google Cloud is our primary cloud services vendor and has removed much of the heavy lifting related to server provisioning, firmware patches, and similar tasks. We rely on a mix of Google Cloud services, including Compute Engine, GKE, BigQuery, and Vertex AI to deliver patient-centric solutions. We also work closely with partners like NetApp to improve our storage management at a much greater scale and more efficiently than we could do on our own.

By using a combination of NetApp and Google Cloud solutions, we’ve been able to decouple storage from our underlying infrastructure to make better use of our resources and accelerate app development. When running on-prem, shared storage proved to be a time and resource drain.

If an application needed shared storage in our legacy on-prem environment, we had to communicate the requirements to an engineer and create a change control. And even then, if all staff and funding were in place to support the change, it would take weeks to complete. This held up projects and delayed our time to market.

We quickly overcame this challenge with NetApp CVS. Through this tool, we can delegate permissions directly within a teams’ Google Cloud project, allowing them to administer their own shared volumes. This translates to on-demand shared storage without operational complexities or the need for dedicated teams to manage it.

We were an early adopter of NetApp CVS, and we’re happy to have made that decision. In addition to cost savings and faster time-to-market, we can now provide our staff with more professional development opportunities. The team members who made up the dedicated storage team now work across the cloud organization, focused on innovation and enablement rather than maintenance.

A stronger foundation for developers to stand on

We constantly work to fill gaps at any point in the developer experience. Containerizing our apps and deploying to GKE has been a major part of this process, driving efficiencies through consolidation and improving our processes to keep our operating systems patched, updated and maintained.

In the past, it was also difficult for us to get reproducible or CI/CD pipelines into our application spaces. Now, we make things easier for application teams as we can provide a CI/CD pipeline for the containers themselves, automating more of the underlying technology to keep developers moving forward.

As we shift more traditional virtual machine (VM) workloads into GKE and leverage NetApp CVS for shared storage, our developers can more easily plug into file-based services. This further accelerates app development and deployments and fuels a more easily managed, efficient CI/CD framework focused on value, not system maintenance.

Smart, data-driven decisions

We’ve been impressed by how quickly we can aggregate data, analyze it, and uncover insights with BigQuery, Vertex AI, and Dataproc — at a speed that would not have been possible without Google Cloud. Vertex AI pipelines helped us automate and standardize our ML operations so data scientists can focus on innovating code vs. managing deployments. This allowed us to make improvements in areas such as more accurately predicting market demand and providing more relevant product recommendations to our customers.

To date, Google Cloud has collaborated with us on many projects, giving us access to early-release products, listening to our needs, and applying our feedback to their product development. Likewise, NetApp continues to work closely with us to expand what is possible with NetApp CVS, particularly with the types of data we can store and the ability to manage it easily.

It’s an excellent partnership, and our work with Google Cloud and NetApp helps us redefine the possibilities of app modernization in healthcare. We can continue to push boundaries of speed, agility, and success of CI/CD pipelines. It’s exciting to see what we are accomplishing today and what we’ll do in the future to constantly improve our customer’s digital experience.

Learn how integrated solutions with NetApp on Google Cloud can help you unlock the full potential of your data.

Imagine ordering a “ready-to-assemble” table online, only to find that the delivery package did not include the assembly instructions. You know what the end product looks like, but have little to no clue how to start assembling the individual pieces to get there. A poorly designed API tends to create a similar experience for a consumer developer. Well designed APIs make it easy for consumer developers to find, explore, access, and use them. In some cases, good quality APIs even spark new ideas and open up new use cases for consumer developers.

There are methods to improve API design — like following RESTful practices. But time and again we are seeing customers unknowingly program minor inconveniences into their APIs. To help you avoid these pitfalls, here are six of the most common mistakes we have seen developers make while creating the API — and guidance on how to get it right.

#1 Thinking inside-out vs outside-in

Being everything for everybody often means that nothing you do is the best it could be, and that is just as true for APIs. When customers turn to APIs, they are looking for specific solutions to make their work easier and more productive. If there is an API that better works to their needs, they will choose that one over yours. This is why it’s so important to know what your customers need to do their work better, and then building to fill those needs. In other words, start thinking Outside-in as opposed to Inside-Out. Specifically,

• Inside-out refers to designing APIs around internal systems or services you would like to expose.
• Outside-in refers to designing APIs around customer experiences you want to create. Read more about the Outside-in perspective in the API product mindset.

The first step to this is learning from your customers — be it internal consumer developers or external customers — and their use cases. Ask them about the apps they are building, their pain points, and what would help streamline or simplify their development. Write down their most significant use cases and create a sample API response that only gives them the exact data they need for each case. As you test this, look for overlap between payloads and adapt your designs to genericize them across common or similar use cases.

If you can’t connect with your customers — because you don’t have direct access, they don’t have time, or they just don’t know what they want — the best approach is to imagine what you would build with your APIs. Think big and think creatively. While you don’t want to design your APIs for vaporware, thinking about the big picture can make it easier to build non-breaking changes in the future. For example the image below showcases APIs offered by Google Maps. Even without diving into the documentation, looking at the names like “Autocomplete” or “Address Validation” clearly outlines the purposes and potential fit for a customer’s use case.

#2 Making your APIs too complex for users

Customers turn to APIs to bypass complicated programming challenges so they can get to the part they know how to do well. If they feel like using your API means learning a whole new system or language, then it isn’t fitting their needs and they will likely look for something else. It’s up to your team to make an API that is strong and smart enough to do what your customer wants, but also simple enough to hide how complicated the tasks your API solves for really are. For example if you know your customers are using your APIs to present information about recently open restaurants and highly rated pizzeria to their consumers, providing them with a simple API call as below would be of great help:

GET /restaurants?location=Austin&category=Pizzeria&open=true&sort=-priority,created_at

To see if your API design is simple enough, pretend you are building the whole system from scratch — or if you have a trusted customer who is willing to help, ask them to test it and report their results. If you can complete the workflow without having to stop to figure something out, then you’re good to go. On the other hand, if you catch rough edges caused by trying to code around system complexity issues, then keep trying to refactor. The API will be ready when you can say that nothing is confusing and that it either meets your customers’ needs or can easily be updated as needs change.

#3 Creating “chatty” APIs with too many calls

Multiple network calls slow down the process and creates higher connection overhead — which means higher operational costs. This is why it’s so important to minimize the number of API calls.

The key to this is outside-in design: simplify. Look for ways to reduce the number of API calls a customer must make in their application’s workflow. If your customers are building mobile applications, for example, they often need to minimize their network traffic to reduce battery drain, and requiring a couple calls instead of a dozen can make a big difference.

Rather than deciding between building distinct, data-driven microservices and streamlining API usage, consider offering both: fine-grained APIs for specific data types, and “experience APIs” (APIs that are designed to power user experiences. Here is a further theoretical discussion on Experience APIs) around common or customer-specific user interfaces. These experience APIs compose multiple smaller domains into a single endpoint; making it much simpler for your customers — especially those building user interfaces — to render their screens easily and quickly.

Another option here is to use something like GraphQL to allow for this type of customizability. Generally you should avoid building a unique endpoint for every possible screen, but common screens like home pages and user account information can make a world of difference to your API consumers.

#4 Not allowing for flexibility

Even if you’ve followed all of the steps above, you may find that there are edge cases that do not fit under your beautifully designed payloads. Maybe your customer needs more data in a single page of results than usual, or the payload has way more data than their app requires. You can’t create a one-size-fits-all solution, but you also don’t want a reputation for building APIs that are limiting. Here are 3 simple options to make your endpoints more flexible.

Filter out response properties: You can either use query parameters for sorting and pagination, or use GraphQL which provides these types of details natively. By giving customers the option to request only the properties they need, it guarantees that they won’t have to sort through tons of unnecessary data to get what they need. For example, if some of your customers only need the title, author, and bestseller ranking, give them the ability to retrieve only that data with a query string parameter.

GET /books?fields=title,author,ranking

• Ability to sort with pagination. Generally, you don’t want to guarantee the order of objects in an API response because minor changes in logic or peculiarities in your data source might change the sort order at some point. In some cases, however, your customers may want to sort by a particular field. Giving them that option, combined with a pagination option, will give them a highly efficient API when they only want the top few results. For example Spotify API utilizes a simple offset and limit parameter set to allow pagination. A sample endpoint as shown in the documentation would look like this

$ curl https://api.spotify.com/v1/artists/1vCWHaC5f2uS3yhpwWbIA6/albums?album_type=SINGLE&offset=20&limit=10

• Use mature compositions like GraphQL: Since customer data needs can differ, giving them on-the-fly composites lets them build to the combinations of data they need, rather than being restricted to a single data type or a pre-set combination of data fields. Using GraphQL can even bypass the need to build experience APIs, but when this isn’t an option, you can use query string parameter options like “expand” to create these more complex queries. Here is a sample response that demonstrates a collection of company resources with embedded properties included

"data": [
{
"CompanyUid": "27e9cf71-fca4",
"name": "ABCCo",
"status": "Active",
"_embedded": {
"organization": {
"CompanyUid": "27e9cf71-fca4",
"name": "ABCCo",
"type": "Company",
"taxId": "0123",
"city": "Portland",
"notes": ""
}
}
}
]

#5 Making design unreadable to humans

“K”eep “I”t “S”imply “S”tupid when you are designing your API. While APIs are meant for computer-to-computer interaction, the first client of an API is always a human, and the API contract is the first piece of documentation. Developers are more apt to study your payload design before they dig into your docs. Observation studies suggest that developers spend more than 51% of their time in editor and client as compared to ~18% on reference.

For example, if you skim through the payload below it takes some time to understand because instead of property names it includes an “id”. Even the property name “data” does not suggest anything meaningful aside from just being an artifact of the JSON design. A few extra bytes in the payload can save a lot of early confusion and accelerate adoption of your API. Notice how user-ids appearing on the left of the colon (in the position where other examples of JSON ideally have property names) creates confusion in reading the payload.

"{id-a}":
{ "data":
[
{
"AirportCode": "LAX",
"AirportName": "Los Angeles",
"From": "LAX",
"To": "Austin",
"departure": "2014-07-15T15:11:25+0000",
"arrival": "2014-07-15T16:31:25+0000"
}
… // More data
]
},

We think that JSON like this is more difficult to learn. If you want to eliminate any ambiguity in the words you choose to describe the data, keep the payload simple and if any of those labels could be interpreted in more than one way, adjust them to be more clear. Here is a sample response from Airlines endpoint of aviationstack API. Notice how the property names clearly explain the expected result while maintaining a simple JSON structure.

"data": [
{
"airline_name": "American Airlines",
"iata_code": "AA",
"iata_prefix_accounting": "1",
"icao_code": "AAL",
"callsign": "AMERICAN",
"type": "scheduled",
"status": "active",
"fleet_size": "963",
"fleet_average_age": "10.9",
"date_founded": "1934",
"hub_code": "DFW",
"country_name": "United States",
"country_iso2": "US"
},
[…]
]

#6 Know when you can break the RESTful rules

Being true to the RESTful basics — such as using the correct HTTP verbs, status codes, and stateless resource-based interfaces — can make your customers’ lives easier because they don’t need to learn an all new lexicon, but remember that the goal is just to help them get their job done. If you put RESTful design first over user experience, then it doesn’t really serve its purpose.

Your goal should be helping your customers be successful with your data, as quickly and easily as possible. Occasionally, that may mean breaking some “rules” of REST to offer simpler and more elegant interfaces. Just be consistent in your design choices across all of your APIs, and be very clear in your documentation about anything that might be peculiar or nonstandard.

Conclusion

Beyond these common pitfalls, we have also created a comprehensive guide packaging up our rich experience designing and managing APIs at incredible scale with Google Cloud’s API management product, Apigee.

Apigee — Google Cloud’s native API management platform — helps you build, manage, and secure APIs — for any use case, scale or environment. Get started with Apigee today or check out our documentation for additional information.

Editor’s note: Today we hear from ForgeRock, a multinational identity and access management software company with more than 1,100 enterprise customers, including a major public broadcaster. In total, customers use the ForgeRock Identity Platform to authenticate and log in over 45 million users daily, helping them manage identity, governance, and access management across all platforms, including on-premises and multicloud environments. 

Operating at that kind of scale isn’t easy. In this blog post, ForgeRock Engineering Director, Warren Strange discusses the three things that help make their developers efficient and productive, and the Google Cloud tools they use along the way. 

At ForgeRock, we’ve been an early adopter of Kubernetes, viewing it as a strategic platform. Running on Kubernetes allows us to drive multicloud support across Google Kubernetes Engine (GKE), Amazon (EKS), and Azure (AKS). So no matter which cloud our customers are running on, we are able to seamlessly integrate our products into customers’ environments. 

Making it easier for ForgeRock’s developers and operators to build, deploy and manage applications has been crucial in our ability to continually provide high quality solutions for our customers. We’re always looking for tools to improve productivity and keep our developers focused on coding instead of configuration. Google Cloud’s suite of DevOps tools have streamlined three specific practices to help keep our developers productive: 

1. Make developers productive within IDEs

Developer productivity is core to the success of any organization, including ForgeRock. Since developers spend most of their time within their IDE of choice, our goal at ForgeRock has been to make it easier for our developers to write Kubernetes applications within the IDEs they know and love. Cloud Code helps us precisely with that: it makes the process of building, deploying, scaling, and managing Kubernetes infrastructure and applications a breeze. 

In particular, working with the Kubernetes YAML syntax and schema takes time, and a lot of trial and error to master. Thanks to YAML authoring support within Cloud Code, we can easily avoid the complicated and time consuming task of writing YAML files at ForgeRock. With YAML authoring support, developers save time on every bug. Cloud Code’s inline  snippets, completions, and schema validation, a.k.a. “linting,” further streamline working with YAML files. 

The benefits of Cloud Code extend to local development as well. Iterating locally on Kubernetes applications often requires multiple manual steps, including building container images, updating Kubernetes manifests, and redeploying applications. Doing these steps over and over again can be a chore. Cloud Code supports Skaffold under the hood, which tracks changes as they come and automatically rebuilds and redeploys—reducing repetitive development tasks. 

Finally, developing for Kubernetes usually involves jumping between the IDE, documentation, samples etc. Cloud Code reduces this context switching with Kubernetes code samples. With samples, we can get new developers up and running quickly. They spend less time learning about configuration and management of the application—and spend more time on writing and evolving the code.

2. Drive end-to-end automation

To further improve developer productivity, we’ve focused on end-to-end automation: from writing code within IDEs, to automatically triggering CI/CD pipelines and running the code in production. In particular, Tekton, Cloud Build, Container Registry, and GKE have been critical to Forgerock as we streamline the flow of code, feedback and remediation through the build and deployment processes. The process looks something like this:

We begin by developing Kubernetes manifests and dockerfiles using Cloud Code. Then we use Skaffold to build containers locally, while Cloud Build helps with continuous integration (CI). The Cloud Build GitHub app allows us to automate builds and tests as part of our GitHub workflow. Cloud Build is differentiated from other continuous integration tools since it is fully serverless. It scales up and scales down in response to load, with no need for us to pre-provision servers or pay in advance for additional capacity. We pay for the exact resources we use. 

Once the image is built by Cloud Build, it is stored, managed, and secured in Google’s Container Registry. Just like Cloud Build, Container Registry is serverless, so we only pay for what we  use. Additionally, since Container Registry comes with automatic vulnerability scanning, every time we upload a new image to Container Registry, we can also scan it for vulnerabilities. 

Next, a Tekton pipeline is triggered, which deploys the docker images stored in Container Registry and Kubernetes manifests to a running GKE cluster. Along with Cloud Build, Tekton is a critical part of our CI/CD process at ForgeRock. Most importantly, since Tekton comes with standardized Kubernetes-native primitives, we can create continuous delivery workflows very quickly.

After deployment, Tekton triggers a functional test suite to ensure that the applications we deploy perform as expected. The test results are posted to our team Slack channel so all developers have instant access and insights about each cluster. From there, we are able to provide our customers with their finished product request.

3.  Leverage multicloud patterns and practices

The industry has seen a shift towards multicloud. Organizations have adopted multicloud strategies to minimize vendor lock-in, take advantage of best-in-class solutions, improve cost-efficiencies, and increase flexibility through choice. 

At ForgeRock, we’re big proponents of multicloud. Part of that comes from the fact that our identity and access management product works across Google Cloud, AWS, and Azure. Developing products using open-source technologies such as Kubernetes has been particularly helpful in driving this interoperability. 

Tekton has been another critical project that has allowed us to prevent vendor lock-in. Thanks to Tekton, our continuous delivery pipelines can deploy across any Kubernetes cluster. Most importantly, since Tekton pipelines run on Kubernetes, these pipelines can be decoupled from the runtime. Like Tekton and Kubernetes, both Cloud Build and Container Registry are based on open technologies. Community-contributed builders and official builder images allow us to connect to a variety of tools as a part of the build process. And finally, with support for open technologies like Google Cloud buildpacks within Cloud Build, we can build containers without even knowing Docker. 

Making it easier for developers and operators to build, deploy and manage applications is critical for the success of any organization. Driving developer productivity within IDEs, leveraging end-to-end automation, and support for multi-cloud patterns and practices are just some of the ways we are trying to achieve this at ForgeRock. To learn more about ForgeRock, and to deploy the ForgeRock Identity Platform into your Kubernetes cluster, check out our open-source ForgeOps repository on GitHub.

Modern developers worldwide have grown accustomed to the comfort of writing code, pushing to a remote Git repository and having that code be deployed at an accessible URL without having to worry about how it is deployed. This was a workflow popularized by Heroku years ago which brought joy and productivity to developers even if it did impose some loss of flexibility for operation teams.

To address that loss of flexibility when meeting security and integration requirements, Heroku introduced Private Spaces. Private Spaces provide network isolation from the internet since any application or datastore provisioned by Heroku is accessible to the internet by default.

Cloud Run is quickly becoming the “swiss army knife” of serverless here at Google Cloud and it’s a natural migration path for developers accustomed to Heroku. The fundamentals are all there:

• Continuously Deploy via Git push using open source Buildpacks or Dockerfiles
• Set CPU and Memory requirements for each instance
• Horizontally scalable apps that scale from zero to thousands of instances to meet traffic demands automatically

So while devs are kept happy, can Cloud Run do something for the Ops folks? Yes. Here are some things available right in the Cloud Run UI:

• Proper Secret Management with IAM based access control. No more setting secrets as environment variables.
• Traffic management between different revisions for blue-green or canary deployments.
• Define SLIs and SLOs with ease. Eg: 90% of requests have to be served under 200ms in a calendar month.
• Secure your service with tools such as Software Delivery Shield, Binary Authorization, and Cloud Armor. Definitely deserves its own blog post.

Recreating Private Spaces on Cloud Run

Let’s focus on network isolation now, let’s say you have an internet-facing app and a private backend API that talks to a private database. Simplest architecture ever, it conceptually looks a bit like this:

Let’s address the database first. If you want to use Postgres then Cloud SQL is most likely what you want, but do keep in mind that we have other datastores that speak Postgres such as AlloyDB and Spanner.

Cloud SQL allows you to create a Postgres instance that’s isolated from the internet by simply unchecking the Public IP checkbox and checking the Private IP checkbox. This will assign an IP address to your Postgres instance on your project’s network.

Once the DB is provisioned you’ll see the IP clearly listed, such as:

Of course there’s so much more to say about CloudSQL, to learn more please take a look at our documentation.

Ok now that you’ve dealt with Postgres, let’s address the private backend API on Cloud Run.

When creating a new Cloud Run service via the Google Cloud Console, Ingress can be limited to “Internal traffic only” so only traffic from internal sources, including your VPC, can access the service. In other words, the internet can not touch it.

As an additional level of security, it’s also possible to enforce that only requests from authorized users be served, In this case a “user” is most likely another service using its associated service account which will need the “roles/run.invoker” in order to call this service.

Now let’s make sure that our Backend API Service can reach the Postgres instance by configuring a VPC Connector. This will allow Cloud Run services to reach into the VPC and therefore, the internal IP for the Postgres instance.

Once the VPC Connector is created, you can associate it with a Cloud Run service.

Then it’s just a matter of configuring your code to use the Postgres instance’s private IP address. A good 12-Factor app friendly spot to do that is with a connection string in an environment variable as part of the Cloud Run service configuration. Better yet, as this may contain a DB password, you can use Secret Manager to mount this environment variable from an encrypted and protected secret.

Finally, let’s now set up that Front End Cloud Run service which will respond to requests from the internet, and securely communicate with the backend API service.

For the frontend service choose to “Allow all traffic” and also “Allow unauthenticated invocations” so anyone on the web can access our URL. We could of course choose the middle option and use Cloud Load Balancing in conjunction with Cloud Armor which provides defenses against DDoS and application attacks, and offers a rich set of WAF rules. However, let’s keep it simple for now.

Keep in mind that our Backend service will only accept requests from within our VPC network, and that we don’t have a private IP address for Cloud Run.

So let’s ensure that all egresses from our Frontend actually get routed to the VPC Connector, this way when our Frontend calls a Backend API via it’s URL endpoint, the Backend will receive the request from within the VPC and allow it in.

PS: If your Backend requires authentication don’t forget to create a Service Account for your Frontend Service and then give it the necessary role following a service-to-service auth pattern.

And that’s it. You now have an operationally acceptable private space like environment with an app composed of two Cloud Run services where the Backend service and Postgres instance are network isolated from the Internet. If after reading this blog you would like to get hands-on experience with the technologies mentioned above, then take a look at Google Cloud Skills Boost. There you will find learning paths, quests, and labs curated to boost your cloud skills in a particular area.

For example here’s a great lab that takes you through developing a REST API on Cloud Run using Go.