WESLEY CHUN: Hi, developers, and welcome to "Serverless
Migration Station," where we show you one serverless compute
modernization technique.
I'm Wesley from Google, joined by Martin
and our friend Porter here to discuss
how and when you would move an App Engine
app to Cloud Functions.
MARTIN OMANDER: That sounds great.
But what I want to know is why we'd
want to migrate an App Engine app to Cloud Functions.
WESLEY CHUN: Very fair of you to ask,
because you want to know whether it's worth doing.
One key reason is that you didn't have much code
to begin with, but App Engine was all we had available.
Other reasons include less configuration, more robust
local development experience, and the ability
to do event-based background processing.
MARTIN OMANDER: Wow.
I didn't even know you could do this with Cloud Functions.
But isn't the App Engine really different from Cloud Functions?
WESLEY CHUN: Yeah, it seems that way, doesn't it?
App Engine is great for full-stack web apps
or mobile backends, while Cloud Function
sounds like it's for event-driven microservices
or one-off utility functions, right?
MARTIN OMANDER: Yeah, that's exactly right, Wes.
So I suppose answering when you'd move from App Engine
to Cloud Functions is the first order of business
before discussing how to do it.
WESLEY CHUN: Absolutely.
Any time you're considering switching products,
you don't do it lightly.
I already mentioned some of the benefits
you get with Cloud Functions.
But, for something more specific,
I'd say we take a quick step back.
There was a time not too long ago
when App Engine was the only serverless platform
available so you'd use it for everything, including
small, single-functionality apps, if you call them that.
Short apps with not much code are perfect for this migration.
Cloud Functions has much less overhead,
meaning you can drop app.yaml and other configuration
files, keeping just your app files along
with third-party package dependencies.
Oh, and one other thing.
Cloud Functions does not support Python 2,
so this is a great chance to upgrade to Python 3.
MARTIN OMANDER: Ah, that makes sense.
A small app like that is really just a single microservice,
perfect for Cloud Functions.
Cool.
So what was the other situation for considering
moving from App Engine to Cloud Functions?
WESLEY CHUN: Well, you said the magic word, Martin--
microservice.
In this other scenario, you have a huge, monolithic app made up
of mostly independent routes which
could be almost a collection of API endpoints.
MARTIN OMANDER: Oh, so you mean I can split out my user
authentication code and admin-only utilities
to be separate functions, away from the main app?
WESLEY CHUN: That's right, especially
if you have different developers doing
the auth code, the database code, the admin code, and so
on.
Your dev team won't be stepping on each other's shoes.
Breaking up that app into multiple independent
microservices, like what you suggested,
is a prime candidate to move to Cloud Functions.
Better yet, if you make them plug and play,
you can reuse those pieces for other apps, saving time
and improve maintainability.
It's a valuable refactor in many respects.
MARTIN OMANDER: Sounds good.
But what if my monolithic application is huge
and I have a ton of microservices?
Would that still be a good use case for Cloud Functions?
WESLEY CHUN: It's a good question, Martin.
The general rule of thumb for using Cloud Functions
is when you have a few or a handful of microservices.
If you've got many more than that,
or there are even dependencies between them,
you may want to consider keeping it running as-is
on App Engine for now or consider moving to Cloud Run,
especially if your team has added containerization
as part of your software development workflow.
MARTIN OMANDER: Makes sense.
And, if that's the case, we've already made some videos
showing users how to migrate from App Engine to Cloud Run,
both with and without Docker, right?
WESLEY CHUN: That's right.
And both of those videos also come with Codelabs
so you get that hands-on experience.
The rest of this video will be for those considering
Cloud Functions instead.
MARTIN OMANDER: Sounds good.
Can you tell us more about the app we're
migrating to Cloud Functions?
WESLEY CHUN: Yeah, the Cloud NDB sample app from module 2
is a great example for us to use because it
doesn't rely on any App Engine-bundled services.
We moved it from App Engine NDB to Cloud NDB back in module 2.
And since Cloud Functions only supports Python 3,
we're going to start with the Module2b folder
and migrate that app to Cloud Functions.
MARTIN OMANDER: I see.
Can you point me to the repo, as well as the Codelab,
to remind me what we did back in module 2?
WESLEY CHUN: Sure thing.
Here are the links to both the starting repo,
as well as the Codelab, to remind you
of how we got there from module 1.
If you did module 2 and ported it to Python 3,
start with your version.
But if you don't have it, clone the repo or download the ZIP
file and grab it from the Module2b folder.
MARTIN OMANDER: Got it.
Now I understand that I should use Cloud Functions when
I have smaller bits of code, like a utility
function or a microservice, rather than a full app.
Is there anything else to know when getting ready to migrate?
WESLEY CHUN: Yeah.
Well, think about this.
If you don't have a full app, you
won't need a full web framework, either, right?
Yes, you still have to get, service, and respond
to requests, but that's it.
You can just write code and not have
to think about stacks or frameworks with that.
So let's go to the computer and move this to Cloud Functions
now.
You know the pattern by now, right?
Deploy that app one more time to App Engine to ensure it works.
This way, there's no guessing if you run into issues
after migrating.
From your Module2b, run gcloud app deploy
and confirm that your app adds a new visit and displays the 10
most recent visits, just like it's always done.
OK.
Just like when we migrated from App Engine to Cloud Run,
it's a whole new platform.
So I'll make an entire copy of your module2b folder.
Now let's start cleaning house.
Delete app.yaml, an App Engine artifact.
The only config file needed is the package requirements file,
requirements.txt.
Neither that nor the HTML index file in templates
require editing.
All of the work is in the main application file.
And when I say work, it sounds like a lot.
But it's really just removing or tweaking things.
As mentioned earlier, we don't need a web framework,
so strip out almost everything from Flask.
The app still renders a template of visits,
so we do need to keep that.
Cloud Functions will give us a Flask request object when
the Cloud Functions is called, so we don't need
to ask the framework for it.
We removed importing Flask, so there's
no need to instantiate it.
No, there's no longer an app object.
If your app is dependent on it, you
may be better off staying with App Engine
or containerizing it for Cloud Run.
No app means we should remove the route, as well.
While route is an adequate name for the route
function of an app, this app is really just a single function--
visit me.
Since it's now a function, let's give it an appropriate function
name, visitme().
Cloud Functions will call it directly with that name.
Plus, it's more descriptive.
And boom, that's it.
Your App Engine app is now a Cloud Function.
Instead of gcloud app deploy, it's gcloud functions deploy.
But because Cloud Functions doesn't
have a config file like app.yaml,
you need to specify other aspects,
like which runtime, the trigger type,
whether to allow unauthenticated traffic, and possibly
what region.
Now as you wrap up, let's chat about some things that Cloud
Functions can do that App Engine can't.
One key feature is that, while you
can develop Cloud Functions on the command line
like App Engine, you can also do everything in the browser--
create functions, code them, deploy them, and test them--
all from the Cloud Console.
Pretty cool, right, Martin?
MARTIN OMANDER: Wow.
That is really cool.
Sometimes I'm on the road and really
only have browser access.
It's good to know that I'll be able to make fixes
from my hotel room if needed.
I think there's another thing Cloud Functions can do
that App Engine can't, right?
WESLEY CHUN: Yeah, and perhaps this
is a product differentiator.
We know App Engine apps are HTTP-triggered.
Well, Cloud Function supports that.
But now we can execute our function
in the background as part of an event-driven process.
Cloud Functions can be triggered if someone uploads
a file to Cloud Storage, a new message
comes into Cloud Pub/Sub, someone
logs into Firebase, and so on.
MARTIN OMANDER: Right.
It's cool that event-driven means
you can execute different Cloud Functions as part
of one single workflow.
Now you mentioned we can develop, deploy,
and test in the browser.
But I'm really an old-school developer.
What if I want to do everything here, on my local laptop?
WESLEY CHUN: Yeah.
The Cloud Functions team has covered here, too.
For local development and testing,
check out the Functions Framework,
a set of open-source libraries letting
you create lightweight functions that
run in many different environments,
including Cloud Functions, locally on your laptop,
like you wanted, Cloud Run, or other Knative-based
environments.
Check it out with the links down below.
MARTIN OMANDER: All right.
Cloud Functions is quite the versatile product.
I'll definitely consider it for its target use cases.
And now are there any other migrations that App Engine
developers should consider?
WESLEY CHUN: Yeah.
Most of the videos in this "Migration Series"
involves migrating off of the original App Engine-bundled
services, like switching away from App Engine
NDB to either Cloud NDB or Cloud Datastore,
and those are covered in modules 2 and 3.
Those with App Engine push queues
can migrate those to Cloud Tasks.
This is covered in modules 7, 8, and 9.
Modules 12 and 13 cover moving off of App Engine
memcache to Cloud Memory Store and Redis.
And we already discussed containerizing App Engine
apps for Cloud Run with or without Docker,
and those are featured in modules 4 and 5.
MARTIN OMANDER: Wow.
So many modules, Wes.
I'm not supposed to do each module, one after another,
right?
WESLEY CHUN: That's right.
And more of them are coming.
Developers should look at whichever
modules make the most sense for their apps and use cases.
We're here whenever you need us.
Thanks for riding with us on Porter
for all of these different migration journeys.
This is Wesley from Google Cloud on behalf of Martin and Porter,
and we hope to see you at the next "Migration Station"
or on another "Serverless Expedition" soon.
[MUSIC PLAYING]