Introduction

The Google Cloud Professional Services Organization’s (PSO) mission is to help our customers get the most out of Google products. PSO is responsible for customer success by sharing our technical expertise in order to unlock business value from the cloud by providing cloud strategy and best practice advice, implementation guidance, and training using our proven methodology. 

In this blog post, we want to focus specifically on Operational Health Reviews and how PSO engages in a myriad of activities to ensure the overall success and health of a customer engagement while ensuring we are meeting customer expectations and objectives, managing risk, and ultimately delivering value during or after the Google Cloud migration. We will discuss the assets, methodology, and tools that we leverage to ensure this success.

What is an Operational Health Review and what purpose does it serve?

Operational Health Reviews (OHR) are regular reviews to proactively address the below topics: 

• A customer’s support experience
• Analysis of trends in key operational metrics
• Analysis of trends in Google Cloud usage
• Status reports for high-priority cloud projects
• Discussion of upcoming events
• Discussion of potential opportunities for training
• Review of feature requests

The core aim of an OHR is to measure progress and advise customers on the overall health of the account and migration progress while providing recommendations as a team on what adjustments should be considered to ensure continued success. During the OHR, we will address any pain points as well as identify and remediate any negative trends in support interfaces and usage metrics. 

The intention of the activity is to also perform a blameless reflection for continuous improvement. This supports the effort to maintain common ground and obtain mutual optimism for the next phase of the customer’s journey on Google Cloud. 

Let’s dive a little deeper into some of the activities that go into an OHR. 

Support experience

One of the Google Cloud’s Support Organization’s goals is to simplify and streamline our customer’s support experience with a scalable and flexible set of offerings built with the customer needs at the center. This includes supporting an ongoing partnership model, with a proactive and collaborative approach. Premium Support is our top-tier support model which is a paid support offering designed for enterprises that run mission critical workloads and require fast response times, platform stability, and increased operational efficiencies. As part of this offering, customers are provided with a Technical Account Manager (TAM) who is in charge of delivering frequent touchpoints, including OHRs. 

During the support experience section of an OHR, some of the following topics may be reviewed:

• Case volume by priority
• Case volume by product
• Cases linked to Google Cloud incidents
• Escalated cases or incidents
• Case initial response time (IRT)
• Case IRT SLO Met Rate
• Case total resolution time (TRT) hours

The purpose of this activity is to better understand the efficiency of both the customer’s and Google’s cloud operations from a support trend perspective. The goal is to celebrate any positive trends, but also to identify potential negative trends and proactively determine a remediation strategy. 

Status reports for high-priority cloud projects

The purpose of this part of the OHR is to ensure the senior management stakeholders have continued visibility into the status of all their high-priority cloud initiatives with an easy-to-read, sometimes color-coded assessment on the status of each project. The assessment [Figure 1] may include, but is not limited to potential identified risks, key next steps, key stakeholders, and a mitigation plan for any high priority issues that may occur during their migration engagement. Additionally, the TAM may also cover any upcoming milestones or events, as well as any potential anticipated future blockers [Figure 2]. 

Review trends in Google Cloud usage

This part of the OHR is meant to provide the customer with a holistic view of their overall Google Cloud usage. The purpose is to provide understanding around what products are being used on Google Cloud and also where cost is generally being allocated for overall cost management and budget tracking purposes. This can help customers with their overall cost optimization efforts. Some of the metrics we may cover in this section are:

• Current Google Cloud usage by service
• Google Cloud growth trends
• Google Cloud growth trends by service
• Google Cloud growth trends by project
• Review of used and available service credits

Feature request review and advocacy

TAMs will work with customers to help identify product needs and advocate for feature requests with Google Product Management and Engineering teams. While feature request advocacy is an ongoing activity, during the OHR, the TAM will review any high priority feature requests that have previously been submitted, providing updates on status including potential release dates. 

When a feature is coming up for the release, the TAM can help the customer prepare for implementation (providing early Preview access, coordinating a meeting with the Product Manager to review the feature, etc.) and then continue to provide support until the feature is successfully implemented in the customer environment. Similarly, if a high priority or technical blocking feature is not yet coming available, the TAM can help offer an alternative solution that can unblock the customer in the short term. 

The OHR is also a great time for the TAM to work with the customer to ensure they have early access to new and exciting features that are in Alpha or Beta, and that would be beneficial to the customer and their environment. 

Training strategy

Training is a primary component to ensuring the overall success in adopting Google Cloud. During the OHR, a review of training metrics will be provided. This may include tracking metrics to determine how the customer is tracking towards an initially agreed upon learning plan or coming up with additional upskilling strategies as necessary. Additionally, throughout an engagement, the customer’s TAM will provide opportunities for both free and paid Google Cloud training. 

Conclusion 

PSO is the voice of customer health, maintaining priority to proactively and strategically guide large enterprise customers to operate effectively and efficiently in the cloud, both during and after the migration process. The OHR is an efficient and effective way to maintain alignment, ensure expectations and objectives are being met, manage risk, and overall ensure the success of the customer.

Learn more about our methodology and get started with Google Cloud by completing a free discovery and assessment of your migration. Alternatively, if you’d like to engage directly with our PSO team on your migration, contact us!

Editor’s note: Technology today lets companies of any size take on entire industries simply with an innovative business model plus digital distribution. Take Shine, a French startup whose platform helps freelancers manage their finances — and their administrative commitments. Here, Raphael Simon, Shine’s CTO and co-founder, talks about why Shine built a new bank on Google Cloud Platform, and in particular Cloud Spanner.

More and more people are deciding to take the plunge and start a freelance career. Some of them by choice, others out of necessity. One of their biggest pain points is dealing with administrative tasks.

In some countries, especially in Europe, the administrative burden of being a freelancer is similar to what a company of 10 or more people deals with. A freelancer doesn’t necessarily have the time or skills to manage all this paperwork. So we are building a new bank for freelancers from the ground up that helps automate administrative tasks associated with their business.

Shine’s banking services and financial tools make it as easy to work as a freelancer as it is to work for a larger company. We deal with administrative tasks on behalf of the freelancer so that he or she can focus on their job: finding and wowing clients.

Building our infrastructure 

As a new bank, we had the opportunity to build our infrastructure from the ground up. Designing an infrastructure and choosing a database presents tough decisions, especially in the financial services world. Financial institutions come under tremendous scrutiny to demonstrate stability and security. Even a tiny leak of banking data can have tremendous consequences both for the bank and its clients, and any service interruption can trigger a banking license to be suspended or a transaction to be declined.

At the same time, it’s vital for us to optimize our resources so we can maximize the time we spend developing user-facing features. In our first six months, we iterated and validated a prototype app using Firebase, and secured our seed funding round (one of the largest in Europe in 2017).

Based on our positive experience with Firebase, plus the ease-of-use and attractive pricing that Google Cloud offered, we decided to build our platform on Google Cloud Platform (GCP).

We were drawn to GCP because it has a simple, consistent interface that is easy to learn. We chose App Engine flexible environment with Google Cloud Endpoints for an auto-scaling microservices API. These helped us reduce the time, effort, and cost in terms of DevOps engineers, so we could invest more in developing features, while maintaining our agility.

We use Cloud Identity and Access Management (Cloud IAM) to help control developer access to critical parts of the application such as customer bank account data. It was quite a relief to lean on a reliable partner like Google Cloud for this.

Database decisions 

Next came time to choose a database. Shine lives at the financial heart of our customers’ businesses and provides guidance on things like accounting and tax declaration. The app calculates the VAT for each invoice and forecasts the charges they must pay each quarter.

Due to the sensitivity of our customers’ data, the stakes are high. We pay careful attention to data integrity and availability and only a relational database with support for ACID transactions (Atomicity, Consistency, Isolation, Durability) can meet this requirement.

At the same time, we wanted to focus on the app and user experience, not on database administration or scalability issues. We’re trying to build the best possible product for our users, and administering a database has no direct value for our customers. In other words, we wanted a managed service.

Cloud Spanner combines a globally distributed relational database service with ACID transactions, industry-standard SQL semantics, horizontal scaling, and high availability. Cloud Spanner provided additional security, high-availability, and disaster recovery features out-of-the-box that would have taken months for us to implement on our own. Oh, and no need to worry about performance — Cloud Spanner is fast. Indeed, Cloud Spanner has been a real asset to the project, from the ease-of-use of creating an instance to scaling the database.

Cloud Spanner pro tips 

We began working with Cloud Spanner and have learned a lot along the way. Here are some technical notes about our deployment and some best practices that may be useful to you down the road:

• Cloud Spanner allows us to change a schema in production without downtime. We always use a NOT NULL constraint, because we generally think that using NULL leads to more errors in application code. We always use a default value when we create an entity through our APIs and we use Cloud Dataflow to set values when we change a schema (e.g., adding a field to an entity). 
• With microservices, it’s generally a good practice to make sure every service has its own database to ensure data isolation between the different services. However, we adopted a slightly different strategy to optimize our use of Cloud Spanner. We have an instance on which there are three databases — one for production, one for staging and one for testing our continuous integration (CI) pipeline. Each service has one or more interleaved tables that are isolated from others services’ tables (we do not use foreign-keys between tables from different services). This way our microservices data are not tightly “coupled”. 
• We created an internal query service that performs read-only queries to Cloud Spanner to generate a dashboard or do complex queries for analytics. It is the only service where we allow joins between tables across services. 
• We take advantage of Cloud Spanner’s scalability, and thus don’t delete any data that could one day be useful and/or profitable. 
• We store all of our business logs on Cloud Spanner, for example connection attempts to the application. We append the ‘-Logs’ suffix to them. 
• When possible, we always create an interleave. 

 In short, implementing Cloud Spanner has been a good choice for Shine:

• It’s saved us weeks, if not months, of coding. 
• We feel we can rely on it since it’s been battle-tested by Google. 
• We can focus on building a disruptive financial services product for freelancers and SMBs.

And because Cloud Spanner is fully managed and horizontally scalable, we don’t have to worry about hardware, security patches, scaling, database sharding, or the possibility of a long and risky database migration in the future. We are confident Cloud Spanner will grow with our business, particularly as we expand regionally and globally. I strongly recommend Cloud Spanner to any company looking for a complete database solution for business-critical, sensitive, and scalable data.

From data centers and cloud regions to subsea cables, Google is committed to connecting the world. Our investments in infrastructure aim to further improve our network—one of the world’s largest—which helps improve global connectivity, supporting  users and Google Cloud customers. Our subsea cables play a starring role in this work, linking up cloud infrastructure that includes more than 100 network edge locations and over 7,500 edge caching nodes. 

As it turns out, readers of this blog seem to find what happens under the sea just as fascinating as what’s going on in the cloud. Posts on our cables are consistently among our most popular, which is why we brought them together for you here so you can take a deeper dive (pun intended).

Here’s a list our most popular posts on our underwater infrastructure:

2021

• Hola, South America! Announcing the Firmina subsea cable
• This bears repeating: Introducing the Echo subsea cable
• The Dunant subsea cable, connecting the US and mainland Europe, is ready for service

2020

• Announcing the Grace Hopper subsea cable, linking the U.S., U.K. and Spain

2019

• Introducing Equiano, a subsea cable from Portugal to South Africa
• A quick hop across the pond: Supercharging the Dunant subsea cable with SDM technology
• Curie subsea cable set to transmit to Chile, with a pit stop to Panama

2018

• Expanding our cloud network for a faster, more reliable experience between Australia and Southeast Asia
• Delivering increased connectivity with our first private trans-Atlantic subsea cable

2017

• Google invests in INDIGO undersea cable to improve cloud infrastructure in Southeast Asia

2016

• New undersea cable expands capacity for Google APAC customers and users
• Google Cloud customers run at the speed of light with new FASTER undersea pipe
• A journey to the bottom of the internet

Our cable systems provide the speed, capacity and reliability Google is known for worldwide, and at Google Cloud, our customers can make use of the same network infrastructure that powers Google’s own services. To learn more, you can view our network on a map, or read more about our network.