[MUSIC PLAYING]
WESLEY CHUN: Greetings, developers,
and welcome to Serverless Migration
Station, a miniseries that's part of Serverless Expeditions.
I'm Wesley, your conductor on these short trips.
Joining me is Martin, who will help
me help you navigate the world of modernizing
your applications, and Porter, our little friend here
who will help you get from point A to point B.
MARTIN OMANDER: Thanks, Wes.
I'm happy to be here.
What are these migrations, and why should developers
be interested?
WESLEY CHUN: I'm glad you asked, Martin.
Well, our job is to help developers modernize
their apps, to take advantage of new features and product
upgrades, to move to a more modern release
of their development language, and generally
keep their apps running well to support theirs
or their customers' needs.
In each episode, our friend Porter
here takes us on a short excursion to the next Migration
Station.
Each ride attempts to take the mystery out
of common migrations that developers undergo
when modernizing their apps.
MARTIN OMANDER: Ah, I get it.
We're helping developers take advantage of the latest
innovations from Google Cloud.
So which migrations are we focusing on first, Wes?
WESLEY CHUN: I'm glad you asked, Martin.
The first set of migrations we're going to tackle
is for original Python App Engine users.
Since its launch in 2008 as our first Cloud product,
we've continued to innovate and open the platform,
as well as introduce some new products.
MARTIN OMANDER: I'm familiar with Cloud Functions and Cloud
Run.
Are you saying users can run their App Engine
code on those platforms, too?
WESLEY CHUN: Yes, Martin.
App Engine users have options.
You can do nothing at all and stay on App Engine,
you can modernize to the next-generation App Engine
service, you can break up larger apps
into micro-services for Cloud Functions,
or you can containerize your app for Cloud Run.
Using Docker is another way to stay on Python 2
forever, for all of you hard-core folks.
If you don't want to learn about Docker or containers,
you can still containerize using Buildpacks,
but only Python 3 is supported.
This series will cover most of these,
but starts with helping you move to unbundle services.
MARTIN OMANDER: Hmm.
I like that Google Cloud is embracing openness and helping
make my apps more portable.
But what's wrong with having the legacy App Engine services,
anyway?
WESLEY CHUN: Well, nothing at all, Martin.
But while bundled services are convenient,
App Engine isn't as open as it can be.
For example, while webapp2 is a great lightweight framework,
moving to something more general,
like Flask, allows your app to be more portable,
meaning you can run your apps outside of App Engine
if desired.
By the way, if you don't use Flask,
you can use any WSGI-compliant framework
that does its own routing.
You can read more in the documentation.
Also, many of App Engine's original services
have matured to becoming their own standalone Cloud
products, anyway, and it's really where
all the new features are going.
So migrating lets users take advantage of their continuing
innovation.
MARTIN OMANDER: OK.
I understand the tech implications.
But before the main content, what can you say about cost?
WESLEY CHUN: Yes, it's true, Martin.
Migration does involve regular usage, so analyze varying costs
you may incur, like datastore access, pricing
of the new standalone Cloud products, free-tier quotas,
and so on.
In other words, don't go into it blindly and get surprised
afterwards.
For this reason, the tiny sample app used for the migrations
should not incur any charges.
But don't let its datastore usage go out of control.
MARTIN OMANDER: Watching videos is great,
but I want to get my hands dirty.
Where should I go, Wes?
WESLEY CHUN: All right, Martin.
Well, except for this video, each migration module
has an associated code lab, a self-paced, free online
tutorial to give you that hands-on.
Users get both the starting and ending code,
so you can reset back to the beginning
or compare your answers with ours.
While some migrations are strongly recommended,
others are optional.
It really depends on what makes sense for your app.
If you need to start migrating today,
several code labs have already been published.
So there really is no reason to wait.
MARTIN OMANDER: Hey, Wes.
You mentioned you'll give us a sample app to migrate.
Can you walk me through that starting sample
so I can get an idea of what to expect?
WESLEY CHUN: Sure.
I'm happy to, Martin.
It's a simple Python 2 guestbook app
using the webapp2 framework.
It records each page visit as a datastore entity with the App
Engine ndb client library.
We're going to dive into the code,
but let's pause so you can clone the repo
or download the zip file.
OK.
Jump to the module 0 code, and let's go to the computer
to walk through it now.
Let's start with the application file main.py.
The key imports bring in the webapp work framework,
plus its templating system, and the App Engine ndb
library to access datastore.
Next is a data model.
For each web page visit, we'll autosave the timestamp as well
as some visitor information, and that's it-- fairly basic.
store_visit creates the entity with the visitor
info we want to save, such as IP address and browser
type or user agent, then writes it
with a timestamp to datastore.
Yes, I know, X-Forwarded-For should
be checked first, and so on.
But this is just a sample app, so
grabbing the first thing that looks like an IP address
rather than being thorough and correct.
fetch_visits queries for the most recent visits,
which will be displayed with the HTML template.
For the primary handler, the app only
supports HTTP GET, which is why it's
the only implemented method.
It registers the visit, queries for the 10 most recent visits
to display, including the one just recorded,
and then passes the data to the template to render.
Finally, we have a routing table at the bottom.
I think all "Hello World" app.yaml's look
like this-- am I right?
It's a python27 app where all routes go to app in main.py.
The last file is a basic index template,
with some header info, then a "for" loop that displays
the most recent visits.
OK.
That's a quick walk-through of the baseline sample
app you can find in the module 0 repo folder.
MARTIN OMANDER: Thanks for the tour of the sample app, Wes.
Now I know what we're starting with--
a basic Python 2 app using the bundled App Engine services.
By the way, is this series for all App Engine users?
WESLEY CHUN: Glad you asked, Martin.
Nope, it's not for everyone.
If you're a Python 3, Java 11, PHP 7, or Go 1.12 or newer App
Engine user, you're already on the next-generation service.
This first set of migration modules
is only for developers, consultants,
IT decision-makers, integration specialists,
or any technical professional interested in bridging
the gap between the first- and second-generation App Engine
runtimes.
MARTIN OMANDER: Thanks for helping users
with these modernization resources.
Do you have any roadmap on which videos we'll see first?
WESLEY CHUN: Well, thanks, Martin.
As mentioned earlier, a starting set of code labs
is already available, so we'll be producing videos for them
first.
But if you're curious, here's a list of all the code
labs you can try now.
There's no need to wait for a video
if you need to get started today.
MARTIN OMANDER: Thanks for the heads-up
of what content to expect.
Are there any other resources that we can share today?
WESLEY CHUN: Oh, definitely, Martin.
In addition to the migration modules,
here are some links to the documentation describing
our long-term support of these older runtimes.
And more importantly, that page links
to the migration guides for each of the legacy runtimes.
Next is the repo for the samples in the docs,
and finally, yet another repo with migration samples
contributed by the community.
We look forward to having you join us
for the first leg on our migration journey,
as well as on other serverless expeditions.
This is Wesley Chun on behalf of Martin and Porter,
saying ciao for now, but we'll see you at the next Serverless
Migration Station.
[MUSIC PLAYING]