The ability to gain real-time insights from IoT data can redefine competitiveness for businesses. Intelligence allows connected devices and assets to interact efficiently with applications and with human beings in an intuitive and non-disruptive way. After your IoT project is up and running, many devices will be producing lots of data. You need an efficient, scalable, affordable way to both manage those devices and handle all that information. 

IoT Core is a fully managed service for managing IoT devices. It supports registration, authentication, and authorization inside the Google Cloud resource hierarchy as well as device metadata stored in the cloud, and the ability to send device configuration from other GCP or third-party services to devices. 

Main components

The main components of Cloud IoT Core are the device manager and the protocol bridges:

• The device manager  registers devices with the service, so you can then monitor and configure them. It provides:
  • Device identity management 
  • Support for configuring, updating, and controlling individual devices
  • Role-level access control
  • Console and APIs for device deployment and monitoring
• Two protocol bridges (MQTT and HTTP) can be used by devices to connect to Google Cloud Platform for:
  • Bi-directional messaging
  • Automatic load balancing
  • Global data access with Pub/Sub

How does Cloud IoT Core work?

Device telemetry data is forwarded to a Cloud Pub/Sub topic, which can then be used to trigger Cloud Functions as well as other third-party apps to consume the data. You can also perform streaming analysis with Dataflow or custom analysis with your own subscribers.

Cloud IoT Core supports direct device connections as well as gateway-based architectures. In both cases the real time state of the device and the operational data is ingested into Cloud IoT Core and the key and certificates at the edge are also managed by Cloud IoT Core. From Pub/Sub the raw input is fed into Dataflow for transformation, and the cleaned output is populated in Cloud Bigtable for real-time monitoring or BigQuery for warehousing and machine learning. From BigQuery the data can be used for visualization in Looker or Data Studio and it can be used in Vertex AI for creating machine learning models. The models created can be deployed at the edge using Edge Manager (in experimental phase). Device configuration updates or device commands can be triggered by Cloud Functions or Dataflow to Cloud IoT Core, which then updates the device.  

Design principles of Cloud IoT Core

As a managed service to securely connect, manage, and ingest data from global device fleets, Cloud IoT COre is designed to be:

• Flexible, providing easy provisioning of device identities and enabling devices to access most of Google Cloud
• IThe industry leader in IoT scalability and performance
•  Interoperable, with supports for the most common industry-standard IoT protocols

Use cases

IoT use cases range across numerous industries. Some typical examples include:

• Asset tracking, visual inspection, and quality control in retail, automotive, industrial, supply chain and logistics
• Remote monitoring and predictive maintenance in oil & gas, utilities, manufacturing, and transportation
• Connected homes and consumer technologies.
• Vision intelligence in retail, security, manufacturing, and industrial sectors
• Smart living in commercial, residential, and smart spaces 
• Smart factories with predictive maintenance and real-time plant floor analytics

 For a more in-depth look into Cloud IoT Core check out the documentation.  

https://youtube.com/watch?v=76v16P-Wqe4%3Fenablejsapi%3D1%26

For more #GCPSketchnote, follow the GitHub repo. For similar cloud content follow me on Twitter @pvergadia and keep an eye out on thecloudgirl.dev.

I previously talked about Eventarc for choreographed (event-driven) Cloud Run services and introduced Workflows for orchestrated services.

Eventarc and Workflows are very useful in strictly choreographed or orchestrated architectures. However, you sometimes need a hybrid architecture that combines choreography and orchestration. 

For example, imagine a use case where a message to a Pub/Sub topic triggers an automated infrastructure workflow or where a file upload to a Cloud Storage bucket triggers an image processing workflow. In these use cases, the trigger is an event but the actual work is done as an orchestrated workflow.

How do you implement these hybrid architectures in Google Cloud? The answer lies in Eventarc and Workflows integration. 

Eventarc triggers

To recap, an Eventarc trigger enables you to read events from Google Cloud sources via Audit Logs and custom sources via Pub/Sub and direct them to Cloud Run services:

One limitation of Eventarc is that it currently only supports Cloud Run as targets. This will change in the future with more supported event targets. It’d be nice to have a future Eventarc trigger to route events from different sources to Workflows directly. 

In absence of such a Workflows enabled trigger today, you need to do a little bit of work to connect Eventarc to Workflows. Specifically, you need to use a Cloud Run service as a proxy in the middle to execute the workflow. 

Let’s take a look at a couple of concrete examples.

Eventarc Pub/Sub + Workflows integration

In the first example, imagine you want a Pub/Sub message to trigger a workflow. 

Define and deploy a workflow

First, define a workflow that you want to execute. Here’s a sample workflows.yaml that simply decodes and logs the Pub/Sub message body:

  main:
  params: [args]
  steps:
    - init:
        assign:
          - headers: ${args.headers}
          - body: ${args.body}
...
    - pubSubMessageStep:
        call: sys.log
        args:
            text: ${"Decoded Pub/Sub message data is " + text.decode(base64.decode(args.body.message.data))}
            severity: INFO
Deploy the workflow with a single command:
gcloud workflows deploy ${WORKFLOW_NAME} --source=workflow.yaml --location=${REGION}

Deploy a Cloud Run service to execute the workflow

Next, you need a Cloud Run service to execute this workflow. Workflows has an execution API and client libraries that you can use for your favorite language. Here’s an example of the execution code from a Node app.js file. It simply passes the received HTTP request headers and body to the workflow and executes it:

  const execResponse = await client.createExecution({
      parent: client.workflowPath(GOOGLE_CLOUD_PROJECT, WORKFLOW_REGION, WORKFLOW_NAME),
      execution: {
        argument: JSON.stringify({headers: req.headers, body: req.body})
      }
    });

Deploy the Cloud Run service with the Workflows name and region passed as environment variables:

  gcloud run deploy ${SERVICE_NAME} \
  --image gcr.io/${PROJECT_ID}/${SERVICE_NAME} \
  --region=${REGION} \
  --allow-unauthenticated \
  --update-env-vars GOOGLE_CLOUD_PROJECT=${PROJECT_ID},WORKFLOW_REGION=${REGION},WORKFLOW_NAME=${WORKFLOW_NAME}

Connect a Pub/Sub topic to the Cloud Run service

With Cloud Run and Workflows connected, the next step is to connect a Pub/Sub topic to the Cloud Run service by creating an Eventarc Pub/Sub trigger:

  gcloud eventarc triggers create ${SERVICE_NAME} \
  --destination-run-service=${SERVICE_NAME} \
  --destination-run-region=${REGION} \
  --location=${REGION} \
  --event-filters="type=google.cloud.pubsub.topic.v1.messagePublished"

This creates a Pub/Sub topic under the covers that you can access with:

  export TOPIC_ID=$(basename $(gcloud eventarc triggers describe ${SERVICE_NAME} --format='value(transport.pubsub.topic)'))

Trigger the workflow

Now that all the wiring is done, you can trigger the workflow by simply sending a Pub/Sub message to the topic created by Eventarc:

gcloud pubsub topics publish ${TOPIC_ID} --message="Hello there"

In a few seconds, you should see the message in Workflows logs, confirming that the Pub/Sub message triggered the execution of the workflow:

Eventarc Audit Log-Storage + Workflows integration

In the second example, imagine you want a file creation event in a Cloud Storage bucket to trigger a workflow. The steps are similar to the Pub/Sub example with a few differences.

Define and deploy a workflow

As an example, you can use this workflow.yaml that logs the bucket and file names:

  main:
  params: [args]
  steps:
...
    - log:
        call: sys.log
        args:
            text: ${"Workflows received event from bucket " + bucket + " for file " + file}
            severity: INFO

Deploy a Cloud Run service to execute the workflow

In the Cloud Run service, you read the CloudEvent from Eventarc and extract the bucket and file name in app.js using the CloudEvent SDK and the Google Event library:

  const cloudEvent = HTTP.toEvent({ headers: req.headers, body: req.body });
  //"protoPayload" : {"resourceName":"projects/_/buckets/events-atamel-images-input/objects/atamel.jpg}";
  const logEntryData = toLogEntryData(cloudEvent.data);
  const tokens = logEntryData.protoPayload.resourceName.split('/');
  const bucket = tokens[3]

Executing the workflow is similar to the Pub/Sub example, except you don’t pass in the whole HTTP request but rather just the bucket and file name to the workflow:

  const execResponse = await client.createExecution({
      parent: client.workflowPath(GOOGLE_CLOUD_PROJECT, WORKFLOW_REGION, WORKFLOW_NAME),
      execution: {
        argument: JSON.stringify({bucket: bucket, file: file})
      }
    });

Connect Cloud Storage events to the Cloud Run service

To connect Cloud Storage events to the Cloud Run service, create an Eventarc Audit Logs trigger with the service and method names for Cloud Storage:

  gcloud eventarc triggers create ${SERVICE_NAME} \
  --destination-run-service=${SERVICE_NAME} \
  --destination-run-region=${REGION} \
  --location=${REGION} \
  --event-filters="type=google.cloud.audit.log.v1.written" \
  --event-filters="serviceName=storage.googleapis.com" \
  --event-filters="methodName=storage.objects.create" \
  --service-account=${PROJECT_NUMBER}-compute@developer.gserviceaccount.com

Trigger the workflow

Finally, you can trigger the workflow by creating and uploading a file to the bucket:

  echo "Hello World" > random.txt
gsutil cp random.txt gs://${BUCKET}/random.txt

In a few seconds, you should see the workflow log the bucket and object name.

Conclusion

In this blog post, I showed you how to trigger a workflow with two different event types from Eventarc. It’s certainly possible to do the opposite, namely, trigger a Cloud Run service via Eventarc with a Pub/Sub message (see connector_publish_pubsub.workflows.yaml) from Workflows or a file upload to a bucket from Workflows. 
All the code mentioned in this blog post is in eventarc-workflows-integration. Feel free to reach out to me on Twitter @meteatamel for any questions or feedback.

Do you want to fire up a bunch of techies? Talk about multicloud! There is no shortage of opinions. I figured we should tackle this hot topic head-on, so I recently talked to four smart folks—Corey Quinn of Duckbill Group, Armon Dadgar of Hashicorp, Tammy Bryant Butow of Gremlin, and James Watters of VMware—about what multicloud is all about, key considerations, and why you should (or shouldn’t!) do it.

Five important insights came out of these discussions. If you’re on a multicloud journey or considering one, keep reading.

Do: Choose to do multicloud for the right reasons

Don’t do multicloud because Gartner says so, implores Corey Quinn. Before embarking on a multicloud, define a “why” focused on business value journey, says Armon Dadger. For example, you might want to use services from each public cloud because of their differentiated services, according to Tammy Bryant Butow. Armon also calls out regulatory reasons, existing business relationships, and accommodating mergers and acquisitions. On the topic of M&A, Corey points out that if you acquire a company that uses another cloud, it’s usually expensive and difficult to consolidate. It can be smarter to stay put.

https://youtube.com/watch?v=xFSDexQhCUY%3Fenablejsapi%3D1%26

Don’t: Over-engineer for workload or data portability

Thinking that you’ll build a system that moves seamlessly among the various cloud providers? Hold up, says our group of experts. Armon points out that aspects of your toolchain or architecture may be multicloud—think of some of your workflows or global network routing—but that shifting workloads or data is far from simple. Corey says that trying to engineer for “write once, run anywhere” can slow you down, and ignores the inherent uniqueness that’s part of each platform. Specifically, Corey calls out the per-cloud stickiness of identity management, security features, and even network functionality. And data gravity is still a thing, says James, that causes some to dismiss multicloud outright.

If you’re using multiple public clouds, you take advantage of the distinct value each offers, Armon says. Use native cloud services where possible so that you see the benefits from useful innovations, built-in resilience, and baked-in best practices. The value from that cloud-infused workload may outweigh the benefits of seamless portability.

https://youtube.com/watch?v=B1VH56_L8f8%3Fenablejsapi%3D1%26

Do: Recognize different stakeholder interests and needs

James smartly points out that many multicloud debates happen because people are arguing from different perspectives. Context matters. If you’re an infrastructure engineer who invests heavily in a given cloud’s identity and access management model, multicloud looks tricky. Or if you’re a data engineer with petabytes of data homed in a particular cloud, multicloud may look unrealistic. James highlights that many developers default to multicloud because their local tools—where all the work happens—are multicloud. A developer’s IDE and preferred code framework(s) aren’t tied to any given cloud. Be aware that groups within your organization will come at multicloud from distinct directions. And this may impact your approach!

https://youtube.com/watch?v=I9sqXDqkKBM%3Fenablejsapi%3D1%26

Don’t: Go it alone

Corey talks about the importance of asking others what worked, and what didn’t. Tammy offers her best practices around sharing results from experiments. It’s about sharing knowledge and tapping into it for community benefit. Others have probably tried what you’re trying, and can help you avoid common pitfalls. If you’ve just made an architectural choice that didn’t work out, share it, and help others avoid the pain. 

Read research from analysts, go to conferences or watch videos to observe case studies, and join online communities that offer a safe place to share mistakes and learn from others.

https://youtube.com/watch?v=mrSb5vqOfuI%3Fenablejsapi%3D1%26

Do: Experiment first using techniques like multi-region deployments

If you think you can operate systems across clouds, how about you first try doing it across regions in a specific cloud, suggests Corey. Getting a system to properly work across cloud regions isn’t trivial, he says, and that experience can help you uncover where you have architectural or operational constraints that will be even worse across cloud providers.

This is great guidance if your multicloud aspirations involve using multiple clouds to power one application—versus the more standard definition of multicloud where you use different clouds for different applications—but can also surface issues in your support process or toolchain that fail when faced with distributed systems. Start with muti-region deployments and chaos engineering experiments before aggressively jumping into multicloud architectures.

The Google Cloud take

Do the things above. It’s great advice. I’ll add three more things that we’ve learned from our customers.

1. Don’t fear multicloud. You’re already doing it. You don’t single-source everything. As Corey mentioned, you probably already have one cloud for productivity tools, another for source code, another for cloud infrastructure. You’ll use software and application services from a mix of providers for a single app. You have that experience in your team and have been doing that for decades. What people do rightly worry about is using more than one infrastructure service beneath an application, as that can introduce latency, security, and logistical hurdles. Make sure you know which model your team is considering.
2. Embrace the right foundational components, including Kubernetes. Will everything run on Kubernetes? Of course not. Don’t try to do that. But it also represents the closest thing we have to a multicloud API. Companies are using Kubernetes to stripe a consistent experience across clouds. And this isn’t just to orchestrate containers, but also to manage infrastructure and cloud-native services. Also, consider where you need other fundamental consistency across clouds, including areas like provisioning and identity federation.
3. Use Google Cloud as your anchor. Here’s a fundamental question you have to decide for yourself: Are you going to bring your on-premises technology and practices to the cloud, or bring cloud technology and practices on-prem? We sincerely believe in the latter. Anchor to where you’re trying to get to. We offer Anthos as a way to build and run distributed Kubernetes fleets in Google Cloud and across clouds. By using a cloud-based backplane instead of an on-prem one, you’re offloading toil, leveraging managed services for scale and security, and introducing modern practices to the rest of your team.

We learned a lot about multicloud through these discussions, and it seems like others did too. That’s why we’re going to do a second round of interviews with a new crop of experts so that we can keep digging deeper into this topic. Stay tuned!

Casper Labs announced a collaboration with Google Cloud that will allow developers to launch public and/or private Casper nodes directly from Google Cloud. This enables a much more seamless and highly secure process for the millions of developers who want to build in blockchain environments without having to learn new, highly specialized programming languages. Additionally, Google Cloud will provide its scalable and reliable infrastructure to developers building on the Casper Protocol. 

Blockchain technology is maturing 

As blockchain technology matures, a growing number of businesses are embracing it as a key way to drive new efficiencies and realize cost savings. 

According to a recent Casper Labs study, 87% of executives polled in the United States, United Kingdom and China reported plans to invest in a blockchain solution in 2023. This is due in no small part due to recent innovations that help organizations overcome the so-called Blockchain Adoption Trilemma, which previously held that it was impossible for any blockchain to be simultaneously a) decentralized, b) scalable, and c) secure.

Thanks to the rise of proof-of-stake blockchains like Casper, new models have emerged that enable a more scalable and secure architecture that no longer forces a compromise on decentralization. 

Another trend facilitating these growing adoption rates is the rise of WebAssembly (WASM) as a baseline technology for newer blockchains, including Casper. WASM (created by W3C) makes application development in blockchain environments far more accessible and interoperable to the millions of developers worldwide who specialize in languages like Java, Javascript, C++ and Rust. Previously, any blockchain-based build required a high degree of specialized developer knowledge, which made it a much more challenging option for most organizations. 

Meet Casper

Casper is a permissionless, decentralized public blockchain based on WASM that was built explicitly to foster enterprise adoption of blockchain technology. Beyond its more accessible model, Casper is the first and only blockchain to offer native upgradable smart contracts. This means that organizations can have the option to securely and consistently update software code even after it is running on Casper. This gives organizations the control and flexibility to use industry best practices, such as continuous deployment and continuous integration, which are already in use in their IT departments. Casper is also highly configurable and allows organizations to support public, private, and/or hybrid deployments. 

Casper is also noteworthy for the presence of Casper Labs, a software development and professional services firm that supports organizations building on the Casper network. Unlike most blockchains that follow a more traditional open-source project, Casper Labs provides around-the-clock support and bespoke software development for enterprise organizations. Recently, Casper Labs helped patent management company IPwe execute the largest-ever blockchain deployment, featuring more than 25 million patents being added as custom NFTs to the Casper Blockchain. 

How to get started with Casper on Google Cloud

Developers who want to start building on Casper can find a comprehensive series of tutorials here.

The Casper Association also recently announced a $25 million grant program to support projects and developers building on Casper. Interested participants can apply here.

This past year brought both new challenges and successes for our customers around the world. We thought life was going to return to normal… and then it didn’t. Despite the uncertainty, it was exciting to see customers make huge transformations in when, where, and how they run their businesses, with cloud infrastructure as a major enabler. 

According to IDC, “by 2024, 50% of organizations will use applications built on abstraction provided by managed services including cloud-native technologies to enable consistency in running in any and many locations.”¹ Over the past year we were honored to work with so many of you to start to make this prediction a reality.

Let’s take a deeper look at where our infrastructure progressed in 2021, and where we’re headed in the new year.

Google Cloud is recognized by independent experts for its leadership

For the fourth consecutive year, Google Cloud was named a Leader in the Gartner Magic Quadrant for Cloud Infrastructure and Platform Services.

The Forrester Wave for AI infrastructure placed Google at the topmost position, a testament to Google’s investments in tomorrow’s AI-first world. 

Google Cloud also won the HPC Wire Editor’s Choice award for the best use of HPC in the cloud.    

We made it easier to migrate enterprise applications

To support enterprises in their transformation journeys we focused on expanding our support for enterprise applications in our cloud. The Home Depot just wrote about its successful migration of SAP to Google Cloud, highlighting how crucial it is to have good processes and strong partnerships. For other companies using SAP applications we also launched Filestore Enterprise, which delivers 99.99% regional availability ​​backed by an SLA. 

Our partner NetApp deepened its integration with Google Cloud to enable easier and faster Windows-based application migration, and provided flexible deployment options to modernize workloads. We also added new Network Connectivity Center partners to include companies like Cisco, Palo Alto Networks, and VMware, so as you migrate over time you can easily connect all your networking resources together in one place. 

For those of you considering migration to cloud, Forrester dove deeper into the economics of migrating enterprise applications to cloud. (Spoiler alert: companies are finding major cost savings and performance benefits!) It’s so important to us that companies trust that their biggest, most complex applications will run smoothly and securely with us, and we’re pleased at the progress we’ve made toward supporting more enterprise applications this year.

We also made it easier for you to migrate VMware workloads to the cloud by expanding Google Cloud VMware Engine to 12 regions worldwide and enabling several new capabilities across networking, compliance, and scale. Customers such as Mitel and Carrefour migrated their VMware estates to Google Cloud to transform their applications with Google services to increase agility, save money (up to 45%) and reduce energy costs (about 35%) compared to running on-premises. 

For High Performance Computing (HPC), we continued to add capabilities such as optimized VM images for HPC, enhanced integration with schedulers such as SchedMD, Slurm, and Altair PBSPro.    

New cost and performance options

To further support customers doing high performance computing for things like real-time advertising, dynamic e-commerce, and gaming, we launched a new VM family: Tau VMs. Tau VMs offer 56% higher absolute performance and 42% higher price-performance compared to general-purpose VMs from any of the leading public cloud vendors.  We are seeing companies such as Nylas switching from other cloud platforms to Google Cloud to make the most of Tau VMs.

That isn’t the only VM advancement we made. For customers with higher levels of fault tolerance and looking for greater cost efficiencies, we launched Spot VMs, which open up access to Google Cloud’s idle capacity so you can run your application at the lowest price possible. With Spot VMs, you save anywhere from 60-91% off the price of on-demand VMs. 

We also launched more options for the highest performance ephemeral block storage — 6TB and 9TB Local SSDs, which offer greater IOPS per dollar when attached to general purpose N2 Compute Engine VMs. 

Distributed cloud brings us closer to you

For years, the industry has been telling companies, “move to cloud!” but not all workloads can move to the public cloud immediately or entirely. Factors include industry- or region-specific compliance and data sovereignty needs, low latency or local data-processing requirements, or the need to run applications close to other services. 

In October, we expanded our distributed cloud strategy and announced Google Distributed Cloud, a portfolio of fully managed hardware and software solutions that extend Google Cloud’s infrastructure and services to data centers and the edge. This is a major step forward in our ability to meet you where you are, in private data centers and at the edge, and we’re excited to see how this helps you as we move into 2022.

Data protection and security that never sleeps

This year we worked hard to help improve your data protection capabilities. We doubled down on our Actifio acquisition by launching several releases that deepened its integration with Google Cloud. For customers with containerized applications, we took a big step forward with the launch of Backup for GKE. We’re particularly excited about how this new option for GKE users allows you to more easily meet your service-level objectives, automate common backup and recovery tasks, and show reporting for compliance and audit purposes. 

We also enhanced Cloud Storage with data protection features like custom region selection for dual-region buckets. Previously, Google Cloud assigned dual-region pairs for you to choose from. With this release, you can  select your own region pairs that meet your regulatory or compliance requirements, or optimize your app performance. We also launched Turbo Replication for dual-region buckets, which replicates 100% of your data between regions in 15 minutes or less, backed by a Service Level Agreement, a first from a leading cloud provider. 

Security is a key area of focus for us and we partnered with Palo Alto Networks to deliver their industry-leading Intrusion Detection System (IDS) solution natively on Google Cloud. With the recent Apache Log4j vulnerability, we automatically updated Cloud IDS to help detect exploit attempts and protect our customers’ environments quickly. We also integrated Cloud Armor with reCAPTCHA Enterprise to deliver a best-in-class bot and fraud management solution to prevent volumetric attacks. Cloud Armor is deployed with our Cloud Load Balancer and Cloud CDN, extending its security benefits at the network edge for traffic coming into Google Cloud. 

We made it easier to build and manage applications

Developers want to focus on code, not configuring, managing or scaling infrastructure. To help, we worked on simplifying networking with new services such as Private Service Connect, which allows you to connect VPCs to applications and services securely without configuring all the network underlay. To make it easier to run workloads in hybrid environments, we introduced BYOIP so you don’t need to change your IP address, and we enhanced Cloud Load Balancer with advanced traffic management, regional and hybrid app delivery to load balance traffic between on-prem and cloud workloads. We also introduced IPv6, DNS policy manager, Cloud Domains, GKE Gateway Controller, eBPF data plane, and Service Directory, all with the goal of making networking easier for developers.

We continue to invest in visibility and observability for efficient day 2 operations. Network Intelligence Center now has dynamic reachability within the Connectivity Tests module, interconnect and VPN visualization in Network Topology, and the Firewall Insights module, which provides visibility into firewall rules to ensure they are being used appropriately and as intended. 

And while not new this year, developers continue to tell us how much they love the ease of architecting storage using Cloud Storage. See how easy it is to configure a dual-region bucket. As a result, developers can treat a continent like a single bucket, dramatically simplifying the application programming model. Google Cloud is unique in offering this capability among major public cloud vendors.

We continue to be the most sustainable cloud for you

Another area Google has invested in deeply and that is becoming increasingly important to more organizations is sustainability. Many cloud providers have a vision for a sustainable future, and many aim to match their electricity consumption with 100% renewable energy by 2025 or 2030. We accomplished 100% renewable energy in 2017, which means we’re the only hyperscale cloud to do this today and on data centers that are twice as energy efficient as the average data center.

We also announced a number of new features like our new Carbon Footprint tool. Every Google Cloud user — that means you! — can see the gross carbon emissions associated with the services you use in Google Cloud. This means picking the data center that meets your sustainability goals, and reducing the overall emissions tied to your infrastructure and applications. And we have some pretty big goals for the future. For more, don’t miss our full sustainability recap.

A big thank you to our customers

While we were busy building out our infrastructure in 2021, we’d be nowhere without the partnership of our amazing customers. It’s hard to pick from all the exciting stories we heard this year, but here are just a few: Pega migrated its SAP applications to Google Cloud with zero downtime. Paypal exited its non-strategic data centers and achieved major cost savings. And Wix used our network to serve tens of millions of requests per day. 

I’m proud to look back at how our cloud infrastructure has evolved this year to support each of our customers on their transformation journey. As we head into 2022 I’m excited to continue to partner with you to solve your most difficult challenges together. 

Interested in hearing more about Google’s vision for the future? Listen to Thomas Kurian’s thoughts from Google Cloud Next ‘21.

^{1. IDC FutureScape: Worldwide Cloud 2022 Predictions}