Introducing new generative AI capabilities in Google Cloud and Google Workspace, plus PaLM API and MakerSuite for developers.
Posted by Scott Huffman, Vice President, Engineering and Josh Woodward, Senior Director, Product Management
We’re seeing a new wave of generative AI applications that are transforming the way people interact with technology – from games and dialog agents to creative brainstorming and coding tools. At Google, we want to continue making AI accessible by empowering all developers to start building the next generation of applications with generative AI by providing easy-to-use APIs and tools.
Earlier today, we announced the PaLM API, a new developer offering that makes it easy and safe to experiment with Google’s large language models. Alongside the API, we’re releasing MakerSuite, a tool that lets developers start prototyping quickly and easily. We’ll be making these tools available to select developers through a Private Preview, and stay tuned for our waitlist soon.
It’s an exciting time in AI for developers and we want to continue to make sure we build AI tools that help make your lives easier. We plan to onboard new developers, roll out new features, and make this technology available to the broader developer community soon. During this time, we’ll listen to feedback, learn, and improve these tools to meet developers where they are.
To stay updated on our progress, subscribe to the Google Developers newsletter.
Posted by Nari Yoon, Hee Jung, DevRel Community Manager / Soonson Kwon, DevRel Program Manager
Let’s explore highlights and accomplishments of vast Google Machine Learning communities over the last quarter of 2022. We are enthusiastic and grateful about all the activities by the global network of ML communities. Here are the highlights!
 |
 |
 |
gMLP: What it is and how to use it in practice with Tensorflow and Keras? by ML GDE Radostin Cholakov (Bulgaria) demonstrates the state-of-the-art results on NLP and computer vision tasks using a lot less trainable parameters than corresponding Transformer models. He also wrote Differentiable discrete sampling in TensorFlow.
Building Computer Vision Model using TensorFlow: Part 2 by TFUG Pune for the developers who want to deep dive into training an object detection model on Google Colab, inspecting the TF Lite model, and deploying the model on an Android application. ML GDE Nitin Tiwari (India) covered detailed aspects for end-to-end training and deployment of object model detection.
Advent of Code 2022 in pure TensorFlow (days 1-5) by ML GDE Paolo Galeone (Italy) solving the Advent of Code (AoC) puzzles using only TensorFlow. The articles contain a description of the solutions of the Advent of Code puzzles 1-5, in pure TensorFlow.
 |
Build tensorflow-lite-select-tf-ops.aar and tensorflow-lite.aar files with Colab by ML GDE George Soloupis (Greece) guides how you can shrink the final size of your Android application’s .apk by building tensorflow-lite-select-tf-ops.aar and tensorflow-lite.aar files without the need of Docker or personal PC environment.
TensorFlow Lite and MediaPipe Application by ML GDE XuHua Hu (China) explains how to use TFLite to deploy an ML model into an application on devices. He shared experiences with developing a motion sensing game with MediaPipe, and how to solve problems that we may meet usually.
 |
 |
 |
Usha Rengaraju (India) shared TensorFlow Extended (TFX) Tutorials (Part 1, Part 2, Part 3) and the following TF projects: TensorFlow Decision Forests Tutorial and FT Transformer TensorFlow Implementation.
JAX High-performance ML Research by TFUG Taipei and ML GDE Jerry Wu (Taiwan) introduced JAX and how to start using JAX to solve machine learning problems.
 |
Low-light Image Enhancement using MirNetv2 by ML GDE Soumik Rakshit (India) demonstrated the task of Low-light Image Enhancement.
 |
Better Hardware Provisioning for ML Experiments on GCP by ML GDE Sayak Paul (India) discussed the pain points of provisioning hardware (especially for ML experiments) and how we can get better provision hardware with code using Vertex AI Workbench instances and Terraform.
 |
 |
More practical time-series model with BQML by ML GDE JeongMin Kwon (Korea) introduced BQML and time-series modeling and showed some practical applications with BQML ARIMA+ and Python implementations.
AI in Healthcare by ML GDE Sara EL-ATEIF (Morocco) introduced AI applications in healthcare and the challenges facing AI in its adoption into the health system.
Women in AI APAC finished their journey at ML Paper Reading Club. During 10 weeks, participants gained knowledge on outstanding machine learning research, learned the latest techniques, and understood the notion of “ML research” among ML engineers. See their session here.
A Natural Language Understanding Model LaMDA for Dialogue Applications by ML GDE Jerry Wu (Taiwan) introduced the natural language understanding (NLU) concept and shared the operation mode of LaMDA, model fine-tuning, and measurement indicators.
Python library for Arabic NLP preprocessing (Ruqia) by ML GDE Ruqiya Bin (Saudi Arabia) is her first python library to serve Arabic NLP.
 |
Anatomy of Capstone ML Projects 🫀by ML GDE Sayak Paul (India) discussed working on capstone ML projects that will stay with you throughout your career. He covered various topics ranging from problem selection to tightening up the technical gotchas to presentation. And in Improving as an ML Practitioner he shared his learning from experience in the field working on several aspects.
 |
Transcending Scaling Laws with 0.1% Extra Compute by ML GDE Grigory Sapunov (UK) reviewed a recent Google article on UL2R. And his posting Discovering faster matrix multiplication algorithms with reinforcement learning explained how AlphaTensor works and why it is important.
Back in Person - Prompting, Instructions and the Future of Large Language Models by TFUG Singapore and ML GDE Sam Witteveen (Singapore) and Martin Andrews (Singapore). This event covered recent advances in the field of large language models (LLMs).
ML for Production: The art of MLOps in TensorFlow Ecosystem with GDG Casablanca by TFUG Agadir discussed the motivation behind using MLOps and how it can help organizations automate a lot of pain points in the ML production process. It also covered the tools used in the TensorFlow ecosystem.
Posted by Wesley Chun (@wescpy), Developer Advocate, Google Cloud
| How to migrate the App Engine Users to Cloud Identity Platform |
Overall, Module 21 features major changes to the Module 20 sample app, implementing a move from App Engine bundled services (NDB & Users) to standalone Cloud services (Cloud Datastore & Identity Platform). Identity Platform doesn't know anything about App Engine admins, so that must be built, requiring the use of the Cloud Resource Manager API. Apps dependent on Python 2 have additional required updates. Let's discuss in a bit more detail.
The following changes to the sample app are required:
- Migrate from App Engine Users (server-side) to Cloud Identity Platform (client-side)
- Migrate from App Engine NDB, the other bundled service used in Module 20, to Cloud NDB (requires use of the Cloud Datastore API)
- Use the Cloud Resource Manager* (via its API) to fetch the Cloud project's IAM allow policy to collate the set of App Engine admin users for the app.
- Use the Firebase Admin SDK to validate whether the user is an App Engine admin
- Migrate from Python 2 to 3 (and possibly back to Python 2 [more on this below])
*At the time of this writing, the Resource Manager documentation only features setup instructions for accessing the API from the lower-level Google APIs client library rather than the Resource Manager client library. To learn how to set up the latter, go to the Resource Manager client library documentation directly. The lower-level client library should only be used in circumstances when a Cloud client library doesn't exist or doesn't have the features your app needs. One such use case is Python 2, and we'll be covering that shortly.
The NDB to Cloud NDB migration is identical to the Module 2 migration content, so it's not covered in-depth here in Module 21. The primary focus is on switching to Identity Platform to continue supporting user logins as well as implementing use of the Resource Manager and Firebase Admin SDK to build a proxy for recognizing App Engine admin users as provided by the Users service. Below is pseudocode implementing the key changes to the main application where new or updated lines of code are bolded:
 |
| Migrating from App Engine Users to Cloud Identity Platform(click to enlarge) |
The key differences to note:
Complete versions of the app before and after the updates can be found in the Module 20 (Python 2) and Module 21 (Python 3) repo folders, respectively. In addition to the video, be sure to check out the Identity Platform documentation as well as the Module 21 codelab which leads you step-by-step through the migrations discussed.
Aside from the necessary coding changes as well as moving from server-side to client-side, note that the Users service usage is covered by App Engine's pricing model while Identity Platform is an independent Cloud service billed by MAUs (monthly active users), so costs should be taken into account if migrating. More information can be found in the Identity Platform pricing documentation.
With the sunset of Python 2, Java 8, PHP 5, and Go 1.11, by their respective communities, Google Cloud has assured users by expressing continued long-term support of these legacy App Engine runtimes, including maintaining the Python 2 runtime. So while there is no current requirement for users to migrate, developers themselves are expressing interest in updating their applications to the latest language releases.
The primary Module 21 migration automatically includes a port from Python 2 to 3 as that's where most developers are headed. For those with dependencies requiring remaining on Python 2, some additional effort is required:
Module 21 features migrations of App Engine bundled services to appropriate standalone Cloud services. While we recommend users modernize their App Engine apps by moving to the latest offerings from Google Cloud, these migrations are not required. In Fall 2021, the App Engine team extended support of many of the bundled services to 2nd generation runtimes (that have a 1st generation runtime), meaning you don't have to migrate to standalone services before porting your app to Python 3. You can continue using App Engine NDB and Users in Python 3 so long as you retrofit your code to access bundled services from next-generation runtimes. Then should you opt to migrate, you can do so on your own timeline.
Posted by Wesley Chun (@wescpy), Developer Advocate, Google Cloud
The Serverless Migration Station video series and corresponding codelabs aim to help App Engine developers modernize their apps, whether it's upgrading language runtimes like from Python 2 to 3 and Java 8 to 17, or to move laterally to sister serverless platforms like Cloud Functions or Cloud Run. For developers who want more control, like being able to SSH into instances, Compute Engine VMs or GKE, our managed Kubernetes service, are also viable options.
In order to consider moving App Engine apps to other compute services, developers must move their apps away from its original APIs (now referred to as legacy bundled services), either to Cloud standalone replacement or alternative 3rd-party services. Once no longer dependent on these proprietary services, apps become much more portable. Apps can stay on App Engine while upgrading to its 2nd-generation platform, or move to other compute platforms as listed above.
 |
| Sample app now supports user logins and App Engine admin users (click to enlarge) |
 |
| Adding App Engine Users service usage to sample app (click to enlarge) |
Posted by Wesley Chun (@wescpy), Developer Advocate, Google Cloud
The Serverless Migration Station series is aimed at helping developers modernize their apps running one of Google Cloud's serverless platforms. The preceding (Migration Module 18) video demonstrates how to add use of App Engine's Task Queue pull tasks service to a Python 2 App Engine sample app. Today's Module 19 video picks up from where that leaves off, migrating that pull task usage to Cloud Pub/Sub.
Moving away from proprietary App Engine services like Task Queue makes apps more portable, giving them enough flexibility to:
- Run on 2nd generation App Engine runtimes
- Shift across to other serverless platforms, like Cloud Functions or Cloud Run (with or without Docker)
- Move to VM-based services like GKE or Compute Engine, or to other compute platforms
Module 19 consists of implementing three different migrations on the Module 18 sample app:
- Migrate from App Engine NDB to Cloud NDB
- Migrate from App Engine Task Queue pull tasks to Cloud Pub/Sub
- Migrate from Python 2 to Python (2 and) 3
The NDB to Cloud NDB migration is identical to the Module 2 migration content, so it's not covered in-depth in Module 19. The original app was designed to be Python 2 and 3 compatible, so there's no work there either. Module 19 boils down to three key updates:
- Setup: Enable APIs and create Pub/Sub Topic & Subscription
- How work is created: Publish Pub/Sub messages instead of adding pull tasks
- How work is processed: Pull messages instead of leasing tasks
 |
| Terminology differences between App Engine pull tasks and Cloud Pub/Sub |
 |
| Migration from App Engine Task Queue pull tasks to Cloud Pub/Sub |
Module 19 features a migration of App Engine pull tasks to Cloud Pub/Sub, but developers should note that Pub/Sub itself is not based on pull tasks. It is a fully-featured asynchronous, scalable messaging service that has many more features than the pull functionality provided by Task Queue. For example, Pub/Sub has other features like streaming to BigQuery and push functionality. Pub/Sub push operates differently than Task Queue push tasks, hence why we recommend push tasks be migrated to Cloud Tasks instead (see Module 8). For more information on all of its features, see the Pub/Sub documentation. Because Cloud Tasks doesn't support pull functionality, we turn to Pub/Sub instead for pull task users.
While we recommend users move to the latest offerings from Google Cloud, neither of those migrations are required, and should you opt to do so, can do them on your own timeline. In Fall 2021, the App Engine team extended support of many of the bundled services to 2nd generation runtimes (that have a 1st generation runtime), meaning you don't have to migrate to standalone Cloud services before porting your app to Python 3. You can continue using Task Queue in Python 3 so long as you retrofit your code to access bundled services from next-generation runtimes.
If you're using other App Engine legacy services be sure to check out the other Migration Modules in this series. All Serverless Migration Station content (codelabs, videos, source code [when available]) can be accessed at its open source repo. While our content initially focuses on Python users, the Cloud team is working on covering other language runtimes, so stay tuned. For additional video content, check out our broader Serverless Expeditions series.
Posted by Kevin Hernandez, Developer Relations Community Manager
Lynn Langit is not only a Cloud GDE - she’s one of the first ever GDEs to join the program. Despite joining the GDE program early after its establishment, she got a relatively late start with development. Lynn is a self-taught developer that started coding when she was 38 years old - before we had the advent of online educational resources that we do today. To teach herself how to code, she relied on certifications and books and went to her local electronics store to buy equipment to build her own server. Through this process, she found that she was a talented developer and became inspired to try her hand at teaching. She started out with teaching basic topics such as user applications. Today she has 28 Cloud courses on LinkedIn and has an audience of 5 million students. With this immense reach, Lynn runs into her students at various conferences around the world and has even had students recognize her from her voice. She mentions,“Before the pandemic, I used to travel and work globally and it was so gratifying to meet all my students because they would want to come and talk to me. It was incredible to meet students from all over the world.”
When Lynn left her corporate job, she started her own consultancy in 2011 with two ideas: technical teaching and building. She started out in a classroom with these two ideas but as traditional learning started to usher in a new era of online learning, Lynn followed suit and started to put her lessons on YouTube. This caught the attention of Lynda.com (now LinkedIn Learning) where she was asked to become an author.
Teaching has proven to be rewarding in several ways. It allows Lynn to have an impact on learners interested in Cloud and dive deeper into topics she’s interested in, all while getting paid for her academic pursuits and instructing. She states, “I can't say I'm an expert in all the services, but I know a lot of the services across all the Clouds. So while I'm learning, I might as well teach and get paid for it.”
Lynn is in the constant pursuit for knowledge and in the ever-changing world of Cloud, there is always something new to learn or teach and in Lynn’s case, both. “Oftentimes I'll create a course in something that I am genuinely interested in that doesn’t have an existing course. It's so that I can focus my energies, learn it, and then teach it,” she adds. A recent example is with a book club she led last year in quantum computing. “I'm just really taking baby steps into it and as part of that, I started exploring the vendor Cloud quantum offerings. Then I decided to share that as a course,” she says.
She also mentions that there is a preconceived notion that online content has to be super polished. She believes it’s important to put your lessons out there and more importantly, to learn together. “We're one community and we need to share when we discover something,” she observed.
Every instructor has their own teaching style and for Lynn, her brand is a conversational style of instruction. Very much like our interview, her lessons feel as if she’s talking to the audience one-on-one. This is in part by design - Lynn doesn’t write a script and she imagines someone sitting across from her. She can also sprinkle in some useful case studies from her consultancy work and can draw from some real-world examples.
When asked about effective educators, Lynn says, “Don't be a jerk. The point is not to show how smart you are. The point is to communicate information that you have found useful, that you think other people will find useful and in a way they can understand.”
Lynn has met a lot of educators in her career and has had the fortune of being able to see published and unpublished content. One thing she noticed is that the problem with a lot of content is that it just simply doesn’t see the light of the day. Some content creators feel as if there is a missing piece or their content needs to be ultra polished but Lynn’s advice is to just click “publish”. She also notes that this can be attributed to imposter syndrome, which shows emotional intelligence, but as a counterpoint she advises, “There's value in the learning, not just the result. That is probably the biggest insight I've gained over my years because I always thought you just had to show polished content.” Lynn believes that your audience wants to go along with you on your journey and since people are busy, they think of you as a curator of knowledge.
She also advises to start small. She is particularly fond of “snack-sized” pieces of content such as the short-form articles on Dev.to. These “snacks” are easier to produce and in reality, it’s easier on the audience. She says, “It's funny because people want to make a course but this is not a Hollywood movie, I am sorry to break it to you, but people are not going to be rapturously glued to your screen for two hours no matter who you are. So just make little snacks.” If you find something interesting, just put it out there. Over time, as you get practice, you can start to produce longer-form content.
Lynn offers valuable advice to any present or future GDE. She encourages, “Really get to know the GDEs. We're all kind of doing the same thing and just jump right in. The bar is high to become a GDE and it's a great community that I've learned a lot from.” There is a wealth of knowledge offered by your community. Maybe you’ll learn how to create an Android app, build a ML model, or build an online course with the guidance of Lynn. Just jump right in.
You can check out Lynn’s LinkedIn courses or find her on LinkedIn or Substack.
The Google Developer Experts (GDE) program is a global network of highly experienced technology experts, influencers, and thought leaders who actively support developers, companies, and tech communities by speaking at events and publishing content.
Posted by Wesley Chun (@wescpy), Developer Advocate, Google Cloud
The Serverless Migration Station mini-series helps App Engine developers modernize their apps to the latest language runtimes, such as from Python 2 to 3 or Java 8 to 17, or to sister serverless platforms Cloud Functions and Cloud Run. Another goal of this series is to demonstrate how to move away from App Engine's original APIs (now referred to as legacy bundled services) to Cloud standalone replacement services. Once no longer dependent on these proprietary services, apps become much more portable, making them flexible enough to:
App Engine's Task Queue service provides infrastructure for executing tasks outside of the standard request-response workflow. Tasks may consist of workloads exceeding request timeouts or periodic tangential work. The Task Queue service provides two different queue types, push and pull, for developers to perform auxiliary work.
Push queues are covered in Migration Modules 7-9, demonstrating how to add use of push tasks to an existing baseline app followed by steps to migrate that functionality to Cloud Tasks, the standalone successor to the Task Queues push service. We turn to pull queues in today's video where Module 18 demonstrates how to add use of pull tasks to the same baseline sample app. Module 19 follows, showing how to migrate that usage to Cloud Pub/Sub.
In addition to registering page visits, the sample app needs to be modified to track visitors. Visits are comprised of a timestamp and visitor information such as the IP address and user agent. We'll modify the app to use the IP address and track how many visits come from each address seen. The home page is modified to show the top visitors in addition to the most recent visits:
 |
| The sample app's updated home page tracking visits and visitors |
When visits are registered, pull tasks are created to track the visitors. The pull tasks sit patiently in the queue until they are processed in aggregate periodically. Until that happens, the top visitors table stays static. These tasks can be processed in a number of ways: periodically by a cron or Cloud Scheduler job, a separate App Engine backend service, explicitly by a user (via browser or command-line HTTP request), event-triggered Cloud Function, etc. In the tutorial, we issue a curl request to the app's endpoint to process the enqueued tasks. When all tasks have completed, the table then reflects any changes to the current top visitors and their visit counts:
 |
| Processed pull tasks update the top visitors table |
Below is some pseudocode representing the core part of the app that was altered to add Task Queue pull task usage, namely a new data model class, VisitorCount, to track visitor counts, enqueuing a (pull) task to update visitor counts when registering individual visits in store_visit(), and most importantly, a new function fetch_counts(), accessible via /log, to process enqueued tasks and update overall visitor counts. The bolded lines represent the new or altered code.
![Adding App Engine Task Queue pull task usage to sample app showing 'Before'[Module 1] on the left and 'After' [Module 18] with altered code on the right](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjRVGVYc9fl4xI9xUpOUaAwXup8p-wUf5nbKllG7OYJSVAYSPVCGw7DU8EbMoTE3kBBgVZiICFvsn_7fHP2oymA_1ASKBrAE2Qt8PzCGAAkK7_WnyvAIEMKQUrxP8FSz3tGykLrlu9nyluN5vgEPrWZrBqIAalCoRmos169g9m9NHz3cGqQyych9eEG/s1600/Screen%20Shot%202022-11-29%20at%205.19.28%20PM.png) |
| Adding App Engine Task Queue pull task usage to sample app |
This "migration" is comprised of adding Task Queue pull task usage to support tracking visitor counts to the Module 1 baseline app and arrives at the finish line with the Module 18 app. To get hands-on experience doing it yourself, do the codelab by hand and follow along with the video. Then you'll be ready to upgrade to Cloud Pub/Sub should you choose to do so.
In Fall 2021, the App Engine team extended support of many of the bundled services to 2nd generation runtimes (that have a 1st generation runtime), meaning you are no longer required to migrate pull tasks to Pub/Sub when porting your app to Python 3. You can continue using Task Queue in your Python 3 app so long as you retrofit the code to access bundled services from next-generation runtimes.
If you do want to move to Pub/Sub, see Module 19, including its codelab. All Serverless Migration Station content (codelabs, videos, and source code) are available at its open source repo. While we're initially focusing on Python users, the Cloud team is covering other runtimes soon, so stay tuned. Also check out other videos in the broader Serverless Expeditions series.
Spain and UK cloud regions and offices are on track to operate at or near 90% carbon-free energy in 2025 thanks to two new clean energy projects.
This week kicked off the HLTH Conference in Las Vegas where thousands of healthcare leaders, care providers, patients and other people in the industry — like our teams at Google — are coming together to discuss how to create a healthier world.
At Google, we believe that technology — especially AI and analytics — can unlock a better future for health globally. Our teams from Search, YouTube, Android, Google Cloud and more are using technology to provide health information and insights for consumers, caregivers and communities. Here’s a look at some of our latest updates.
For many, the front door to healthcare is their smartphone. Millions of people turn to Google Search and YouTube for authoritative information or use apps and connected devices, like Fitbit, to help stay on top of health and wellness goals.
To give Android users a new way to get more from their health and wellness data, we introduced Health Connect earlier this year at Google I/O. Through our Early Access Program, more than 10 health, fitness and wellness apps including MyFitnessPal, Oura and Peloton have already integrated with the platform to help people manage everything from workouts to diet to sleep and more. We are now opening up to more developers with Health Connect (Beta) to give people a single place to manage access to data across their health and fitness apps. In the coming months, we will continue to create an even richer ecosystem of apps and features.
We’ve also made strides on our other platforms, Search and YouTube. In 2021, health videos on YouTube were viewed more than 12 billion times in the U.S. YouTube’s authoritative health content and features are now available in 7 countries, and YouTube recently opened up its features to a wider group of health experts in the U.S. to encompass authoritative services that extend beyond educational institutions and health organizations.
On Search, there’s more ways for people to turn health information into action. After piloting a feature earlier this year that shows available healthcare appointments for primary care, we’re continuing to explore new ways to expand appointments to other specialities and verticals through new and existing partnerships.
This work is made possible by all our partners who provide the health information, insights and experiences that empower consumers in their health.
Healthcare is one of the largest and most complex industries that is turning towards technology to help organizations run more effectively — which in turn helps people live healthier lives.
When organizations commit to digital transformation, it can be a long and overwhelming process, but that doesn’t mean it has to take years to see benefits for developers, clinicians and patients.
Google Cloud came together with several of our customers and partners — including Hackensack Meridian Health, Lifepoint Health and Mayo Clinic — to find a way to encourage rapid reinvention. As a result, we built Google Cloud’s new Healthcare Data Engine (HDE) accelerators to help organizations reinvent quickly and enable the data interoperability that saves lives. The first three HDE accelerators, available in early 2023, will address common use cases around health equity, patient flow, and value-based care.
The transformation of healthcare requires an open and collaborative approach to be successful. For example, Electronic Health Records (EHR) are a critical part of this ecosystem and we see many ways to work with EHR companies for the benefit of healthcare organizations. Today marks a critical development in this journey. At HLTH we announced an agreement that will allow healthcare organizations to run Epic — an EHR system — on Google Cloud. Hackensack Meridian Health plans to move its Epic workloads to Google Cloud, with the aim to drive greater innovation, efficiencies and security.
And with our solution Care Studio, we’ve been working with MEDITECH to bring our advanced search, summarization and sense-making capabilities to their EHR, MEDITECH Expanse. We are now extending this integrated solution to our first two partners, Mile Bluff Medical Center and DCH Health System, to give their health teams a more complete view of their patients and easily find salient information to provide better care. This includes organizing patient records from different sources into a longitudinal view, bringing our advanced search functionality to clinicians directly in their EHR so they can easily and quickly access critical information all in one place.
Fitbit Health Solutions is bringing our technology to healthcare partners, incorporating Fitbit devices, services and insights into programs focused on managing chronic conditions like diabetes. A study from the All of Us research program found that increasing your daily step count by 1000 steps could cut the risk of type 2 diabetes by more than 25%. This kind of insight is key to promoting lifestyle changes for people, and why we are partnering with Babylon Health to support their high-risk members managing chronic conditions.
Underpinning all our work is a deep commitment to make sure that we do not leave anyone behind. Technology has the power to eliminate health disparities and democratize access to healthcare. But we need to be intentional in our efforts to live up to our goal of improving the health of billions of people by building for everyone, everywhere.
