What is the state of serverless computing and Python in 2024?
What are some of the new tools and best practices?
Well, we're lucky to have Tony Sherman,
who has a lot of practical experience
with serverless programming on the show.
This is Talk Python to Me,
episode 458, recorded January 25th, 2024.
Welcome to Talk Python to Me, a weekly podcast on Python.
This is your host, Michael Kennedy.
Follow me on Mastodon, where I'm @mkennedy,
and follow the podcast using @talkpython,
both on fosstodon.org.
Keep up with the show and listen to over seven years
of past episodes at talkpython.fm.
We've started streaming most of our episodes live on YouTube.
Subscribe to our YouTube channel over at talkpython.fm
slash YouTube to get notified about upcoming shows
and be part of that episode.
This episode is brought to you by Sentry.
Don't let those errors go unnoticed.
Use Sentry like we do here at Talk Python.
Sign up at talkpython.fm/sentry.
And it's brought to you by Mailtrap,
an email delivery platform that developers love.
Try for free at mailtrap.io.
Tony, welcome to Talk Python to Me.
Thank you.
Thanks for having me.
Fantastic to have you here.
It's going to be really fun to talk about serverless.
You know, the joke with the cloud is,
well, I know you call it the cloud,
but it's really just somebody else's computer.
But we're not even talking about computer.
We're just talking about functions.
Maybe it's someone else's function.
I don't know.
We're going to find out.
Yeah, I actually, I saw a recent article about server-free recently with somebody trying to,
yeah, move completely.
Yeah.
Because as you might know, serverless doesn't mean actually no servers.
Of course.
Server-free.
All right.
So we could just get the thing to run on the BitTorrent network.
Got it.
Okay.
Yeah.
I don't know.
We'll figure it out.
But it's going to be super fun.
And we're going to talk about your experience working with serverless.
We'll talk about some of the choices people have out there
and also some of the tools that we can use to do things like observe and test our serverless code.
Yeah.
For that, though, tell us a bit about yourself.
Sure.
So I'm actually a career changer.
So I worked in the cable industry for about 10 years and doing a lot of different things
from installing, you know, knock out the door cable guy to working on more of the outside plant.
But at some point, I was seeing limits of career path there.
And so my brother-in-law is a software engineer.
And I had already started kind of going back to school, finishing my degree.
And I was like, okay, well, maybe I should kind of look into this.
And so I took an intro to programming class.
It was in Python.
And that just kind of, yeah, led me down this path.
So now for the past, I don't know, four years or so, been working professionally in the software world,
started out in a QA role at an IoT company.
And now, yeah, doing a lot of serverless programming in Python these days.
Second company now, but that does some school bus safety products.
Interesting.
Very cool.
Yeah.
Yep.
But a lot of Python and a lot of serverless.
Well, serverless and IoT, I feel like they go pretty hand in hand.
Yes.
Yep.
Yeah.
Another thing is with serverless is when you have very like spiky traffic.
Like if you think about school buses that, you know, you have a lot coming on twice a day.
To bimodal.
Exactly.
Like the 8 a.m. shift and then the 2.30 to 3 shift.
So, yeah, that's a really good use case for serverless is something like that.
Okay.
Are you enjoying doing the programming stuff instead of the cable stuff?
Absolutely.
I sometimes I live in Michigan, so I look outside and look at, you know, the snow coming down or these storms.
And yeah, I just, yeah, I really, some people like you don't miss being outside.
I'm like, maybe every once in a while, but I can, I can go walk outside on a nice day.
You can choose to go outside.
You're not ready to go outside in the sleet or rain.
Yeah.
Yeah, absolutely.
We just had a mega storm here and just the huge tall trees here in Oregon just fell left and right.
And there's in every direction that I look, there's a large tree on top of one of the houses of my neighbors.
Oh, man.
Maybe a house or two over.
But it just took out all the, everything that was a cable in the air was taken out.
So it's just been a swarm of people who are out in 13 degree Fahrenheit, you know, negative nine Celsius weather.
And I'm thinking, you know, not really choosing to be out there today, probably.
Right.
Excellent.
Well, thanks for that introduction.
I guess maybe we could, a lot of people probably know what serverless is, but I'm sure there's a lot who are not even really aware of what serverless programming is.
Right.
Let's talk about what's the idea.
What's the, what's the Zen of this?
Yeah.
So, yeah, I kind of, you know, made the joke that serverless doesn't mean there are no servers, but, and there's, hopefully I don't butcher it too much, but it's more like, functions as a service.
There's other things that can be serverless too.
Like there's, you know, serverless databases or, a lot of different, services that can be serverless.
Meaning you don't have to think about like how to operate them, how to think about, you know, scaling them up.
You don't have to, you know, spin up, VMs or, or Kubernetes clusters or anything.
You, you don't have to think about that part.
It's just your, your code that goes into it.
And so, yeah, serverless functions are probably what people are most familiar with.
And that's, I'm sure what we'll talk about most today, but, and, yeah, that's really the idea.
You don't have to, you don't have to manage the server.
Oh, sure.
And that's a huge barrier.
I remember when I first started getting into web apps and programming and then another level, when I got into Python, because I had not done that much Linux work, getting stuff up running.
It was really tricky.
And then having the concern of, is it secure?
How do I patch it?
How do I back it up?
How do I keep it going?
All of those things, they're non-trivial, right?
Right.
Yeah.
There's, there's a lot to think about.
And, and if you like work at an organization, it's probably different everywhere you go to that.
They, you know, how they manage their servers and things.
So, so putting in some stuff in the cloud kind of brings some, some commonality to it too.
Like you can, you can learn how, you know, the Azure cloud or Google cloud or AWS, how those things work and, and kind of have some common ground too.
So, yeah, for sure.
Like having, I mean, also feels more accessible to the developers in a larger group.
You know, in the sense that it's not a DevOps team that kind of takes care of the servers or a production engineers where you hand them your code.
It's, it's a little closer to just, I have a function and then I get it up there and it continues to be the function, you know?
Yeah.
You, and that is a different mindset too.
You kind of see it all the way through from writing your code to deploying it.
Uh, yeah.
With, without maybe an entire DevOps team that you just kind of say, here you go, go deploy this.
Yeah.
So in my world, I mostly have virtual machines.
I've moved over to kind of a Docker cluster.
I think I've got 17 different things running in the Docker cluster at the moment, but both of those are really different than serverless.
Right.
Yeah.
So it's been working well for me, but when I think about serverless, let me know if this is true.
It feels like you don't need to have as much of a, a Linux or server or, or sort of an ops experience to create these things.
Yeah.
I would say like you could probably get away with like almost none, right?
Like at the simplest form, like with, like AWS, for instance, their Lambda functions, you can, and that's the one I'm most familiar with.
So, forgive me for using them as an example for everything.
There's a lot of, different, serverless, options, but, you could go into the AWS console and you could actually, write your, you know, Python code right in the console, deploy that they have function URLs now.
So you could actually have like, I mean, within a matter of minutes, you can have a serverless function set up.
And so, AWS Lambda, right.
That's the one.
Yep.
Lambda being, I guess, a simple function, right?
We have Lambdas in Python.
They can only be one line.
So I'm sure you can have more than one line in the AWS Lambda, but.
Yeah.
There are limitations though, with, with Lambda that you, that are, definitely some pain points that I ran into.
So.
Oh, really?
Okay.
What are some of the limitations?
Yeah.
So, package size is one.
So if you start thinking about all these like amazing, packages on PyPI, you do have to start thinking about how, how many you're going to bring in.
So, and I don't know the exact limits off the top of my head, but it's pretty quick Google search on their, their package size.
It might be like 50 megabytes zipped, but two 50.
Um, when you decompress it, to do a zip base, then they do have, containerized Lambda functions that go up to like a 10 gig limit.
So that helps, but, okay.
Yeah.
They, those ones, used to be less performant, but they're, they're kind of catching up to where they're, that was really on something called cold starts.
Uh, but they're, they're getting, I think pretty close to it.
Not, not being a very big difference, whether you Dockerize or zip these functions, but, but yeah.
So when you start just like pip installing everything, you've got to think about how to get that code into your function.
Uh, and, how much it's going to bring in.
So yeah, that definitely was, a limitation that, had to quickly learn.
Yeah.
I guess it's probably trying to do pip install dash R effectively.
Yeah.
And it's like, you know, you, you can't go overboard with this.
Right.
Yeah.
When you start bringing in packages, like, you know, maybe like some of the like, scientific packages, you're, you're definitely going to be hitting some, some size limits.
Okay.
And with the containerized ones, basically you get probably give it a Docker file and a command to run in it and it can, it can build those images before and then just execute and just do a Docker run.
Yeah.
I think how those ones work is you, you store an image, on like their container registry, Amazon's, is it ECR, I think.
And so then you kind of pointed at that and yeah, it'll, execute your like handler function.
Uh, when that, when the Lambda gets called.
This portion of talk Python and me is brought to you by multi-platform error monitoring at Sentry.
Code breaks.
It's a fact of life.
With Sentry, you can fix it faster.
Does your team or company work on multiple platforms that collaborate?
Chances are extremely high that they do.
It might be a reactor view front end JavaScript app that talks to your FastAPI backend services.
Could be a go microservice talking to your Python microservice or even native mobile apps talking to your Python backend APIs.
Now let me ask you a question.
Whatever combination of these that applies to you, how tightly do these teams work together?
Especially if there are errors originating at one layer, but becoming visible at the other.
It can be super hard to track these errors across platforms and devices.
But Sentry has you covered.
They support many JavaScript front end frameworks.
Obviously Python backend, such as FastAPI and Django.
And they even support native mobile apps.
For example, at Talk Python, we have Sentry integrated into our mobile apps for our courses.
Those apps are built and compiled in native code with Flutter.
With Sentry, it's literally a few lines of code to start tracking those errors.
Don't fly blind.
Fix code faster with Sentry.
Create your Sentry account at talkpython.fm/sentry.
And if you sign up with the code TALKPYTHON, one word, all caps,
it's good for two free months of Sentry's business plan,
which will give you up to 20 times as many monthly events,
as well as some other cool features.
My thanks to Sentry for supporting Talk Python to me.
Yeah, so out in the audience, Kim says,
AWS does make a few packages available directly just by default in Lambda.
That's kind of nice.
Yeah, yep.
So, yeah, Bodo, which if you're dealing with AWS and Python,
you're using the Bodo package.
And yeah, that's included for you.
So that's definitely helpful in any of their, you know,
transitive dependencies would be there.
I think Bodo used to even include, like, requests,
but then I think they eventually dropped that with some, like, SSL stuff.
But yeah, you definitely, you can't just, like, pip install anything
and not think of it unless, depending on how you package these up.
So.
Sure.
That makes sense.
Yeah.
Of course they would include their own Python libraries, right?
Yeah.
And it's not a, yeah, it's not exactly small.
I think, like, Bodo core used to be, like, 60 megabytes,
but I think they've done some work to really get that down.
So.
Yeah.
Yeah, that's, yeah, that's not too bad.
I feel like Bodo core, Bodo 3, those are constantly changing.
Like, constantly.
Yeah.
Yeah, well, as fast as AWS adds services, they'll probably keep changing quickly.
Yeah.
I feel like those are auto-generated, maybe, just from looking at the way the API
looks at it, you know, the way they look written.
And so.
Yeah.
Yeah, that's probably the case.
Yeah.
I know they do that with, like, their infrastructure is code CDK.
It's all, like, TypeScript originally, and then you have your Python bindings for it.
And so.
Right, right, right, right.
I mean, it makes sense, but at the same time, when you see a change, it doesn't necessarily
mean, oh, there's a, there's a new important aspect added.
It's probably just, yeah, I don't know.
People have actually pulled up the console for AWS, but just the amount of services that
are there.
And then each one of those has its own full API, like a little bit of the one of those
things.
So we regenerated it, but it might be for some part that you'd never, never call, right?
Like you might only work with S3 and it's only changed.
Yeah.
I don't know, EC2 stuff, right?
Right.
Yep, exactly.
Yeah, indeed.
All right.
Well, let's talk real quickly about some of the places where we could do serverless, right?
Yeah.
You mentioned AWS Lambda.
Yeah.
And I also maybe touch on just 1 million requests free per month.
That's pretty cool.
Yeah.
So yeah, getting like jumping into AWS sometimes sounds scary, but they have a pretty generous
free tier.
Definitely do your research on some of the security of this, but yeah, you can, you know, a million
requests free per month.
You probably have to look into that a little bit because it's, you know, you have your memory
configurations too.
So there's probably, I don't know exactly how that works within their free tier, but
you're charged like with Lambda, at least it's your like invocation time and memory and
also amount of requests.
So yeah.
I'm always confused when I look at that and go, okay, with all of those variables, is that
a lot or a little?
I know it's a lot, but it's hard for me to conceptualize.
Like, well, I use a little more memory than I thought.
So it costs like, wait a minute.
How do I know how much memory I use?
You know, like, yeah.
What does this mean in practice?
Yeah.
It's built by how you configure it too.
So if you say I need a Lambda with 10 gigs of memory, you're, you're being built at that
like 10 gigabyte price threshold.
So there is a really, a really cool tool called power to our AWS Lambda power tuner.
So yeah, what that'll do is you can, it creates a state machine in AWS.
Yeah.
I think I did send you a link to that one.
So the, the power tuner will create a state machine that, invocates your Lambda
with several different memory configurations.
And you can say, I want either the best cost optimized version or the best performance optimized
version.
So, and that'll tell you, like, it'll say, okay, yeah, you're best with a Lambda configured
at, you know, 256 megabytes, you know, for memory.
So, sorry.
Yeah.
For the, the link it's, this is power tools.
This is a different, amazing package.
Yeah.
Maybe I didn't send you the, power tuner.
I should, okay.
Sorry.
That's news to me.
Okay.
Sorry.
Yeah.
And they have similar names.
Yeah.
There's only so many ways to describe stuff.
Right.
Yeah.
Okay.
They have it right in their head.
Yep.
And it is an open source package.
So there's probably a GitHub link in there, but yeah.
Yeah.
And, this will tell you like the best way to optimize your, your Lambda function, at
least as far as memory is concerned.
So, yeah, really good tool.
It gives you a visualization and gives you a graph that will say like, okay, here's,
here's kind of where cost and performance meet.
And so, yeah, it's, it's really excellent for figuring that out.
Um, yeah, at least in, in AWS land, I don't know if some of the other cloud providers have
something similar to this, but, yeah, it's definitely a really helpful tool.
Sure.
Yeah.
Like I said, I've, I'm confused and I've been doing cloud stuff for a long time when I look
at it.
Yeah.
So, well, there's some interesting things here.
So like, you can actually have, a Lambda invocation that costs less with a higher
memory configuration because it'll run faster.
So you're, I think Lambda bills like by the millisecond now.
So, you can actually, because it runs faster, it can be cheaper to run.
So, well, that explains all the rust that's been getting written.
Yeah.
There's a real number behind this.
I mean, we need to go faster, right?
Okay.
So, you know, the, the, I think maybe AWS Lambda is one of the very first ones as well to come
on with this concept of serverless.
Yeah.
It, it, I don't know for sure, but it probably is.
And then, yeah, your other big cloud providers have them.
And now you're actually even seeing them, come up with, a lot of like Vercel has
some kind of, some type of serverless function.
Uh, I don't know what they're using behind it, but it's almost like they just put a,
a nicer UI around AWS Lambda or whichever cloud provider that's, you know, that's potentially
backing this up.
But, yeah, they're just reselling their flavor of, of somebody else's cloud.
Yeah.
It could be because yeah, Vercel, obviously they have a really, nice suite of products
with a, with a good UI, very usable.
So, no.
Okay.
So Vercel, some of them people can try.
And then we've got the two other hyperscale clouds, I guess you call them.
Google cloud has serverless, right?
Yep.
Okay.
So I'm not sure which ones that they might just be called cloud functions.
Uh, and yeah, Azure also has, they got cloud run and cloud functions.
I have no idea what the difference is though.
Yep.
And, yeah, Azure also has a serverless product and I'd imagine there's probably like
even more that we're, we're not aware of, but, yeah, it's kind of, nice to not think
about, setting up servers for something.
So then I think maybe, is it fast?
Yeah.
Function as a service.
Let's see.
Yeah.
But if we search for F-A-A-S instead of pass or, IaaS, right?
There's, we've got Almeda, Intel.
I saw that IBM had some, oh, there's also, the, we've got digital ocean.
I'm a big fan of digital ocean because I feel like their pricing is really fair and they've
got good documentation and stuff.
So they've got functionless, sorry, serverless functions, that you can,
I don't use these.
Yeah.
I haven't used these either, but yeah.
Um, and, yeah, as far as costs, like for, especially for like small, like personal
projects and things where you don't need to have a server on all the time, they're yeah,
pretty, pretty nice.
If you have a website that you need something server side where you got to have some Python,
but you don't need a server going all the time.
Yeah.
Okay.
Like maybe I have a static site, but then I want this one thing to happen.
If somebody clicks a button, something like that.
Yeah.
Yeah, absolutely.
Yep.
You could be completely static, but have something that is, yeah.
Yeah.
That one function call that you do need.
Yeah.
Exactly.
And then you also pointed out that cloud flare has some form of serverless.
Yeah.
And I, I haven't used these either, but, yeah, I do know that they have, some type
of, you know, functions as a service.
I don't know what frameworks for languages.
They let you write them in there.
Yeah.
I use, bunny.net for my CDN.
It's just absolutely awesome platform.
I really, really love it.
And one of the things that they've started offering, I can get this stupid, completely useless cookie
banner to go away is they've offered a, what they call, edge compute.
Oh, yeah.
Okay.
What you would do.
I don't know where to find it somewhere, maybe, but basically the CDN has 115, 120 points of
presence all over the world where, you know, this one's close to Brazil.
This one's close to Australia, whatever.
And, but you can actually run serverless functions on those things.
Like, so you deploy them.
So the code actually executes in 150, 115 locations.
Yes.
Yeah.
Probably cloudflare or something like that as well, but I don't know.
Yeah.
AWS has, they have like Lambda at edge, at the edge.
So that's kind of, goes hand in hand with their, like CDN, cloud, cloud front,
I believe.
Yeah.
So they have something similar like that, where you have a, a Lambda that's going to
be, you know, perform it because it's yeah.
Distributed across their CDN.
Yeah.
CDN that's a whole nother world.
They're, they're getting really advanced.
Yeah.
So, we won't, maybe that's a different show.
It's not a show today, but it's just the idea of like you distribute the compute
on the CDN is pretty nice.
The drawback is just JavaScript, which is okay, but it's, it's not the same as right.
Yes.
Yeah.
I wonder if you could do high script.
Oh yeah.
That's an interesting thought.
Yeah.
We're getting closer and closer to Python in the browser.
So yeah.
Yeah.
My JavaScript includes this little bit of WebAssembly and I don't, I don't like semicolons,
but go ahead and run it anyway.
Yeah.
Out in the audience.
It looks like, Cloudflare probably does support Python, which is.
Okay.
Yeah.
There's, there's so many options out there for, for serverless functions that are, yeah,
really, especially if you're already in, you know, if you're maybe deploying, you know,
some static stuff over Cloudflare, Cloudflare or Vercel.
Yeah.
It's sometimes nice just to be all, all in on one, one service.
Yeah.
It really is.
Let's talk about using, choosing serverless over other things, right?
You actually laid out two really good examples or maybe three, even with the static site
example, but you know, I've got bursts of activity.
Yeah.
Right.
And really, really low, incredibly, incredibly low usage other times.
Right.
Yeah.
You think of like, yeah, you're, you're black Friday traffic, right?
Like you to not have to think of like how many servers to be provisioned for something
like that.
Or if you don't know, I think there's probably some like, well, I actually know there's
been like some pretty popular articles about people like leaving the cloud.
Uh, and, and yeah, like if you know your scale and you know, you know exactly what you
need, yeah, you, you probably can save money by just having your, your own infrastructure
set up or, but yeah, if you don't know, or it's very like spiky, you don't need
to have a server that's consuming a lot of power running, you know, 24 hours a day.
You can, just invoke a function as you need.
So this portion of talk Python may is brought to you by Mailtrap and email delivery platform
that developers love an email sending solution with industry, best analytics, SMTP and email
APIs, SDKs for major programming languages and 24 seven human support.
Try for free at Mailtrap.io.
Yeah.
There's a super interesting series by David Heinemeyer Hansen of Ruby on rails fame and
from, base camp about how base camp has left the cloud and how they're saving $7 million
and getting better performance over five years.
Yeah.
But that's, that's a big investment, right?
They bought $600,000 for hardware, right?
Yeah.
Only so many people can do that.
Right.
And you, you know, you gotta have that running somewhere that, you know, with, with,
with backup power and, yeah.
Yeah.
So what they ended up doing for this one is they went with some service called theft,
okay.
Hosting, which is like white glove, white.
So white, labeled is the word I'm looking for where it just looks like it's your hardware,
but they put it into a mega data center and there's, you know, they'll have the hardware
shipped to them and somebody will just come out and install it into racks and go, here's
your IP.
Right.
Like a, yeah.
Uh, virtual, virtual VM or a VM in a cloud that, but it takes three days, three
weeks to boot.
Right.
Yeah.
Which is kind of the opposite is almost, I mean, I'm kind of diving into it because it's,
it's almost the exact opposite of the serverless benefits, right?
This is insane stability.
I have this thing for five years, 4,000 CPUs we've installed and we're using them for the
next five years rather than how many milliseconds am I going to run this code for?
Right.
Exactly.
Yeah.
It's definitely the far opposite.
And so, yeah, you kind of, you know, maybe serverless isn't for every use case, but it's
definitely a nice like tool to have in the toolbox.
And yeah, you definitely even working in serverless, like if you're, yeah, eventually you're going
to need like maybe to interact with the database that's got to be on all the time.
You know, it's yeah, there's a lot of, it's a good tool, but it's definitely not the,
uh, one size fits all solution.
So yeah, let's talk databases in a second, but for, you know, when does it make sense
to say we're going to put this, like if this suppose I have an API, right?
That's a pretty, an API is a real similar equivalent to what a serverless thing is.
Like I'm going to call this API, I think it's going to happen.
I'm going to call this function.
The thing's going to happen.
Let's suppose I have an API and it has eight endpoints.
It's written in FastAPI or whatever it is.
It might make sense to have that as serverless, right?
You don't want to run a server and all that kind of thing.
But what if I have an API with 200 endpoints?
Like, where is the point where like, there are so many little serverless things.
I don't even know where to look.
They're everywhere.
Which version is this one?
You know what I mean?
Like where, where's that trade-off and how do, you know, you and the people you work with
think about that?
Yeah, I guess that's a, a good, good question.
I mean, as you start like, you know, getting into these like microservices, how small
do you want to break these up?
And so there, there, there is some different thoughts on that.
Even like a, a Lambda function, for instance, if you, if you put this behind an API,
uh, you can use a single Lambda function to, for your entire rest API, even if it is,
you know, 200 endpoints.
So, okay.
So you put the whole app there and then when a request comes in, it routes to whatever
part of your app.
Theoretically.
Yeah.
So there's, a package called power tools for, AWS power tools.
I don't know.
Power tools for Python.
Yeah.
I don't care.
Yeah.
I know the similar name.
Yeah.
So they have a, a really good like event resolver.
So you can actually, it's, it almost looks like, you know, flask or, some of the
other Python web frameworks.
And so you, you kind of have this resolver, whether it's, you know, API gateway and, and
AWS are different.
Um, they have a few different options for, the API itself, but yeah, you, in, in theory,
you could have your entire API behind a single Lambda function, but then that's probably not
optimal.
Right.
So you're, that's where you have to, figure out how to break that up.
And so, yeah, they do like that same, the decorators, you know, app dot post or
yeah.
Yeah.
And your endpoints and you can do the, with the, have them, have variables in there
where maybe you have like ID, as your lookup and it can, you know, slash user slash
ID is going to find your, find, you know, a single user.
So, and, and their documentation, they actually addressed this a little bit.
Like, do you want to do, they, they call it either like a, a micro function pattern where
maybe every single endpoint has its own Lambda function.
Uh, but yeah, that's a lot of overhead to maintain.
If you had, like you said, 200 endpoints, you have 200 Lambdas.
Um, you gotta upgrade them all at the same time.
So they have the right.
Yeah.
That's right.
So, yeah.
So, there, there's definitely some, even, even conflicting views on this.
How, how micro do you want to go?
And so, I was able to go to AWS reinvent and, November and, and they actually kind
of pitched this, this hybrid, maybe like if you take your like CRUD operations, right.
And, and maybe you have, your create update and delete all on one Lambda that's con with
its configuration for those, but your read is on another Lambda.
So maybe your CRUD operations, they all interact with a relational database, but your reader just,
uh, does like, reads from a dynamo database, where you kind of sync that, that data up.
And so you could have your permissions kind of separated for each of those, Lambda functions.
And, you know, people reading from an API don't always need the same permissions as,
you know, updating, deleting.
And so, so yeah, there's a lot of different ways to, to break that up and how, how micro
do you go with this?
Um, definitely.
How micro can you go?
Yeah.
Cause it sounds to me like if you had many, many of them, then all of a sudden you're back
to like, wait, I did this because I didn't want to be in DevOps and now I'm a different
kind of DevOps.
Yeah.
So, yeah, that.
Python, that package, the power tools is, is does a lot of like heavy lifting for you.
Um, at PyCon, there was a talk on serverless that, they, the way they described the power
tools package was it, they had said it like codified your, your serverless best practices.
And, and it's really true.
They give a lot, there's like so many different tools in there and there's a, a logger,
like a structured logger, that works really well with Lambda and you, you don't even have
to use like the AWS, login services.
If you want to use like, you know, data dog or, or Splunk or something else, you, it's just
a structured logger and how you aggregate them.
It's like up to you and you can even customize how you format them, but it's, works really
well with Lambda.
Um, yeah.
So that's.
You probably could actually capture exceptions and stuff with something like century even.
Right.
Oh yeah.
Python code.
There's no reason you couldn't.
Right.
Exactly.
Yep.
Um, yeah, some of that comes into, you know, packaging up those, those libraries for
that.
Uh, you know, you, you do have to think of some of that stuff, but like, yeah, yeah.
Data dog, for instance, they, they provide something called like a Lambda layer or a Lambda extension,
which is another way to package code up.
That just makes it a little bit easier.
So, yeah, there's a lot of, a lot of different ways to, to attack some of these problems.
A lot of that stuff, even though they have nice libraries for them, it's really just calling
a HTTP endpoint and you could go, okay, we need something really light.
I don't know if requests is already included or, but there's some gotta be some kind of HTTP
thing already included.
We're just going to directly call it.
Not sure.
Yeah.
All these packages.
Yeah.
Yep.
Yeah.
This code looks nice.
This, this power tools code, it looks like well-written Python code.
It's they, they do some really amazing stuff and they, they bring in a Pydantic too.
So, yeah, like, being mostly in serverless, I I've never really gotten to use like FastAPI,
right.
And leverage Pydantic as much, but with, power tools, you really can.
So, so they'll package up, Pydantic for you.
And so you can actually, yeah, you can have Pydantic models for, you know, validation
function on these.
It's like a, a Lambda function, for instance, it always receives an event.
There's always like two arguments to the fun, to the handler function.
It's event and context.
And like event is always a, it's a, a dictionary in Python.
And so they, they can always look different.
And so, yeah.
Yeah.
So, cause the event.
Yeah.
Uh, so if you look in the, the power tools, github their, their tests, they have like,
uh, okay, here's what a, an event.
API gateway proxy event dot JSON or whatever.
Right.
Yes.
Yeah.
So they have, yeah.
Examples.
Yes.
Yeah.
So like, you don't want to parse that out by, by yourself.
Uh, you know, so they, they have, Pydantic models or they, they might actually just be
Python data classes, but, that you can, you can say like, okay, yeah, this function
is going to be for, yeah.
An API gateway proxy event, or it's going to be an S3 event or whatever it is.
You know, there's, there's so many different ways to receive events, from different AWS
services.
So, so yeah, power tools kind of gives you some, some nice validation.
And yeah, you might just say like, okay, yeah, the body of this event, even though I,
I don't care about all this other stuff, that they include the, the path headers,
queer string parameters, but I just need like the body of this.
So you just say, okay, event dot body, and you can even use, you can validate that further.
The event body is going to be a Pydantic model that you created.
So yeah, there's a lot of different pieces in here.
If I was working on this and it didn't already have Pydantic models, I would take this and go
to Jason Pydantic.
Oh, I didn't even know this existed.
That's where it's.
Okay.
Boom.
Put that right in there.
And boom, there you go.
It parses it onto a nested tree, object tree of, of the model.
Very nice.
But if they already give it to you, they already give it to you.
Yeah.
Just take what they give you.
Yeah.
Those specific events might be data classes instead of Pydantic.
Um, just because you don't, that way you don't have to package Pydantic up in your Lambda.
But, yeah, if you're already, figuring out a way to package power tools, you're, you're,
you're, you're close enough that you probably just include Pydantic too.
But yeah, yeah, it's, and they also, I think they just added this feature where
it'll actually generate, open API schema for you.
Uh, kind of, I think, yeah, fast, FastAPI does that as well.
Right.
So, yeah, so that's something you can leverage power tools to do now as well.
Oh, excellent.
And then you can actually take the open API schema and generate a Python client board on
top of that.
I think with, yeah, yeah.
So you just say it's robots all the way down.
Right.
Turtles all the way down.
Yeah.
Um, yeah.
I, I haven't used those open API generated clients, very much.
I, I was always like skeptical of them, but, yeah.
In theory.
I just feel heartless or, you know, soulless, I guess the word looks more.
And he's just like, okay, here's another star org, star, star KW orgs thing where it's like,
couldn't you just like write it, make some reasonable defaults and give me some keyword
argue, you know, just like, yeah, but if it's better than nothing, you know, it's better than
right.
Yeah.
So, but yeah, you, you can see like power tools.
They, they took a lot of influence from FastAPI and it does seem like it.
Yeah, for sure.
Yeah.
Oh, it's, it's definitely really powerful.
And you get some of those same benefits.
Yeah.
This is new to me.
It looks, it looks quite nice.
So, another comment by Kim is tended to use serverless functions for either things that
run briefly, like once a month on a schedule or the code that processes stuff coming in on
an AWS SQS simple queuing service queue of unknown schedule.
So maybe that's an interesting segue into how do you call your serverless code?
Yeah.
So, as we kind of touched on, there's a lot of different ways from like, you know,
AWS for instance, to do it.
So, yeah, like AWS Lambda has like Lambda function URLs, but I haven't used those as much,
but if you just look at like the different options and, and like power tools, for instance,
you can, you can have a, a load balancer that's gonna, where you set the endpoint to invoke
a Lambda, you can have, API gateway, which is another service they have.
Um, so there's a lot of different ways.
Yeah.
So, that's kind of almost getting into like a way of like streaming or an asynchronous
way of processing data.
So, yeah, maybe, in AWS, you're using a queue, right?
That's, filling up and you say like, okay, yeah, every time this queue is at this size or,
or this timeframe, invoke this Lambda and process all these messages.
So there's a lot of different ways to, to, to invoke a Lambda function.
So, if it's, I mean, really as simple as, you can invoke them like from the AWS CLI
or, but yeah, most people are probably have some kind of API around it.
Yeah.
Almost make them look like just HTTP endpoints.
Right.
Yeah.
Mark out there says not heard talk of ECS.
I don't think, but I've been running web services using Fargate serverless tasks on ECS for years
now.
Are you familiar with this?
I haven't done it.
Uh, I, yeah, I, I'm like vaguely familiar with it, but yeah, this is like a, a serverless,
yeah.
Serverless compute for containers.
So, I haven't used this personally, but yeah, very like similar concept where it
kind of scales up for you and, yeah, you don't have to have things running all
the time, but yeah, it can be dockerized applications.
Um, yeah, in fact, the company I work for now, they do this with their Ruby on rails applications.
They, they dockerize them and run, with, with Fargate.
Uh, so, Docker creating Docker containers of these things, the less familiar you are with
running that tech stack, the better it is in Docker.
You know what I mean?
Yeah.
Like I, I could run straight Python, but if it's Ruby on rails or PHP, maybe it's going
into a container that would make me feel a little bit better about it.
Yeah.
Especially if you're in that workflow of like handing something over to a DevOps team, right?
Like you, you can say like, here, here's an image or a container or Docker file that,
you know, that will work for you.
You know, that's maybe a little bit easier than, trying to explain how to set up an environment
or something.
So, yeah.
Yeah.
Fargate's a really good serverless option too.
Excellent.
What about performance?
You know, you talked about having like a whole API apps, like FastAPI or flask or whatever.
Yeah.
Start up those apps can be somewhat, can be non-trivial basically.
And so then on the other side, we've got databases and stuff.
And one of the bits of magic of databases is the connection pooling that happens, right?
So the first connection might take 500 milliseconds, but the next one takes one.
It's already open effectively, right?
Yeah.
That's definitely something you really have to take into consideration is like how, how
much you can do.
That's where some, some of that like observability, some of like the, the tracing that you can do
and profiling is, is really powerful.
Yeah.
AWS Lambda, for instance, they have, they have something called cold starts.
So like, yeah.
So the first time like a Lambda gets invoked or maybe you have, you know, 10 Lambdas that
get called at the same time, that's going to, you know, invoke 10 separate Lambda functions.
So that's like great for the scale, right?
That's really nice, but on a cold start, it's usually a little bit slower invocation because
it has to initialize.
Like I think what's happening, you know, behind the scenes is they're like, they're moving your
code over.
That's going to get executed.
And anything that happens like outside of your handler function.
So importing libraries sometimes you're establishing a database connection.
Maybe you're, you know, loading some environment variables or, or some secrets.
And so, yeah, there's definitely, performance is something to consider.
Um, I, yeah, that's probably, you, you mentioned rust.
Uh, yeah, there's probably some more performant, like run times for some of these serverless functions.
So, I've even heard some people say, okay, for, for like client facing things, we're, we're
not going to use serverless.
Like we just want that performance.
So, so that cold start definitely can, that can have an impact on you.
Yeah.
On both ends that I've pointed out, like the app start, but also the, the service, the database
stuff with like the connection.
Right.
Yeah.
So yeah.
Relational databases too.
That's an interesting thing.
Uh, with, yeah.
What do you guys do?
You mentioned Dynamo already.
Yeah.
So Dynamo really performant for, a lot of connections.
Right.
But a, so Dynamo is a, you know, serverless database that can, that can scale.
You can query it over and over and that's not going to, it doesn't reuse a connection
in the same way that like a SQL database would.
Um, so that's, that's an excellent option, but if you do have to connect to a relational
database and you have a lot of invocations, you can, you can use a, like a proxy,
if, if you're all in on AWS.
And so again, sorry for this is really AWS heavy, but, but if you're using their like
relational database service, RDS, you can use RDS proxy, which will use like a pool of connections
for your Lambda function.
Oh, that can, yeah.
That can give you a lot of, performance or, at least you won't be, you know, running
out of connections to your database.
So, another thing too, is just how you structure that connection.
So, I mentioned cold Lambdas, you obviously have warm Lambdas too.
So, a Lambda has its, its handler function.
And so anything outside of the handler function can get reused on a, on a, on a warm Lambda.
So you can establish the connection to a database and it'll get reused on every invocation that
it, that it can.
That's cool.
Do you have to do anything explicit to make it do that?
Or is that just, it just has to be outside of that handler function.
So, you know, kind of at your, your top level of your, your file.
So.
Yeah.
Excellent.
Yeah.
It makes me think almost one thing you would consider is like profiling the import statement
almost.
Right.
And yeah, that's what we normally do, but there's a library called import profiler that actually
lets you time how long different, different things take to import.
It could take a while, especially if you come from, not from a native Python way of thinking
in like C# or C++ or something you say hash include or using such and such
like that's a compiler type thing that really has no cost.
Yeah.
There's code execution.
And when you import something in Python and some of these can take a while, right?
Yes.
Yeah.
So, there's a lot of tools for that.
There's some, I think even maybe specific for Lambda.
I don't like data dog has a profiler that gives you like this, I forget what the graphic
is called, like a flame, a flame graph.
Yeah.
That'll give you like a flame graph and show like, okay, yeah, it took this long to,
make your database connection this long to import Pydantic.
And it took this long to, make a, a call to DynamoDB, you know, so you actually
kind of like break that up.
Uh, AWS has x-ray, I think, which does something similar to, so, yeah, it's definitely something
to consider.
Um, another, just what you're packaging, is definitely, something to, to watch
for.
And so, I mentioned, yeah, I mentioned using pants to package Lambdas and they, they
do, hopefully I don't butcher how this works behind the scenes, but, they're using,
they're using Rust and they'll actually kind of like infer your dependencies for you.
And so they have a, an integration with AWS Lambda.
They also have it for Google cloud function.
So yeah, it'll go through.
You say, here's like my, AWS Lambda function.
This is the, the file for it and the function that needs to be called.
And it's going to create a zip file for you, that has your, your Lambda code in it.
And it's going to find all those dependencies you need.
So it'll actually, you know, by default, it's going to include like, you know, Bodo that you
need.
If, if you're using Bodo, it'll, if you're going to use, you know, pie, my SQL or whatever
library, it's going to pull all those in and zip that up for you.
And so if you just like open up that zip and you see, and especially if you're,
sharing code across your code base, maybe you have a shared function to, to make some of these
database connections or calls.
Like, you, you see everything that's going to go in there.
And so, yeah.
And so how, how like pants does it is it's, it's file-based.
So, sometimes just for like ease of imports, you might throw a lot of stuff in like your,
um, your init.py file and say like, okay, yeah.
From, you know, you add all kind of bubble up all your things that you want to import in
there.
Um, well, if one of those imports, is also using, open CV and you don't need
that, then pants is going to say like, oh, he's importing this.
And because it's file-based now this Lambda needs open CV, which is a, you know, massive
package.
That's going to, it's going to impact your, your performance, especially in those cold
starts because that, that code has to be moved over.
So yeah, that's, that's pretty interesting.
So kind of an alternative to saying, here's my requirements or my pyproject.toml, my lock
file or whatever, that just lists everything the entire program might use.
This could say, you're going to import this function.
And to do that, it imports these things, which import those things.
And then, and then it just says, okay, that means here's what you need.
Right.
Yeah.
It's definitely one of like the best ways that I found to, to package up,
Lambda functions.
I think some of the other tooling might do some of this too, but yeah, a lot of times
it, it would require like requirements that TXT, but if you have like a large code
base to where maybe you do have this, this shared, you know, module for, that, you
know, maybe you have, you know, 30 different Lambda functions that are all going to use
some kind of helper function.
It's just going to go in, like grab that.
And it doesn't have to be like pip installable pants is smart enough to just be like, okay,
it needs this code.
And so, but yeah.
You definitely have to be careful.
Yeah.
And then there's so many other cool things that, that pants is doing that, you know,
they have some, really nice stuff for testing and, linting and formatting.
And it's, yeah, there's a lot of really good stuff that they're doing.
Yeah.
I had Benji on the show to talk about pants.
That was, that was fun.
Yeah.
So let me go back to this picture.
Is this the picture?
I have a lot of things open on my screen now there.
So on my server setup that I described, which is a bunch of Docker containers running on one
big machine.
I can go in there and I can say, tail this log and see all the traffic to all the different
containers.
I can tell another log and just see like the logging log book, log guru, whatever output
of that, or just the web traffic.
Like there's different ways to just go, I'm just going to sit back and look at it for
a minute to make sure it's chilling.
Right.
If everything's so transient, not so easy in the same way.
So what do you do?
Yeah.
So, yeah, power tools does, they have their, their structured logger that helps a lot, but
yeah, you have to kind of like aggregate these logs somewhere.
Right.
Because yeah, you can't, you know, a Lambda function, you can't like SSH into.
Right.
So, yeah, you can't have to make too long.
Yeah.
Um, so yeah, you, you need to have some way to aggregate these.
So like AWS has cloud watch where, that will like by default kind of log all of your
standard out.
So even like a print statement would go to, cloud watch, just by, by default.
Um, but you probably want to like structure these better with, most likely in, in, you
know, JSON format, just most tooling around those is going to help you.
So, yeah, the power tool structured logger is, is really good.
And you can, you can, even like you can have like a single log statement, but you can
append different keys to it.
And, it's, it's pretty powerful.
Um, especially cause you, you don't want to like, I think like, so if you just like
printed something in a Lambda function, for instance, that's going to be like a different
row on each of your, like, by like the default cloud watch, like it'll be, I, how
it breaks it up is really odd unless you have some kind of structure to them.
Okay.
And so, yeah, so definitely something to, to consider.
Um, something else you can do is, yeah, there's, there's metrics you can do.
Uh, so like how it works with like cloud watch, they have a specific format.
And if you use that format, you can, it'll automatically pull that in as a metric
and like data dog has something, similar where you can actually kind of like go in there.
You can look at your logs and say, like, find a value and be like, I want this to be a metric
now.
And so that's really powerful.
Oh, the metric sounds cool.
So I see logging and racing.
What's the difference between those things?
Like tracing as a level and just a high level of logging.
Yeah.
Tracing, and hopefully I do do the justice, differentiating too.
Um, I, I feel like tracing does have a lot more to do with your, your performance
or, maybe even closer to like tracking some of these metrics.
Right.
Um, I've used the, the data dog tracer a lot.
Uh, and I've used the AWS, like X-ray, they're tracing utility a little bit too.
And so like those might, those will show you.
So like, maybe you are reaching out to a database, writing to S3.
APM, application performance monitoring, where it says, yes, you spent this much time in a
SQL query in this much time in.
Identic serialization.
Whereas the login would say a user has been sent a message.
Right.
Exactly.
Yeah.
Yep.
Tracing definitely is probably more around your, your performance and yeah.
Things like that.
I see.
It's kind of insane that they can do that.
You know, you, you, you see it in the Django debug tool bar and the pyramid debug tool bar,
but they'll be like, here's your code and here's all your SQL queries.
And here's how long they took.
And you're just like, wow, that thing is reaching deep down in there.
You know, the, the data dog one is very interesting because like it, it just knows like that this
is a SQL connection and it tells you like, oh, okay.
This SQL connection took this long.
And it was like, I didn't tell it to even trace that.
Like it just like, it, it knows really well.
Yeah.
So like the connections open is another to say, and here's what it sent over SSL, by the way.
How'd you get in there?
Yeah.
So it's in process.
So it can do a lot.
It is impressive to see those things that work.
All right.
So that's probably what the tracing is about, right?
Yes.
Yeah.
Definitely.
Probably more around performance.
You can put some different things in tracing too.
Like I've, I've used it to say, like we talked about those like database connections to say
like, oh yeah, I, this is a, this is reusing a connection here.
Cause I was, I was trying to like debug some stuff on, am I creating a connection too many
times?
So I don't want to be, so yeah, you can, you can put some other useful things in tracing
as well.
But yeah.
And pat out the audience.
Oops.
Move around.
When you're using many microservices, like single execution involves many services.
Basically it's hard to follow the logs between the services and tracing helps.
Tie that together.
Yeah.
That's for sure.
All right.
Let's close this out, Tony, with one more thing that I'm not sure how constructive it
can be.
There probably is some ways, but testing, right?
Yeah.
That's definitely.
If you could set up your own Lambda cluster, you might just run that for yourself.
Right.
So yeah.
How do you do this?
Right.
Yeah.
To some extent you can write like, like there's, there's a Lambda Docker image that you could run
locally and you can do that.
But if, if your Lambda is reaching out to DynamoDB, I guess there's, there's technically
a DynamoDB container as well.
Like, like you could, it's a lot of overhead to set this up, but rather than just doing like,
you know, flask start or, you know, whatever the, the command is to like spin
up a flask.
I pressed the go button in my IDE and now it's.
Yeah.
So that's definitely, and there's more and more tooling coming out, you know,
that's, that's coming out for this kind of stuff.
But, if you can like unit tests, there's no reason you can't just like, you know,
run, run unit tests, locally.
But when you start getting into the integration test, you're probably getting to the point where
maybe you just deploy to actual services.
Um, and you know, it's, it's always trade-offs, right?
Like there's, there's costs associated with it.
There's the overhead of like, okay, how can I deploy to an isolated environment, but maybe
it interacts with another microservice.
So, yeah, so there's, there's definitely trade-offs, but.
I can see that you might come up with, like a QA environment, almost like a mirror image
that doesn't share any data, but it's sufficiently close, but then you're running, I mean, that's
a pretty big commitment because you're running a whole replica of whatever you have.
Right.
Yeah.
And so, yeah, QA environments are great.
Um, but you might even want lower than QA.
You might want to have a, dev or like a, one place I worked at, we would
spin up an entire environment for every PR.
So, you could actually, yeah, like when you created a PR, that environment got spun
up and it ran your integration tests and system tests against that environment, which, you
know, simulated, your prod environment a little bit better than running locally on your
machine.
So, certainly a challenge, to, to test this.
And yeah.
And there's always these like one-off things too.
Right.
Like, you can't really simulate like that memory limitation of a Lambda locally,
you know, as much as when you deploy it and things like that.
So.
Yeah.
That would be much, much harder.
I, maybe you could run a Docker container and put a memory limit on it.
You know, that might work.
Yeah.
Maybe you're back into like more and more DevOps to avoid DevOps.
Right.
Yeah.
So there it goes.
But interesting.
All right.
Well, anything else you want to add to this conversation before we wrap it up about out of
time here?
Yeah.
I guess, I don't know if I have it.
Hopefully we covered enough.
Uh, there's just a lot of like good.
Yeah.
There's a lot of good resources.
The, the tooling that I've mentioned, like power tools and pants, just amazing communities
like power tools has a discord and go on there and ask for help.
And they're super helpful.
Uh, pants has a Slack channel.
You can join their Slack and ask, you know, about things.
And, and so those two communities have been really good and really helpful in this.
A lot of good, talks that are available on YouTube too.
So just, yeah, there's definitely resources out there and, that a lot of people have,
you know, fought this for a while.
So yeah, excellent.
And you don't have to start from just create function and start typing.
Yeah.
Cool.
All right.
Well, before you get out of here though, let's, let's get your recommendation for a PI PI package,
something, something fun.
Um, I probably, you know, we've talked a lot about it, but power tools is definitely one,
uh, that is like every day getting used for me.
So the, yeah, power tools for Lambda and Python,
they actually support other, other, languages too.
So they have like the same functionality for like, you know, no JS, you know, for like
typescript and.net.
And so, yeah, but this one definitely, leveraging power tools and, Pydantic together
just really made like, serverless, a lot of fun to, to write.
So, yeah, definitely doing great things there.
Excellent.
Well, I'll put all those things in the show notes and it's been great to talk to you.
Thanks for sharing your journey down the serverless path.
Yeah.
Yep.
Thanks.
Thanks for having me.
You bet.
Yeah.
Enjoy chatting.
Same.
Bye.
That's it.
This has been another episode of talk Python to me.
Thank you to our sponsors.
Be sure to check out what they're offering.
It really helps support the show.
Take some stress out of your life.
Get notified immediately about errors and performance issues in your web or mobile applications with
Sentry.
Just visit talkpython.fm/sentry and get started for free and be sure to use the promo
code talkpython, all one word.
Mailtrap, an email delivery platform that developers love.
Try for free at mailtrap.io.
Want to level up your Python?
We have one of the largest catalogs of Python video courses over at Talk Python.
Our content ranges from true beginners to deeply advanced topics like memory and async.
And best of all, there's not a subscription in sight.
Check it out for yourself at training.talkpython.fm.
Be sure to subscribe to the show.
Open your favorite podcast app and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, the Google Play feed at /play,
and the direct RSS feed at /rss on talkpython.fm.
We're live streaming most of our recordings these days.
If you want to be part of the show and have your comments featured on the air,
be sure to subscribe to our YouTube channel at talkpython.fm/youtube.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
We'll see you next time.
Bye.
I'll see you next time.