Tag Archives: cloud

An easier way to move your App Engine apps to Cloud Run

Posted by Wesley Chun (@wescpy), Developer Advocate, Google Cloud

Blue header

An easier yet still optional migration

In the previous episode of the Serverless Migration Station video series, developers learned how to containerize their App Engine code for Cloud Run using Docker. While Docker has gained popularity over the past decade, not everyone has containers integrated into their daily development workflow, and some prefer "containerless" solutions but know that containers can be beneficial. Well today's video is just for you, showing how you can still get your apps onto Cloud Run, even If you don't have much experience with Docker, containers, nor Dockerfiles.

App Engine isn't going away as Google has expressed long-term support for legacy runtimes on the platform, so those who prefer source-based deployments can stay where they are so this is an optional migration. Moving to Cloud Run is for those who want to explicitly move to containerization.

Migrating to Cloud Run with Cloud Buildpacks video

So how can apps be containerized without Docker? The answer is buildpacks, an open-source technology that makes it fast and easy for you to create secure, production-ready container images from source code, without a Dockerfile. Google Cloud Buildpacks adheres to the buildpacks open specification and allows users to create images that run on all GCP container platforms: Cloud Run (fully-managed), Anthos, and Google Kubernetes Engine (GKE). If you want to containerize your apps while staying focused on building your solutions and not how to create or maintain Dockerfiles, Cloud Buildpacks is for you.

In the last video, we showed developers how to containerize a Python 2 Cloud NDB app as well as a Python 3 Cloud Datastore app. We targeted those specific implementations because Python 2 users are more likely to be using App Engine's ndb or Cloud NDB to connect with their app's Datastore while Python 3 developers are most likely using Cloud Datastore. Cloud Buildpacks do not support Python 2, so today we're targeting a slightly different audience: Python 2 developers who have migrated from App Engine ndb to Cloud NDB and who have ported their apps to modern Python 3 but now want to containerize them for Cloud Run.

Developers familiar with App Engine know that a default HTTP server is provided by default and started automatically, however if special launch instructions are needed, users can add an entrypoint directive in their app.yaml files, as illustrated below. When those App Engine apps are containerized for Cloud Run, developers must bundle their own server and provide startup instructions, the purpose of the ENTRYPOINT directive in the Dockerfile, also shown below.

Starting your web server with App Engine (app.yaml) and Cloud Run with Docker (Dockerfile) or Buildpacks (Procfile)

Starting your web server with App Engine (app.yaml) and Cloud Run with Docker (Dockerfile) or Buildpacks (Procfile)

In this migration, there is no Dockerfile. While Cloud Buildpacks does the heavy-lifting, determining how to package your app into a container, it still needs to be told how to start your service. This is exactly what a Procfile is for, represented by the last file in the image above. As specified, your web server will be launched in the same way as in app.yaml and the Dockerfile above; these config files are deliberately juxtaposed to expose their similarities.

Other than this swapping of configuration files and the expected lack of a .dockerignore file, the Python 3 Cloud NDB app containerized for Cloud Run is nearly identical to the Python 3 Cloud NDB App Engine app we started with. Cloud Run's build-and-deploy command (gcloud run deploy) will use a Dockerfile if present but otherwise selects Cloud Buildpacks to build and deploy the container image. The user experience is the same, only without the time and challenges required to maintain and debug a Dockerfile.

Get started now

If you're considering containerizing your App Engine apps without having to know much about containers or Docker, we recommend you try this migration on a sample app like ours before considering it for yours. A corresponding codelab leading you step-by-step through this exercise is provided in addition to the video which you can use for guidance.

All migration modules, their videos (when available), codelab tutorials, and source code, can be found in the migration repo. While our content initially focuses on Python users, we hope to one day also cover other legacy runtimes so stay tuned. Containerization may seem foreboding, but the goal is for Cloud Buildpacks and migration resources like this to aid you in your quest to modernize your serverless apps!

Containerizing Google App Engine apps for Cloud Run

Posted by Wesley Chun (@wescpy), Developer Advocate, Google Cloud

Google App Engine header

An optional migration

Serverless Migration Station is a video mini-series from Serverless Expeditions focused on helping developers modernize their applications running on a serverless compute platform from Google Cloud. Previous episodes demonstrated how to migrate away from the older, legacy App Engine (standard environment) services to newer Google Cloud standalone equivalents like Cloud Datastore. Today's product crossover episode differs slightly from that by migrating away from App Engine altogether, containerizing those apps for Cloud Run.

There's little question the industry has been moving towards containerization as an application deployment mechanism over the past decade. However, Docker and use of containers weren't available to early App Engine developers until its flexible environment became available years later. Fast forward to today where developers have many more options to choose from, from an increasingly open Google Cloud. Google has expressed long-term support for App Engine, and users do not need to containerize their apps, so this is an optional migration. It is primarily for those who have decided to add containerization to their application deployment strategy and want to explicitly migrate to Cloud Run.

If you're thinking about app containerization, the video covers some of the key reasons why you would consider it: you're not subject to traditional serverless restrictions like development language or use of binaries (flexibility); if your code, dependencies, and container build & deploy steps haven't changed, you can recreate the same image with confidence (reproducibility); your application can be deployed elsewhere or be rolled back to a previous working image if necessary (reusable); and you have plenty more options on where to host your app (portability).

Migration and containerization

Legacy App Engine services are available through a set of proprietary, bundled APIs. As you can surmise, those services are not available on Cloud Run. So if you want to containerize your app for Cloud Run, it must be "ready to go," meaning it has migrated to either Google Cloud standalone equivalents or other third-party alternatives. For example, in a recent episode, we demonstrated how to migrate from App Engine ndb to Cloud NDB for Datastore access.

While we've recently begun to produce videos for such migrations, developers can already access code samples and codelab tutorials leading them through a variety of migrations. In today's video, we have both Python 2 and 3 sample apps that have divested from legacy services, thus ready to containerize for Cloud Run. Python 2 App Engine apps accessing Datastore are most likely to be using Cloud NDB whereas it would be Cloud Datastore for Python 3 users, so this is the starting point for this migration.

Because we're "only" switching execution platforms, there are no changes at all to the application code itself. This entire migration is completely based on changing the apps' configurations from App Engine to Cloud Run. In particular, App Engine artifacts such as app.yaml, appengine_config.py, and the lib folder are not used in Cloud Run and will be removed. A Dockerfile will be implemented to build your container. Apps with more complex configurations in their app.yaml files will likely need an equivalent service.yaml file for Cloud Run — if so, you'll find this app.yaml to service.yaml conversion tool handy. Following best practices means there'll also be a .dockerignore file.

App Engine and Cloud Functions are sourced-based where Google Cloud automatically provides a default HTTP server like gunicorn. Cloud Run is a bit more "DIY" because users have to provide a container image, meaning bundling our own server. In this case, we'll pick gunicorn explicitly, adding it to the top of the existing requirements.txt required packages file(s), as you can see in the screenshot below. Also illustrated is the Dockerfile where gunicorn is started to serve your app as the final step. The only differences for the Python 2 equivalent Dockerfile are: a) require the Cloud NDB package (google-cloud-ndb) instead of Cloud Datastore, and b) start with a Python 2 base image.

Image of The Python 3 requirements.txt and Dockerfile

The Python 3 requirements.txt and Dockerfile

Next steps

To walk developers through migrations, we always "START" with a working app then make the necessary updates that culminate in a working "FINISH" app. For this migration, the Python 2 sample app STARTs with the Module 2a code and FINISHes with the Module 4a code. Similarly, the Python 3 app STARTs with the Module 3b code and FINISHes with the Module 4b code. This way, if something goes wrong during your migration, you can always rollback to START, or compare your solution with our FINISH. If you are considering this migration for your own applications, we recommend you try it on a sample app like ours before considering it for yours. A corresponding codelab leading you step-by-step through this exercise is provided in addition to the video which you can use for guidance.

All migration modules, their videos (when published), codelab tutorials, START and FINISH code, etc., can be found in the migration repo. We hope to also one day cover other legacy runtimes like Java 8 so stay tuned. We'll continue with our journey from App Engine to Cloud Run ahead in Module 5 but will do so without explicit knowledge of containers, Docker, or Dockerfiles. Modernizing your development workflow to using containers and best practices like crafting a CI/CD pipeline isn't always straightforward; we hope content like this helps you progress in that direction!

#IamaGDE: Diana Rodríguez Manrique

#IamaGDE series presents: Google Maps Platform

Welcome to #IamaGDE - a series of spotlights presenting Google Developer Experts (GDEs) from across the globe. Discover their stories, passions, and highlights of their community work.

Today, meet Diana Rodríguez— Maps, Web, Cloud, and Firebase GDE.

Google Developer Expert, Diana Rodríguez

Diana Rodríguez’s 20 years in the tech industry have been focused on community and making accessible content. She is a full-stack developer with experience in backend infrastructure, automation, and a passion for Python. A self-taught programmer, Diana also learned programming skills from attending meetups and being an active member of her local developer community. She is the first female Venezuelan GDE.

“I put a lot of myself into public speaking, workshops, and articles,” says Diana. “I want to make everything I do as open and transparent as possible.”

Diana’s first foray into working with Google Maps was in 2016, when she built an app that helped record institutional violence against women in Argentina. As a freelance developer, she uses the Google Maps Platform for her delivery services clients.

“I have plenty of clients who need not only location tracking for their delivery fleet, but also to provide specific routes,” says Diana.

“The level of interaction that’s been added to Maps has made it easier for me as a developer to work with direct clients,” says Diana, who uses the Plus Codes feature to help delivery drivers find precise locations on a map. “I’m a heavy user of plus codes. They give people in remote areas and underserved communities the chance to have location services, including emergency and delivery services.”

Getting involved in the developer community

Diana first became involved in the developer community 20 years ago, in 1999, beginning with a university user group. She attended her first Devfest in Bangkok in 2010 and has worked in multiple developer communities since then. She was a co-organizer of GDG Triangle and is now an organizer of GDG Durham in North Carolina. In 2020, she gave virtual talks to global audiences.

“It’s been great to get to know other communities and reach the far corners of the Earth,” she says.

Image of Diana Rodriguez

Favorite Google Maps Platform features and current projects

Diana is excited about the Places API and the Maps team’s continuous improvements. She says the Maps team keeps the GDEs up to date on all the latest news and takes their feedback very seriously.

“Shoutout to Claire, Alex, and Angela, who are in direct contact with us, and everyone who works with them; they have been amazing,” she says. “I look forward to showcasing more upcoming changes. What comes next will be mind-blowing, immersing people into location in a different way that is more interactive.”

Of the new features released in June 2020, which include Cloud-based maps styling and Local Context, Diana says, “Having the freedom to customize the experience a lot more is amazing.”

As a Maps GDE in 2021, Diana plans to continue working on open source tech projects that benefit the greater good, like her recently completed app for Diabetes users, ScoutX, which notifies emergency contacts when a Diabetic person’s blood glucose values are too high or too low, in case they need immediate help.

She envisions an app that expands connectivity and geolocation tracking for hikers in remote areas, using LoRaWan technologies that can withstand harsh temperatures and conditions.

“Imagine you go to Yellowstone and get lost, with no GPS signal or phone signal, but there’s a tracking device connected to a LoRaWan network sending your location,” Diana says. “It’s much easier for rescue services to find you. Rack Wireless is working on providing satellite access, as well, and having precise latitude and longitude makes mapping simple.”

In the future, Diana sees herself managing a team that makes groundbreaking discoveries and puts technologies to use to help other people.

Follow Diana on Twitter at @cotufa82

Check out Diana’s projects on GitHub

For more information on Google Maps Platform, visit our website.

For more information on Google Developer Experts, visit our website.

#IamaGDE: Diana Rodríguez Manrique

#IamaGDE series presents: Google Maps Platform

Welcome to #IamaGDE - a series of spotlights presenting Google Developer Experts (GDEs) from across the globe. Discover their stories, passions, and highlights of their community work.

Today, meet Diana Rodríguez— Maps, Web, Cloud, and Firebase GDE.

Google Developer Expert, Diana Rodríguez

Diana Rodríguez’s 20 years in the tech industry have been focused on community and making accessible content. She is a full-stack developer with experience in backend infrastructure, automation, and a passion for Python. A self-taught programmer, Diana also learned programming skills from attending meetups and being an active member of her local developer community. She is the first female Venezuelan GDE.

“I put a lot of myself into public speaking, workshops, and articles,” says Diana. “I want to make everything I do as open and transparent as possible.”

Diana’s first foray into working with Google Maps was in 2016, when she built an app that helped record institutional violence against women in Argentina. As a freelance developer, she uses the Google Maps Platform for her delivery services clients.

“I have plenty of clients who need not only location tracking for their delivery fleet, but also to provide specific routes,” says Diana.

“The level of interaction that’s been added to Maps has made it easier for me as a developer to work with direct clients,” says Diana, who uses the Plus Codes feature to help delivery drivers find precise locations on a map. “I’m a heavy user of plus codes. They give people in remote areas and underserved communities the chance to have location services, including emergency and delivery services.”

Getting involved in the developer community

Diana first became involved in the developer community 20 years ago, in 1999, beginning with a university user group. She attended her first Devfest in Bangkok in 2010 and has worked in multiple developer communities since then. She was a co-organizer of GDG Triangle and is now an organizer of GDG Durham in North Carolina. In 2020, she gave virtual talks to global audiences.

“It’s been great to get to know other communities and reach the far corners of the Earth,” she says.

Image of Diana Rodriguez

Favorite Google Maps Platform features and current projects

Diana is excited about the Places API and the Maps team’s continuous improvements. She says the Maps team keeps the GDEs up to date on all the latest news and takes their feedback very seriously.

“Shoutout to Claire, Alex, and Angela, who are in direct contact with us, and everyone who works with them; they have been amazing,” she says. “I look forward to showcasing more upcoming changes. What comes next will be mind-blowing, immersing people into location in a different way that is more interactive.”

Of the new features released in June 2020, which include Cloud-based maps styling and Local Context, Diana says, “Having the freedom to customize the experience a lot more is amazing.”

As a Maps GDE in 2021, Diana plans to continue working on open source tech projects that benefit the greater good, like her recently completed app for Diabetes users, ScoutX, which notifies emergency contacts when a Diabetic person’s blood glucose values are too high or too low, in case they need immediate help.

She envisions an app that expands connectivity and geolocation tracking for hikers in remote areas, using LoRaWan technologies that can withstand harsh temperatures and conditions.

“Imagine you go to Yellowstone and get lost, with no GPS signal or phone signal, but there’s a tracking device connected to a LoRaWan network sending your location,” Diana says. “It’s much easier for rescue services to find you. Rack Wireless is working on providing satellite access, as well, and having precise latitude and longitude makes mapping simple.”

In the future, Diana sees herself managing a team that makes groundbreaking discoveries and puts technologies to use to help other people.

Follow Diana on Twitter at @cotufa82

Check out Diana’s projects on GitHub

For more information on Google Maps Platform, visit our website.

For more information on Google Developer Experts, visit our website.

Cloud NDB to Cloud Datastore migration

Posted by Wesley Chun (@wescpy), Developer Advocate, Google Cloud

An optional migration

Serverless Migration Station is a mini-series from Serverless Expeditions focused on helping users on one of Google Cloud's serverless compute platforms modernize their applications. The video today demonstrates how to migrate a sample app from Cloud NDB (or App Engine ndb) to Cloud Datastore. While Cloud NDB suffices as a current solution for today's App Engine developers, this optional migration is for those who want to consolidate their app code to using a single client library to talk to Datastore.

Cloud Datastore started as Google App Engine's original database but matured to becoming its own standalone product in 2013. At that time, native client libraries were created for the new product so non-App Engine apps as well as App Engine second generation apps could access the service. Long-time developers have been using the original App Engine service APIs to access Datastore; for Python, this would be App Engine ndb. While the legacy ndb service is still available, its limitations and lack of availability in Python 3 are why we recommend users switch to standalone libraries like Cloud NDB in the preceding video in this series.

While Cloud NDB lets users break free from proprietary App Engine services and upgrade their applications to Python 3, it also gives non-App Engine apps access to Datastore. However, Cloud NDB's primary role is a transition tool for Python 2 App Engine developers. Non-App Engine developers and new Python 3 App Engine developers are directed to the Cloud Datastore native client library, not Cloud NDB.

As a result, those with a collection of Python 2 or Python 3 App Engine apps as well as non-App Engine apps may be using completely different libraries (ndb, Cloud NDB, Cloud Datastore) to connect to the same Datastore product. Following the best practices of code reuse, developers should consider consolidating to a single client library to access Datastore. Shared libraries provide stability and robustness with code that's constantly tested, debugged, and battle-proven. Module 2 showed users how to migrate from App Engine ndb to Cloud NDB, and today's Module 3 content focuses on migrating from Cloud NDB to Cloud Datastore. Users can also go straight from ndb directly to Cloud Datastore, skipping Cloud NDB entirely.

Migration sample and next steps

Cloud NDB follows an object model identical to App Engine ndb and is deliberately meant to be familiar to long-time Python App Engine developers while use of the Cloud Datastore client library is more like accessing a JSON document store. Their querying styles are also similar. You can compare and contrast them in the "diffs" screenshot below and in the video.

The diffs between the Cloud NDB and Cloud Datastore versions of the sample app

The "diffs" between the Cloud NDB and Cloud Datastore versions of the sample app

All that said, this migration is optional and only useful if you wish to consolidate to using a single client library. If your Python App Engine apps are stable with ndb or Cloud NDB, and you don't have any code using Cloud Datastore, there's no real reason to move unless Cloud Datastore has a compelling feature inaccessible from your current client library. If you are considering this migration and want to try it on a sample app before considering for yours, see the corresponding codelab and use the video for guidance.

It begins with the Module 2 code completed in the previous codelab/video; use your solution or ours as the "START". Both Python 2 (Module 2a folder) and Python 3 (Module 2b folder) versions are available. The goal is to arrive at the "FINISH" with an identical, working app but using a completely different Datastore client library. Our Python 2 FINISH can be found in the Module 3a folder while Python 3's FINISH is in the Module 3b folder. If something goes wrong during your migration, you can always rollback to START, or compare your solution with our FINISH. We will continue our Datastore discussion ahead in Module 6 as Cloud Firestore represents the next generation of the Datastore service.

All of these learning modules, corresponding videos (when published), codelab tutorials, START and FINISH code, etc., can be found in the migration repo. We hope to also one day cover other legacy runtimes like Java 8 and others, so stay tuned. Up next in Module 4, we'll take a different turn and showcase a product crossover, showing App Engine developers how to containerize their apps and migrate them to Cloud Run, our scalable container-hosting service in the cloud. If you can't wait for either Modules 4 or 6, try out their respective codelabs or access the code samples in the table at the repo above. Migrations aren't always easy, and we hope content like this helps you modernize your apps.

Migrating from App Engine ndb to Cloud NDB

Posted by Wesley Chun (@wescpy), Developer Advocate, Google Cloud

Migrating to standalone services

Today we're introducing the first video showing long-time App Engine developers how to migrate from the App Engine ndb client library that connects to Datastore. While the legacy App Engine ndb service is still available for Datastore access, new features and continuing innovation are going into Cloud Datastore, so we recommend Python 2 users switch to standalone product client libraries like Cloud NDB.

This video and its corresponding codelab show developers how to migrate the sample app introduced in a previous video and gives them hands-on experience performing the migration on a simple app before tackling their own applications. In the immediately preceding "migration module" video, we transitioned that app from App Engine's original webapp2 framework to Flask, a popular framework in the Python community. Today's Module 2 content picks up where that Module 1 leaves off, migrating Datastore access from App Engine ndb to Cloud NDB.

Migrating to Cloud NDB opens the doors to other modernizations, such as moving to other standalone services that succeed the original App Engine legacy services, (finally) porting to Python 3, breaking up large apps into microservices for Cloud Functions, or containerizing App Engine apps for Cloud Run.

Moving to Cloud NDB

App Engine's Datastore matured to becoming its own standalone product in 2013, Cloud Datastore. Cloud NDB is the replacement client library designed for App Engine ndb users to preserve much of their existing code and user experience. Cloud NDB is available in both Python 2 and 3, meaning it can help expedite a Python 3 upgrade to the second generation App Engine platform. Furthermore, Cloud NDB gives non-App Engine apps access to Cloud Datastore.

As you can see from the screenshot below, one key difference between both libraries is that Cloud NDB provides a context manager, meaning you would use the Python with statement in a similar way as opening files but for Datastore access. However, aside from moving code inside with blocks, no other changes are required of the original App Engine ndb app code that accesses Datastore. Of course your "YMMV" (your mileage may vary) depending on the complexity of your code, but the goal of the team is to provide as seamless of a transition as possible as well as to preserve "ndb"-style access.

The difference between the App Engine ndb and Cloud NDB versions of the sample app

The "diffs" between the App Engine ndb and Cloud NDB versions of the sample app

Next steps

To try this migration yourself, hit up the corresponding codelab and use the video for guidance. This Module 2 migration sample "STARTs" with the Module 1 code completed in the previous codelab (and video). Users can use their solution or grab ours in the Module 1 repo folder. The goal is to arrive at the end with an identical, working app that operates just like the Module 1 app but uses a completely different Datastore client library. You can find this "FINISH" code sample in the Module 2a folder. If something goes wrong during your migration, you can always rollback to START, or compare your solution with our FINISH. Bonus content migrating to Python 3 App Engine can also be found in the video and codelab, resulting in a second FINISH, the Module 2b folder.

All of these learning modules, corresponding videos (when published), codelab tutorials, START and FINISH code, etc., can be found in the migration repo. We hope to also one day cover other legacy runtimes like Java 8 and others, so stay tuned! Developers should also check out the official Cloud NDB migration guide which provides more migration details, including key differences between both client libraries.

Ahead in Module 3, we will continue the Cloud NDB discussion and present our first optional migration, helping users move from Cloud NDB to the native Cloud Datastore client library. If you can't wait, try out its codelab found in the table at the repo above. Migrations aren't always easy; we hope this content helps you modernize your apps and shows we're focused on helping existing users as much as new ones.

#IamaGDE: Homing Tam

#IamaGDE series presents: Google Maps

Welcome to #IamaGDE - a series of spotlights presenting Google Developer Experts (GDEs) from across the globe. Discover their stories, passions, and highlights of their community work.

image of GDE, Homing Tam

Homing Tam is a product manager at Lalamove, an on-demand logistics company. He started at the company as a product manager focusing on location-based systems, talking with developers and business users to enhance the company’s mapping solutions, before moving into product management. Now, Homing handles corporate solutions; takes care of people who want to integrate with his company’s systems; handles the API side of things to help make integration easier; and provides recommendations for developers and other technical teammates.

Becoming a Maps developer

Homing studied geomatics and computing at university, and his 2009 thesis was based on Google’s API backend. His dissertation focused on using the Google Maps API to perform mapping and overlay. His first full-time job was as a GIS analyst at Esri, the largest private software company in the world. A year and a half later, he became a solutions consultant for a different company, helping customers interested in integrating Google Maps with their software.

image of developer community meetup

Getting involved in the developer community

After Homing got involved in the Google Technology User Group (now known as Google Developer Groups), his boss at the time told him about the Google Developer Experts program. For his interview, Homing presented a product using the Google Maps APIs. When he became a GDE, he gave presentations and talks in the greater China region as a surrogate for the Google Maps Platform team. Homing is currently one of the organizers for GDG Hong Kong, organizing and giving community talks.

Favorite Maps features and current projects

Homing says the Maps Styling Wizard, the precursor to the newer Cloud-based Maps Styling features, is one of his favorite features.

“Cartography, which I studied in college, matters a lot, especially to a simple black and white schematic map, or when matching the theme of a map to a site,” he says. “I like that feature a lot.”

In 2020, Homing gave one talk on Android in the Android 11 Meetup and another talk on Maps at the first-ever virtual Hong Kong Devfest, and he’s ready to do more speaking.

“It had been a while since I gave a talk on maps, and the launch of Cloud-based Maps Styling is so exciting that I feel like it’s time to do some presentations and let the community know more about it. Beyond knowing how to use the API, you need to know how you can make the most of the API.”

Homing notes that this year, in particular, more small business owners need to know how to collect customer addresses, allow customers to place on-demand delivery orders, and update customers.

image from GDG developer community meetup in Hong Kong

In 2021, in addition to giving more talks, Homing hopes to work with the GDG organizers in Hong Kong to plan a hackathon or otherwise teach community members more about the new Maps features.

“Can we make an MVP or a really initial stage cycling app to use as a base to explore the new features and use different Google components?’

As his career continues, Homing says he has two priorities: progressing as a product manager and leveraging technology, including maps, to improve lives.

“This year was a year for everyone to become digitally literate,” he says. “With the extra time we spend on technology, we should make good use of technology to make life better.”

For more information on Google Maps Platform, visit our website.

For more information on Google Developer Experts, visit our website.

Migrating from App Engine webapp2 to Flask

Posted by Wesley Chun (@wescpy), Developer Advocate, Google Cloud
graphic showing movement with arrows,. settings, lines, and more

Migrating web framework

The Google Cloud team recently introduced a series of codelabs (free, self-paced, hands-on tutorials) and corresponding videos designed to help users on one of our serverless compute platforms modernize their apps, with an initial focus on our earliest users running their apps on Google App Engine. We kick off this content by showing users how to migrate from App Engine's webapp2 web framework to Flask, a popular framework in the Python community.

While users have always been able to use other frameworks with App Engine, webapp2 comes bundled with App Engine, making it the default choice for many developers. One new requirement in App Engine's next generation platform (which launched in 2018) is that web frameworks must do their own routing, which unfortunately, means that webapp2 is no longer supported, so here we are. The good news is that as a result, modern App Engine is more flexible, lets users to develop in a more idiomatic fashion, and makes their apps more portable.

For example, while webapp2 apps can run on App Engine, Flask apps can run on App Engine, your servers, your data centers, or even on other clouds! Furthermore, Flask has more users, more published resources, and is better supported. If Flask isn't right for you, you can select from other WSGI-compliant frameworks such as Django, Pyramid, and others.

Video and codelab content

In this "Module 1" episode of Serverless Migration Station (part of the Serverless Expeditions series) Google engineer Martin Omander and I explore this migration and walk developers through it step-by-step.

In the previous video, we introduced developers to the baseline Python 2 App Engine NDB webapp2 sample app that we're taking through each of the migrations. In the video above, users see that the majority of the changes are in the main application handler, MainHandler:

The diffs between the webapp2 and Flask versions of the sample app

The "diffs" between the webapp2 and Flask versions of the sample app

Upon (re)deploying the app, users should see no visible changes to the output from the original version:

VisitMe application sample output

VisitMe application sample output

Next steps

Today's video picks up from where we left off: the Python 2 baseline app in its Module 0 repo folder. We call this the "START". By the time the migration has completed, the resulting source code, called "FINISH", can be found in the Module 1 repo folder. If you mess up partway through, you can rewind back to the START, or compare your solution with ours, FINISH. We also hope to one day provide a Python 3 version as well as cover other legacy runtimes like Java 8, PHP 5, and Go 1.11 and earlier, so stay tuned!

All of the migration learning modules, corresponding videos (when published), codelab tutorials, START and FINISH code, etc., can all be found in the migration repo. The next video (Module 2) will cover migrating from App Engine's ndb library for Datastore to Cloud NDB. We hope you find all these resources helpful in your quest to modernize your serverless apps!

A new Android smartphone and 5G partnership with Jio


Thank you to everyone at Reliance Industries for all you do for India from investing in infrastructure and technology to creating jobs and expanding opportunity to supporting communities in need, especially in this difficult moment for the country.


It’s been devastating to see the country hit so hard by COVID-19. Yet it’s heartening to see how Reliance has stepped up to contribute to the national response and get support to the communities that need it most. On behalf of all of us at Google: We hope you are taking care and we are wishing for better days ahead.


For Google, the past year has brought renewed purpose and greater urgency to our mission to organize the world’s information and make it universally accessible and useful. At a time when so many aspects of our lives and work are moving online, it’s even more important to make technology accessible and helpful for everyone. 


This goal is at the heart of our partnership with Reliance Jio. I was proud to help launch this partnership last year. It was the first and biggest equity investment from the ₹75,000 crore ($10 billion) Google for India Digitization Fund.


Our vision was to bring affordable access to information for Indians in their own language, to build new products and services for India’s unique needs, and to empower businesses with technology.


I’m excited that today, we can announce the next steps in this vision, starting with a new, affordable Jio smartphone, created with Google. Our teams have optimized a version of our Android OS especially for this device. It will offer language and translation features, a great camera, and support for the latest Android updates.


It is built for India and it will open up new possibilities for millions of new users who will experience the internet for the very first time. And we can’t wait to show you the device later this year.


I’m also proud to announce that we are taking our collaboration further with a new 5G partnership between Google Cloud and Jio.


It will help more than a billion Indians connect to a faster and better internet, support businesses in their digital transformation, and help Jio build new services in sectors like health, education and more — laying a foundation for the next phase of India’s digitization.  

As part of this collaboration, Reliance will also shift its core retail businesses to Google Cloud’s infrastructure. They will be able take advantage of Google’s AI and machine learning, e-commerce, and demand forecasting offerings. Harnessing the reliability and performance of Google Cloud will enable these businesses to scale up as needed to respond to customer demand. 

Empowering businesses as they embark on their digital transformation is a key part of our mission in India, and I’m excited for the innovations this partnership will help unleash. We are proud to play a part in India’s next wave of technological innovation. 


Helping to connect 1.3 billion Indians to the opportunities the internet creates is meaningful to all of us at Google — and certainly to me personally. I know that with greater access to smartphones and improved connectivity, there’s no limit to what India’s people can do. 


We look forward to getting technology into the hands of more people and to exploring what more we can achieve together in the years ahead.


Posted by Sundar Pichai, CEO of Google and Alphabet


Partnering with Jio to help bring the promise of internet connectivity and affordability to everyone

From the infrastructure that facilitates widespread connectivity to the availability of truly affordable smartphones, we have been committed to finding ways to help bring ubiquitous access to information to people everywhere. With the pandemic resulting in greater dependency on online services and the need for timely information, access to the internet is especially crucial today. But hundreds of millions of Indians are yet to benefit from being connected, to utilize services and access information that can have a positive and immediate impact on their daily lives. Today we are excited to give you an update on our partnership with Jio in two key areas that can help bridge this gap.


Making the internet accessible to millions of more Indians with Jio


While millions of people across India who use feature phones want access to a full-fledged smartphone, there exists gaps in usability and affordability that prevent these aspirations from becoming reality.


Our Android teams across the globe have been hard at work in finding solutions to these challenges. A big milestone in this journey was our announcement last year to invest in Jio Platforms Ltd to address this gap by jointly creating a device based on optimizations to the Android operating system and the Play Store that serves the needs of many who have never used a smartphone before, while offering premium capabilities that have until now been associated with more powerful devices.

Along with Jio we are thrilled to share a preview of our made-for-India device that is built to address the unique needs of millions of new smartphone users across India. We have worked closely with the Jio team on engineering and product development on useful voice-first features that enable these users to consume content and navigate the phone in their own language, deliver a great camera experience, and get the latest Android feature and security updates.


Image 1: Use Google Assistant to get things done in popular Jio apps; Image 2: Listen to any content on your phone screen by tapping the ‘Listen’ button; Image 3: Quickly Translate any content -- on your phone screen or in the phone’s camera


Easily access and consume content in a choice of Indian languages: For users who might not be able to read content in their language, with a tap of a button they can now translate what’s on their screen, and even have it read back to them in their own language. Read Aloud and Translate Now are seamlessly integrated in the OS allowing these features to work with any text on their phone screen, including web pages, apps, messages, and even photos. We’ve also added App Actions that enable Google Assistant to deliver a great experience with many of the Jio apps on this device. In addition to asking for the latest cricket scores or a weather update, you can also ask Google Assistant to play music on Jio Saavn or check your balance on My Jio.


Image 1: Clearer photos in low light with Night mode; Image 2: Photos have wider dynamic range with HDR mode; Image 3: Snapchat lenses bring Indian-specific effects to your selfies


A great camera experience: A fast, high-quality camera is a must-have feature for today's smartphone users, so we partnered closely to build an optimized experience within the phone’s Camera module resulting in great photos and videos: from clearer photos at night and in low-light situations to HDR mode that brings out wider color and dynamic range in photos, these are firsts for affordable phones in India. We have also partnered with Snap to integrate Indian-specific Snapchat Lenses directly into the phone’s camera, and we will continue to update this experience.


Ongoing feature drops and the latest system updates: Along with support for the latest Android releases and security updates, this experience will keep getting better with new features and customizations, all delivered over-the-air. With Google Play Protect built in, it has Google’s world-class security and malware protection. And with the Google Play Store, you will have access to millions of apps that people across the world use and enjoy.


The smartphone being developed with Jio will be called JioPhone Next. It will be coming later this year, and will enable scores of new internet users to experience these best-in-class Android smartphone features at an affordable price. This is a momentous step in our Android mission for India, and is the first of many that our Android product and engineering teams will embark on in India. We are also actively expanding our engineering teams in India, as we continue to work on finding ways to answer the unique needs of India’s smartphone users.


Powering Jio’s services with a new Google Cloud Partnership


We’re delighted to share that Jio and Google Cloud are embarking on a new long-term, strategic partnership, independent of our investment in Jio Platforms Ltd, with a goal of powering 5G in enterprise and consumer segments in India. Jio will take advantage of Google Cloud’s scalable infrastructure and will also migrate many of their core businesses to Google Cloud.


Google Cloud’s deep expertise and innovation, combined with telco-specific capabilities for security, performance, and resilience, will help Jio’s 5G service to deliver high speed internet as demand for connectivity goes up. The two companies will collaborate to bring a portfolio of 5G edge computing solutions as Jio builds new services across many verticals including gaming, healthcare, education, and entertainment. These will be powered by Jio’s 5G network and Google Cloud’s innovations in AI/ML, data and analytics, and other cloud-native technologies. 


This new Cloud partnership will also see Reliance migrating its core retail businesses like Reliance Retail, JioMart, JioHealth, JioSaavn and others to Google Cloud’s infrastructure, taking advantage of Google’s AI/ML, ecommerce, and demand forecasting offerings. Leveraging the scalability of Google Cloud will increase reliability and performance, as well as enable these businesses to scale up to respond to customer demand.  


We are deeply privileged to play a role in the next phase of India’s digital transformation and we look forward to working closely with Jio to share more on these developments in the months ahead.


Posted by Ram Papatla GM & India Engineering Lead, Android, and Bikram Singh Bedi, Managing Director, Google Cloud India