Migrating from App Engine Memcache to Cloud Memorystore (Module 13)

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

Introduction and background

The previous Module 12 episode of the Serverless Migration Station video series demonstrated how to add App Engine Memcache usage to an existing app that has transitioned from the webapp2 framework to Flask. Today’s Module 13 episode continues its modernization by demonstrating how to migrate that app from Memcache to Cloud Memorystore. Moving from legacy APIs to standalone Cloud services makes apps more portable and provides an easier transition from Python 2 to 3. It also makes it possible to shift to other Cloud compute platforms should that be desired or advantageous. Developers benefit from upgrading to modern language releases and gain added flexibility in application-hosting options.

While App Engine Memcache provides a basic, low-overhead, serverless caching service, Cloud Memorystore “takes it to the next level” as a standalone product. Rather than a proprietary caching engine, Cloud Memorystore gives users the option to select from a pair of open source engines, Memcached or Redis, each of which provides additional features unavailable from App Engine Memcache. Cloud Memorystore is typically more cost efficient at-scale, offers high availability, provides automatic backups, etc. On top of this, one Memorystore instance can be used across many applications as well as incorporates improvements to memory handling, configuration tuning, etc., gained from experience managing a huge fleet of Redis and Memcached instances.

While Memcached is more similar to Memcache in usage/features, Redis has a much richer set of data structures that enable powerful application functionality if utilized. Redis has also been recognized as the most loved database by developers in StackOverflow’s annual developers survey, and it’s a great skill to pick up. For these reasons, we chose Redis as the caching engine for our sample app. However, if your apps’ usage of App Engine Memcache is deeper or more complex, a migration to Cloud Memorystore for Memcached may be a better option as a closer analog to Memcache.

Migrating to Cloud Memorystore for Redis featured video


Performing the migration

The sample application registers individual web page “visits,” storing visitor information such as IP address and user agent. In the original app, the most recent visits are cached into Memcache for an hour and used for display if the same user continuously refreshes their browser during this period; caching is a one way to counter this abuse. New visitors or cache expiration results new visits as well as updating the cache with the most recent visits. Such functionality must be preserved when migrating to Cloud Memorystore for Redis.

Below is pseudocode representing the core part of the app that saves new visits and queries for the most recent visits. Before, you can see how the most recent visits are cached into Memcache. After completing the migration, the underlying caching infrastructure has been swapped out in favor of Memorystore (via language-specific Redis client libraries). In this migration, we chose Redis version 5.0, and we recommend the latest versions, 5.0 and 6.x at the time of this writing, as the newest releases feature additional performance benefits, fixes to improve availability, and so on. In the code snippets below, notice how the calls between both caching systems are nearly identical. The bolded lines represent the migration-affected code managing the cached data.

Switching from App Engine Memcache to Cloud Memorystore for Redis

Wrap-up

The migration covered begins with the Module 12 sample app (“START”). Migrating the caching system to Cloud Memorystore and other requisite updates results in the Module 13 sample app (“FINISH”) along with an optional port to Python 3. To practice this migration on your own to help prepare for your own migrations, follow the codelab to do it by-hand while following along in the video.

While the code migration demonstrated seems straightforward, the most critical change is that Cloud Memorystore requires dedicated server instances. For this reason, a Serverless VPC connector is also needed to connect your App Engine app to those Memorystore instances, requiring more dedicated servers. Furthermore, neither Cloud Memorystore nor Cloud VPC are free services, and neither has an “Always free” tier quota. Before moving forward this migration, check the pricing documentation for Cloud Memorystore for Redis and Serverless VPC access to determine cost considerations before making a commitment.

One key development that may affect your decision: In Fall 2021, the App Engine team extended support of many of the legacy bundled services like Memcache to next-generation runtimes, meaning you are no longer required to migrate to Cloud Memorystore when porting your app to Python 3. You can continue using Memcache even when upgrading to 3.x so long as you retrofit your code to access bundled services from next-generation runtimes.

A move to Cloud Memorystore and today’s migration techniques will be here if and when you decide this is the direction you want to take for your App Engine apps. 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, we plan to cover other language runtimes, so stay tuned. For additional video content, check out our broader Serverless Expeditions series.

Experts.Anyone.Anywhere

Posted by Janelle Kuhlman, Developer Relations Program Manager

Click above to meet our community of Experts

The Google Developer Experts program is a global network of highly experienced technology experts, developers and thought leaders. GDEs share their expertise with other developers and tech communities through a variety of ways such as speaking engagements, mentorship and content writing. The community has access to an exclusive network of experts that span across different Google technologies including Android, Cloud, Machine Learning and more.

Get to know our diverse community and subscribe to the Google Developers YouTube Channel to stay informed on the latest updates across our products and platforms!

How to use App Engine Memcache in Flask apps (Module 12)

Posted by Wesley Chun

Background

In our ongoing Serverless Migration Station series aimed at helping developers modernize their serverless applications, one of the key objectives for Google App Engine developers is to upgrade to the latest language runtimes, such as from Python 2 to 3 or Java 8 to 17. Another objective is to help developers learn how to move away from App Engine legacy APIs (now called “bundled services”) to Cloud standalone equivalent services. Once this has been accomplished, apps are much more portable, making them flexible enough to:

In today’s Module 12 video, we’re going to start our journey by implementing App Engine’s Memcache bundled service, setting us up for our next move to a more complete in-cloud caching service, Cloud Memorystore. Most apps typically rely on some database, and in many situations, they can benefit from a caching layer to reduce the number of queries and improve response latency. In the video, we add use of Memcache to a Python 2 app that has already migrated web frameworks from webapp2 to Flask, providing greater portability and execution options. More importantly, it paves the way for an eventual 3.x upgrade because the Python 3 App Engine runtime does not support webapp2. We’ll cover both the 3.x and Cloud Memorystore ports next in Module 13.

Got an older app needing an update? We can help with that.

Adding use of Memcache

The sample application registers individual web page “visits,” storing visitor information such as the IP address and user agent. In the original app, these values are stored immediately, and then the most recent visits are queried to display in the browser. If the same user continuously refreshes their browser, each refresh constitutes a new visit. To discourage this type of abuse, we cache the same user’s visit for an hour, returning the same cached list of most recent visits unless a new visitor arrives or an hour has elapsed since their initial visit.

Below is pseudocode representing the core part of the app that saves new visits and queries for the most recent visits. Before, you can see how each visit is registered. After the update, the app attempts to fetch these visits from the cache. If cached results are available and “fresh” (within the hour), they’re used immediately, but if cache is empty, or a new visitor arrives, the current visit is stored as before, and this latest collection of visits is cached for an hour. The bolded lines represent the new code that manages the cached data.

Adding App Engine Memcache usage to sample app

Wrap-up

Today’s “migration” began with the Module 1 sample app. We added a Memcache-based caching layer and arrived at the finish line with the Module 12 sample app. To practice this on your own, follow the codelab doing it by-hand while following the video. The Module 12 app will then be ready to upgrade to Cloud Memorystore should you choose to do so.

In Fall 2021, the App Engine team extended support of many of the bundled services to next-generation runtimes, meaning you are no longer required to migrate to Cloud Memorystore when porting your app to Python 3. You can continue using Memcache 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 Cloud Memorystore, stay tuned for the Module 13 video or try its codelab to get a sneak peek. 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, we hope to one day cover other language runtimes, so stay tuned. For additional video content, check out our broader Serverless Expeditions series.

Celebrating leaders in AAPI communities

Posted by Google Developer Studio

In recognition of Asian Americans and Pacific Islanders Heritage Month, we are speaking with mentors and leaders in tech and who identify as part of the AAPI community. Many of the influential figures we feature are involved with and help champion inclusivity programs like Google Developer Experts and Google Developer Student Clubs, while others work on leading in product areas like TensorFlow and drive impact through their line of work and communities.

On that note, we are honoring this year’s theme of “Advancing Leaders Through Collaboration” by learning more about the power of mentorship, advice they’ve received from other leaders, and their biggest accomplishments.

Read more about leads in the AAPI community below.

Ben Hong

Senior Staff Developer Experience Engineer at Netlify

What’s the best piece of advice you can offer new/junior developers looking to grow into leadership roles?

There is a lot of advice out there on how to get the most out of your career by climbing the ladder and getting leadership roles. Before you embark on that journey, first ask yourself the question “Why do I want this?”

Becoming a leader comes with a lot of glitz and glamor, but the reality is that it carries a huge weight of responsibility because the decisions and actions you take as a leader will impact the lives of those around you in significant ways you can’t foresee.

As a result, the key to becoming the best leader you can be is to:

  1. Establish what your values and principles are
  2. Align them to the actions you take each and every day

Because at the end of the day, leaders are often faced with difficult decisions that lead to an uncertain future. And without core values and principles to guide you as an individual, you run the risk of being easily swayed by short term trade offs that could result in a long term loss.

This world needs leaders who can stand their ground against the temptations of short-term wins and make the best decisions they can while fighting for those that follow them. If you stand firm in your values and listen to those around you, you’ll be able to create profound impact in your community.

Taha Bouhsine

Data Scientist and GDSCUIZ Lead

What’s the best piece of advice you can offer new/junior developers looking to grow into leadership roles?

Create a journey worth taking. You will face many challenges and a new set of problems. You will start asking a lot of questions as everything seems to be unfamiliar.

Things get much lighter if you are guided by a mentor, as you will get guidance on how to act in this new chapter of life. In your early days, invest as much as you can in building and nurturing a team, as it will save you a lot of time along the road. Surround yourself with real people who take the initiative, get to the action, and are willing to grow and learn, nurture their skills and guide them towards your common goal. Don’t try to be a people pleaser as it’s an impossible mission.

Your actions will offend some people one way or the other. That’s ok as you should believe in your mission, create a clear plan with well-defined tasks and milestones, and be firm with your decision. In the end, responsibility is yours to bear, so at least take it on something you decided, not something that was forced upon you by others.

Finally, when there is fire, look for ways to put it out. Take care of your soul, and enjoy the journey!

Huyen Tue Dao

Android Developer, Trello

What do you love most about being a part of the developer community?

It has been the most rewarding and critical part of my career to meet other developers, learning and sharing knowledge and getting to know them as human beings.

Development is a job of constant learning, whether it is the latest technology, trends, issues, and challenges or the day-to-day intricacies and nuances of writing specialized code and solving problems in efficient and elegant ways. I don’t think I’d have the tools to solve issues large and small without the sharing of knowledge and experience of the developer community. If you’re having a problem of any kind, chances are that someone has had the same challenges. You can take comfort that you can probably find the answer or at least find people that can help you. You can also feel confident that if you discovered something new or learned important lessons, someone will want to hear what you have to say.

I love seeing and being part of this cycle and interchange; as we pool our experience, our knowledge, and insights, we become stronger and more skilled as a community. I would not be the engineer or person that I am without the opportunities of this exchange.

Just as important, though, is the camaraderie and support of those who do what I do and love it. I have been so fortunate to have been in communities that have been open and welcoming, ready to make connections and form networks, eager to celebrate victories and commiserate with challenges. Regardless of the technical and personal challenges of the everyday that may get to me, there are people that understand and can support me and provide brilliantly diverse perspectives of different industries, countries, cultures, and ages.

Malak Magdy Ali

Google Developer Student Club Lead at Canadian International College, Egypt

What’s the best piece of advice you can offer new/junior developers looking to grow into leadership roles?

The best piece of advice I can give to new leaders is to have empathy. Having empathy will make you understand people’s actions and respect their feelings. This will make for stronger teams.

Also, give others a space to lead. Involve your team in making decisions; they come up with great ideas that can help you and teammates learn from each other. In this process, trust is also built, resulting in a better quality product.

Finally, don’t underestimate yourself. Do your best and involve your team to discuss the overall quality of your work and let them make recommendations.

How can App Engine users take advantage of Cloud Functions?

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

Introduction

Recently, we discussed containerizing App Engine apps for Cloud Run, with or without Docker. But what about Cloud Functions… can App Engine users take advantage of that platform somehow? Back in the day, App Engine was always the right decision, because it was the only option. With Cloud Functions and Cloud Run joining in the serverless product suite, that’s no longer the case.

Back when App Engine was the only choice, it was selected to host small, single-function apps. Yes, when it was the only option. Other developers have created huge monolithic apps for App Engine as well… because it was also the only option. Fast forward to today where code follows more service-oriented or event-driven architectures. Small apps can be moved to Cloud Functions to simplify the code and deployments while large apps could be split into smaller components, each running on Cloud Functions.

Refactoring App Engine apps for Cloud Functions

Small, single-function apps can be seen as a microservice, an API endpoint “that does something,” or serve some utility likely called as a result of some event in a larger multi-tiered application, say to update a database row or send a customer email message. App Engine apps require some kind web framework and routing mechanism while Cloud Function equivalents can be freed from much of those requirements. Refactoring these types of App Engine apps for Cloud Functions will like require less overhead, helps ease maintenance, and allow for common components to be shared across applications.

Large, monolithic applications are often made up of multiple pieces of functionality bundled together in one big package, such as requisitioning a new piece of equipment, opening a customer order, authenticating users, processing payments, performing administrative tasks, and so on. By breaking this monolith up into multiple microservices into individual functions, each component can then be reused in other apps, maintenance is eased because software bugs will identify code closer to their root origins, and developers won’t step on each others’ toes.

Migration to Cloud Functions

In this latest episode of Serverless Migration Station, a Serverless Expeditions mini-series focused on modernizing serverless apps, we take a closer look at this product crossover, covering how to migrate App Engine code to Cloud Functions. There are several steps you need to take to prepare your code for Cloud Functions:

  • Divest from legacy App Engine “bundled services,” e.g., Datastore, Taskqueue, Memcache, Blobstore, etc.
  • Cloud Functions supports modern runtimes; upgrade to Python 3, Java 11, or PHP 7
  • If your app is a monolith, break it up into multiple independent functions. (You can also keep a monolith together and containerize it for Cloud Run as an alternative.)
  • Make appropriate application updates to support Cloud Functions

    The first three bullets are outside the scope of this video and its codelab, so we’ll focus on the last one. The changes needed for your app include the following:

    1. Remove unneeded and/or unsupported configuration
    2. Remove use of the web framework and supporting routing code
    3. For each of your functions, assign an appropriate name and install the request object it will receive when it is called.

    Regarding the last point, note that you can have multiple “endpoints” coming into a single function which processes the request path, calling other functions to handle those routes. If you have many functions in your app, separate functions for every endpoint becomes unwieldy; if large enough, your app may be more suited for Cloud Run. The sample app in this video and corresponding code sample only has one function, so having a single endpoint for that function works perfectly fine here.

    This migration series focuses on our earliest users, starting with Python 2. Regarding the first point, the app.yaml file is deleted. Next, almost all Flask resources are removed except for the template renderer (the app still needs to output the same HTML as the original App Engine app). All app routes are removed, and there’s no instantiation of the Flask app object. Finally for the last step, the main function is renamed more appropriately to visitme() along with a request object parameter.

    This “migration module” starts with the (Python 3 version of the) Module 2 sample app, applies the steps above, and arrives at the migrated Module 11 app. Implementing those required changes is illustrated by this code “diff:”

    Migration of sample app to Cloud Functions

    Next steps

    If you’re interested in trying this migration on your own, feel free to try the corresponding codelab which leads you step-by-step through this exercise and use the video for additional 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 as well as content for the next-generation Cloud Functions service, so stay tuned. If you’re curious whether it’s possible to write apps that can run on App Engine, Cloud Functions, or Cloud Run with no code changes at all, the answer is yes. Hope this content is useful for your consideration when modernizing your own serverless applications!

Celebrating global women in tech and trailblazers

Posted by Google Developer Studio

In honor of Women’s History Month, we are featuring tech trailblazers who have made significant contributions to developer communities close to Google and beyond. Many of the women we spoke to work directly with some of our educational outreach and inclusivity programs like Google Developer Experts and Women Techmakers, while others are Google Developer Student Clubs participants or Googlers who do incredible work around the globe.

They all share a passion for making the developer community more accessible and inclusive for generations of women to come. Read about them below to learn more about these individuals whose drive contributes to a better workplace and world.

We’re proud to celebrate #WHM22 with them.

Google Developer Experts

Laura Morillo-Velarde Rodríguez

Guest’s location: Zaragoza, Spain

Tell us more about your role.

I work as a Tech Lead at Seedtag, a contextual advertising company, where I help build an amazing tech team to go through all the technical challenges that we have to face. Besides that, I’m also a Women Techmakers Ambassador and Cloud Google Developer Expert.

Is there a project you’ve worked on recently that you’re excited to share?

During the pandemic I started recording podcasts (in Spanish) with some friends (GDG Spain Podcast, Cloud Español) and one of those is Tech & Ladies Podcast. Every two weeks Cristina Pampín, Silvia García and I talk with other women in tech about their careers, different technologies or other topics related to the tech space.

What makes you passionate about being in the tech space?

I’m passionate about the tech space because you always have something new to learn. I think that this can be a bit overwhelming sometimes, as you need to find the time and it usually involves a lot of self-study, but it also prevents our work from becoming boring.

What is the biggest piece of advice you would offer professionals starting in the tech space?

I would recommend them to make the most of the technical communities that we have. There, you can learn a lot, meet amazing people and contribute to the growth of others with your knowledge and experience.

Luz Maria Maida Claude

Guest’s Location: Ingelheim, Germany

Tell us more about your role.

I’ve been a Software Engineer for the last 7 years. Right now, I’m working at BIX that is the Digital Lab of Boehringer Ingelheim. Although my job description is “Frontend Engineer,” the reality is that every day I have different challenges that involve a great diversity of technologies and tools.

Is there a project you’ve worked on recently that you’re excited to share?

With my team I created some prototypes using hardware oriented to the healthcare systems. In my free time I’m creating a project to collect funds for stray animals.

What makes you passionate about being in the tech space?

Technology gives us the power to turn our ideas into reality, but many of the things that are in our lives today are there because we share our knowledge with others. Thanks to many communities and groups we have more opportunities to improve our environments and grow step by step, something that is important in this time where we need to create changes.

What is the biggest piece of advice you would offer professionals starting in the tech space?

Be curious, trust in yourself and enjoy the journey. It is important to understand that every day counts to reach the objectives that we have. We’ll never have all the knowledge, but your current version knows something more than yesterday and the last week. Don’t stop and continue growing.

Google’s Coding Competitions

Chu-Ling Ko

Guest’s Location: Palo Alto, California

Tell us more about your role

I am a software engineer at Google for Clinicians of Google Health. Also, I am a volunteer for Google’s Coding Competitions. We develop the coding competition problems for Kick Start, Code Jam, and Code Jam to I/O for Women!

Is there a project you’ve worked on recently that you’re excited to share?

Recently, a group of women volunteers including me are working together to develop the problem sets for Code Jam to I/O for Women 2022. We prepare input verifiers, test case generators, various solutions (and some fake ones), and solution articles. It is so exciting that we are all a part of this amazing event!

What makes you passionate about being in the tech space?

I am so passionate about this work because it is something that helps people. Google’s Coding Competition team produces plenty of high-quality problem sets every year, along with comprehensible, educational solution articles. We hope the participants can enjoy and learn new things from each of our coding competitions!

What is the biggest piece of advice you would offer professionals starting in the tech space?

Enjoy and take everything you are doing seriously, and appreciate the people you meet in the adventure!

Tatiyana Mishtal

Guest’s Location: Zurich, Switzerland

Tell us more about your role.

I’m a Senior Software Engineer at YouTube Content ID, also TL of our team. We are working on detection of copyright violations on YouTube. Due to the specifics of our product, we have a very intensive Quality focus – I spend a lot of time on data analysis and cross-team collaboration to improve automated decisions made. At the same time reliability requirements, new signals development and continuous improvements to YouTube infrastructure bring endless interesting engineering challenges as well.

Is there a project you’ve worked on recently that you’re excited to share?

In addition to my main project, I’m also part of the Hash Code team. For several years already we have organized this coding competition for developers of all levels from all around the world. And just a few weeks ago we held the 2022 Qualification Round, which was especially challenging for us. Not only did we need to prepare a hard and exciting problem for the competition as we do every year, but also we had migrated to the new Google Coding Competitions platform and it was our debut there. Thanks to ours and the Coding Competitions team’s joint effort everything went smoothly!

What makes you passionate about being in the tech space?

I really like making things work. I enjoy solving problems, overcoming challenges and in the end seeing how results impact people’s lives. I especially value personal time and it delights me that technology can both improve the quality of people’s lives and cut the “time cost” of many mundane things.

What is the biggest piece of advice you would offer professionals starting in the tech space?

Ask “why” instead of “how”. Why something works the way it does, why people came to particular ideas and why would one use the technology in a way they do. There are a lot of options of “how” for everything in tech, but you need to know “why” to take the most out of it.

Google Developer Groups

Michelle Mannering

Guest’s Location: Melbourne, Victoria

Tell us more about your role.

The GitHub DevRel team gets to do some of the most amazing things in the Developer Relations space. We showcase the products and services that GitHub has, but more importantly we highlight the awesome things our community is doing. Whether someone is a maintainer, an open source contributor, student, or developer working within a company, everyone has a unique and interesting experience. By showcasing these cool developers and projects we can show how people are building better things for the world.

Is there a project you’ve worked on recently that you’re excited to share?

We’re always doing such fun and awesome things at GitHub. One of the things I’ve been working on a lot is the Release Radar. It’s a monthly blog post that goes out showcasing awesome open source projects. We also have a video that goes out featuring some of the projects, talking about what they do, and how others can use them. It’s a really awesome way to get the word out about what developers are building. You can find out more on releaseradar.github.com

What makes you passionate about being in the tech space?

I really love talking to others and hearing about their journey and experience. The best thing about the tech space is listening to someone get really excited about the thing they are building and then showing it to as many people as possible. I’m always so blown away by what people can create. I’ve been in this boat a few times and when you’re learning or building something and you get it right, and it deploys and doesn’t break, it’s not just you that gets excited, but everyone around you!

What is the biggest piece of advice you would offer professionals starting in the tech space?

Don’t think that this is a space where you have to be a genius and know everything. Everyone, all developers, from the most junior to the most senior, still use Stack Overflow to find answers. Never think you are not enough, and on the flip side, never think that you know it all. You can always learn more. So my best advice is “no matter what your role or your experience, always be learning!”

Cassidy Williams

Guest’s Location: Chicago, Illinois

Tell us more about your role.

In short: I build open source and educational content to help people get jobs!

Is there a project you’ve worked on recently that you’re excited to share?

I’ve been working on my newsletter full of web news, practice interview questions, and jokes! It’s at cassidoo.co/newsletter and I’m about to hit my 5-year-anniversary writing it!

What makes you passionate about being in the tech space?

Tech is such a creative, logical, exciting field that can change peoples’ lives. I love helping people get jobs in tech to afford and build the lives and ideas they want to.

What is the biggest piece of advice you would offer professionals starting in the tech space?

Look for people who are where you want to be. Look at their paths, and see how you can try to mimic it. Make yourself available for people to mimic you. One of my favorite quotes is to “lift as you climb”! If you help others as you move forward in their careers as you move forward in yours, you’ll build a wonderful community of people around you, and make the tech community a better place!

How to get started in cloud computing

Posted by Google Cloud training & certifications team

Validated cloud skills are in demand. With Google Cloud certifications, employers know that certified individuals have proven knowledge of various professional roles within the cloud industry. Google Cloud certifications have also been recognized as some of the highest-paying IT certifications for the past several years. This year, the Google Cloud Certified Professional Data Engineer topped the list with an average salary of $171,749, while the Google Cloud Certified Professional Cloud Architect came in second place, with an average salary of $169,029.

You may be wondering what sort of background you need to take advantage of these opportunities: What sort of classes should you take? How exactly do you get started in the cloud without experience? Here are some tips to start learning about Google Cloud and build your cloud computing skills.

Get hands-on experience with cloud computing

Google Cloud training offers a wide range of learning paths featuring comprehensive courses and hands-on labs, so you get to practice with the real Google Cloud console. For instance, If you wanted to take classes to prepare for the Professional Data Engineer certification mentioned above, there is a complete learning path featuring four courses and 31 hands-on labs to help familiarize you with relevant topics like BigQuery, machine learning, IoT, TensorFlow, and more.

There are nine learning paths providing you with a launch pad to all major pillars of cloud computing, from networking, cloud security, database management, and hybrid cloud infrastructure. Each broader learning path contains specific learning paths to help you specifically train for job roles like Machine Learning Engineer. Visit the Google Cloud training page to find the right path for you.

Learn live from cloud experts

Google Cloud regularly hosts a half-day live training event called Cloud OnBoard which features hands-on learning led by experts. All sessions are also available to watch on-demand after the event.

If you’re a developer new to cloud computing, we recommend you start with Google Cloud Fundamentals, an entry-level course to learn about the basics of Google Cloud. Experts guide you through hands-on labs where you can practice using the Google Console, Google Cloud Shell, and more.

You’ll be introduced to core components of Google Cloud and given an overview of how its tools impact the entire cloud computing landscape. The curriculum covers Compute Engine and how to create VM instances from scratch and from existing templates, how to connect them together, and end with projects that can talk to each other safely and securely. You will also learn about the different storage and database options available on Google Cloud.

Other Cloud OnBoard event topics include cloud architecture, Kubernetes, data analytics, and cloud application development.

Explore Google Cloud infrastructure

Cloud infrastructure is the backbone of the internet. Understanding cloud infrastructure is a good starting point to start digging deeper into cloud concepts because it will give you a taste of the various aspects of cloud computing to figure out what you like best, whether it’s networking, security, or application development.

Build your foundational Google Cloud knowledge with our on-demand infrastructure training in the cloud infrastructure learning path. This learning path will provide you with practical experience through expert-guided labs which dive into Cloud Storage and other key application services like Google Cloud’s operations suite and Cloud Functions.

Show off your skills

Once you have a strong grasp on Google Cloud basics, you can start earning skill badges to demonstrate your experience.

Skill badges are digital credentials that recognize your ability to solve real-world problems with your cloud knowledge. You can share them on your resume or social profile so your professional network sees your technical skills. This can be useful for recruiters or employers as you transition to cloud computing work.Skill badges also enable you to get in-depth, hands-on experience with different Google Cloud offerings on the way to earning the credential.

You can also use them to start preparing for Google Cloud certifications which are more intensive and show employers that you are a cloud expert. Most Google Cloud certifications recommend having at least 6 months or up to several years of industry experience depending on the material.

Ready to get started in the cloud? Visit the Google Cloud training page to see all your options from in-person classes, online courses, special events, and more.

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!

Recommended strategies and best practices for designing and developing games and stories on Google Assistant


Posted by Wally Brill and Jessica Dene Earley-Cha

Illustration of pink car collecting coins

Since we launched Interactive Canvas, and especially in the last year we have been helping developers create great storytelling and gaming experiences for Google Assistant on smart displays. Along the way we’ve learned a lot about what does and doesn’t work. Building these kinds of interactive voice experiences is still a relatively new endeavor, and so we want to share what we’ve learned to help you build the next great gaming or storytelling experience for Assistant.

Here are three key things to keep in mind when you’re designing and developing interactive games and stories. These three were selected from a longer list of lessons learned (stay tuned to the end for the link for the 10+ lessons) because they are dependent on Action Builder/SDK functionality and can be slightly different for the traditional conversation design for voice only experiences.

1. Keep the Text-To-Speech (TTS) brief

Text-to-speech, or computer generated voice, has improved exponentially in the last few years, but it isn’t perfect. Through user testing, we’ve learned that users (especially kids) don’t like listening to long TTS messages. Of course, some content (like interactive stories) should not be reduced. However, for games, try to keep your script simple. Wherever possible, leverage the power of the visual medium and show, don’t tell. Consider providing a skip button on the screen so that users can read and move forward without waiting until the TTS is finished. In many cases the TTS and text on a screen won’t always need to mirror each other. For example the TTS may say “Great job! Let’s move to the next question. What’s the name of the big red dog?” and the text on screen may simply say “What is the name of the big red dog?

Implementation

You can provide different audio and screen-based prompts by using a simple response, which allows different verbiage in the speech and text sections of the response. With Actions Builder, you can do this using the node client library or in the JSON response. The following code samples show you how to implement the example discussed above:

candidates:
- first_simple:
variants:
- speech: Great job! Let's move to the next question. What’s the name of the big red dog?
text: What is the name of the big red dog?

Note: implementation in YAML for Actions Builder

app.handle('yourHandlerName', conv => {
conv.add(new Simple({
speech: 'Great job! Let's move to the next question. What’s the name of the big red dog?',
text: 'What is the name of the big red dog?'
}));
});

Note: implementation with node client library

2. Consider both first-time and returning users

Frequent users don’t need to hear the same instructions repeatedly. Optimize the experience for returning users. If it’s a user’s first time experience, try to explain the full context. If they revisit your action, acknowledge their return with a “Welcome back” message, and try to shorten (or taper) the instructions. If you noticed the user has returned more than 3 or 4 times, try to get to the point as quickly as possible.

An example of tapering:

  • Instructions to first time users: “Just say words you can make from the letters provided. Are you ready to begin?”
  • For a returning user: “Make up words from the jumbled letters. Ready?”
  • For a frequent user: “Are you ready to play?”

Implementation

You can check the lastSeenTime property in the User object of the HTTP request. The lastSeenTime property is a timestamp of the last interaction with this particular user. If this is the first time a user is interacting with your Action, this field will be omitted. Since it’s a timestamp, you can have different messages for a user who’s last interaction has been more than 3 months, 3 weeks or 3 days. Below is an example of having a default message that is tapered. If the lastSeenTime property is omitted, meaning that it’s the first time the user is interacting with this Action, the message is updated with the longer message containing more details.

app.handle('greetingInstructions', conv => {
let message = 'Make up words from the jumbled letters. Ready?';
if (!conv.user.lastSeenTime) {
message = 'Just say words you can make from the letters provided. Are you ready to begin?';
}
conv.add(message);
});

Note: implementation with node client library

3. Support strongly recommended intents

There are some commonly used intents which really enhance the user experience by providing some basic commands to interact with your voice app. If your action doesn’t support these, users might get frustrated. These intents help create a basic structure to your voice user interface, and help users navigate your Action.

  • Exit / Quit

    Closes the action

  • Repeat / Say that again

    Makes it easy for users to hear immediately preceding content at any point

  • Play Again

    Gives users an opportunity to re-engage with their favorite experiences

  • Help

    Provides more detailed instructions for users who may be lost. Depending on the type of Action, this may need to be context specific. Defaults returning users to where they left off in game play after a Help message plays.

  • Pause, Resume

    Provides a visual indication that the game has been paused, and provides both visual and voice options to resume.

  • Skip

    Moves to the next decision point.

  • Home / Menu

    Moves to the home or main menu of an action. Having a visual affordance for this is a great idea. Without visual cues, it’s hard for users to know that they can navigate through voice even when it’s supported.

  • Go back

    Moves to the previous page in an interactive story.

Implementation

Actions Builder & Actions SDK support System Intents that cover a few of these use case which contain Google support training phrase:

  • Exit / Quit -> actions.intent.CANCEL This intent is matched when the user wants to exit your Actions during a conversation, such as a user saying, “I want to quit.”
  • Repeat / Say that again -> actions.intent.REPEAT This intent is matched when a user asks the Action to repeat.

For the remaining intents, you can create User Intents and you have the option of making them Global (where they can be triggered at any Scene) or add them to a particular scene. Below are examples from a variety of projects to get you started:

So there you have it. Three suggestions to keep in mind for making amazing interactive games and story experiences that people will want to use over and over again. To check out the full list of our recommendations go to the Lessons Learned page.

Thanks for reading! To share your thoughts or questions, join us on Reddit at r/GoogleAssistantDev.

Follow @ActionsOnGoogle on Twitter for more of our team’s updates, and tweet using #AoGDevs to share what you’re working on. Can’t wait to see what you build!

Google Developer Student Club 2021 Lead applications are open!


Posted by Erica Hanson, Global Program Manager, Google Developer Student Clubs

Hey, student developers! If you’re passionate about programming and are ready to use your technology skills to help your community, then you should become a Google Developer Student Clubs Lead!

Application forms for the upcoming 2021-2022 academic year are NOW OPEN. Get started at goo.gle/gdsc-leads.

Want to know more? Learn more about the program below.

What are Google Developer Student Clubs?

Google Developer Student Clubs are university based community groups for students interested in Google developer technologies. With clubs hosted in 106 countries around the world, students from undergraduate and graduate programs with an interest in leading a community are welcome. Together, students learn the latest in Android App Development, Google Cloud Platform, Flutter, and so much more.

By joining a GDSC, students grow their knowledge in a peer-to-peer learning environment and put theory to practice by building solutions for local businesses and their community.

How will I improve my skills?

As a Google Developer Student Club Lead you will have the chance to…

  • Gain mentorship from Google.
  • Join a global community of leaders.
  • Practice by sharing your skills.
  • Help students grow.
  • Build solutions for real life problems.

How can I find a Google Developer Student Club near me?

Google Developer Student Clubs are now in 106 countries with 1250+ groups. Find a club near you or learn how to start your own, here.

When do I need to submit the Application form?

We encourage students to submit their forms as soon as possible. You can learn more about your region’s application deadline, here. Make sure to learn more about our program criteria.

Get Started

From working to solve the United Nations Sustainable Development Goals to helping local communities make informed voting decisions, Google Developer Student Club leads are learning valuable coding skills while making a true difference. As a lead from a Club in Kuala Lumpur, Malaysia put it,

“The secret to our club’s success was that we were able to cultivate a heart of service and a culture of open mentorship.”

We can’t wait to see what our next group of Google Developer Student Club leads will accomplish this year. Join the fun and get started, here.

*Google Developer Student Clubs are student-led independent organizations, and their presence does not indicate a relationship between Google and the students’ universities.

Passionate former DSC lead Irene inspires others to learn Google technologies with her new podcast and more


Posted by Erica Hanson, Global Program Manager, Google Developer Student Clubs

(Irene (left) and her DSC team from the Polytechnic University of Cartagena (photo prior to COVID-19)

Irene Ruiz Pozo is a former Google Developer Student Club (DSC) Lead at the Polytechnic University of Cartagena in Murcia, Spain. As one of the founding members, Irene has seen the club grow from just a few student developers at her university to hosting multiple learning events across Spain. Recently, we spoke with Irene to understand more about the unique ways in which her team helped local university students learn more about Google technologies.

Real world ML and AR learning opportunities

Irene mentioned two fascinating projects that she had the chance to work on through her DSC at the Polytechnic University of Cartagena. The first was a learning lab that helped students understand how to use 360º cameras and 3D scanners for machine learning.

(A DSC member giving a demo of a 360º camera to students at the National Museum of Underwater Archeology in Cartagena)

The second was a partnership with the National Museum of Underwater Archeology, where Irene and her team created an augmented reality game that let students explore a digital rendition of the museum’s exhibitions.

(An image from the augmented reality game created for the National Museum of Underwater Archeology)

In the above AR experience created by Irene’s team, users can create their own character and move throughout the museum and explore different virtual renditions of exhibits in a video game-like setting.

Hash Code competition and experiencing the Google work culture

One particularly memorable experience for Irene and her DSC was participating in Google’s annual programming competition, Hash Code. As Irene explained, the event allowed developers to share their skills and connect in small teams of two to four programmers. They would then come together to tackle engineering problems like how to best design the layout of a Google data center, create the perfect video streaming experience on YouTube, or establish the best practices for compiling code at Google scale.

(Students working on the Hash Code competition (photo taken prior to COVID-19)

To Irene, the experience felt like a live look at being a software engineer at Google. The event taught her and her DSC team that while programming skills are important, communication and collaboration skills are what really help solve problems. For Irene, the experience truly bridged the gap between theory and practice.

Expanding knowledge with a podcast for student developers

(Irene’s team working with other student developers (photo taken before COVID-19)

After the event, Irene felt that if a true mentorship network was established among other DSCs in Europe, students would feel more comfortable partnering with one another to talk about common problems they faced. Inspired, she began to build out her mentorship program which included a podcast where student developers could collaborate on projects together.

The podcast, which just released its second episode, also highlights upcoming opportunities for students. In the most recent episode, Irene and friends dive into how to apply for Google Summer of Code Scholarships and talk about other upcoming open source project opportunities. Organizing these types of learning experiences for the community was one of the most fulfilling parts of working as a DSC Lead, according to Irene. She explained that the podcast has been an exciting space that allows her and other students to get more experience presenting ideas to an audience. Through this podcast, Irene has already seen many new DSC members eager to join the conversation and collaborate on new ideas.

As Irene now looks out on her future, she is excited for all the learning and career development that awaits her from the entire Google Developer community. Having graduated from university, Irene is now a Google Developer Groups (GDG) Lead – a program similar to DSC, but created for the professional developer community. In this role, she is excited to learn new skills and make professional connections that will help her start her career.

Are you also a student with a passion for code? Then join a local Google Developer Student Club near you, here.