Deploying and managing your application after you create it can be a big challenge.
Cloud platforms such as Azure have literally hundreds of services.
Which ones should you choose? How do you link them together?
In this episode, Anthony Shaw and Shane Boyer share a new CLI tool and template
they've created for jump-starting your use of modern Python apps and deploying them to Azure.
We're talking FastAPI, Beanie and MongoDB, Async and Await, Bicep DevOps,
Automated CI and CD pipelines and more.
Plus, we also get to catch up on other Python work happening that Anthony is involved with.
If you're interested in deploying or structuring modern Python applications,
you'll find some interesting takeaways from our conversation.
This is Talk Python to Me, episode 373, recorded May 12, 2022.
Me too.
Welcome to Talk Python to Me, a weekly podcast on Python.
This is your host, Michael Kennedy.
Follow me on Twitter where I'm @mkennedy and keep up with the show and listen to past episodes
at talkpython.fm and follow the show on Twitter via at Talk Python.
We've started streaming most of our episodes live on YouTube.
Subscribe to our YouTube channel over at talkpython.fm/youtube to get notified
about upcoming shows and be part of that episode.
This episode is brought to you by Sentry and their awesome error monitoring product,
as well as NordVPN.
What you do on the internet belongs to you, not ad companies.
Keep your connection private and safe with Nord.
Transcripts for this and all of our episodes are brought to you by Assembly AI.
Do you need a great automatic speech-to-text API?
Get human-level accuracy in just a few lines of code.
Visit talkpython.fm/assemblyai.
Anthony, Shane, welcome to Talk Python to Me.
Hey, how are you?
I'm doing well.
It's great to have you here.
Yeah, yeah.
I'm excited to talk about this re-envisioning how Python works on Azure as a developer story
that you all are working on.
And from the really quick preview I've seen, it looks really exciting.
You must be excited to share it.
Yeah, it's been an adventure to figure out what's the fastest way to get a developer
kind of up and running on Azure and in the cloud without having to learn a whole set of new things.
That's kind of the goal here.
Sure.
And Shane, you and I, when we first started talking, we were reminiscing back to Azure in
the early days when there were only a couple of services.
Right.
Yeah.
Back in Silverlight.
It ran on.
Silverlight.
It ran on.
Silverlight.
Right.
Silverlight.
Oh, my goodness.
Right.
Those were the days.
What was that?
2008-ish?
Maybe a little earlier even?
Yeah, that sounds about right.
Yeah, we had Silverlight.
I think we had three actual products, and this is long before I started at Microsoft,
and SQL Server was its own portal.
So it had its own little space.
And now we're like, I don't know, well over 100 different things that we can do in the portal.
Yeah.
I don't know how many folks who are listening have actually gone to the portal and pulled
it up and sort of just browsed it.
But between Azure and AWS, it's just like a paradox of choice.
There's just layers of, oh, my gosh, the screen is full of icons.
Oh, I opened up one, and that was a subsection of now we have like deploy features that fill
the screen, right?
It's quite the challenge to get up and going, right?
Yeah.
I think if you ask any web developer, hey, you've got code.
How do you run this on the cloud?
And it's like, it depends, truly takes full meaning, you know, when it comes to that.
And, you know, before it was, you know, maybe it was just a slider bar for scaling,
right?
Like, oh, I want maybe two or three.
And now it's like, oh, well, it's based on CPU and this and how the moon is moving.
And like, there's just so many different ways that, you know, we can scale a web app or any
part of our architecture now.
And so many areas in which the pressure might be exerted that it needs to scale rather than
just CPU.
Yeah, totally.
Before we get to it, though, just like quick introduction for you.
I guess, Anthony, people know you.
You've been on the show so many times.
It's fantastic to have you back.
Yeah, it's great to be here again.
Yeah, for sure.
It's always good to have you on the show.
And when you're not on the show, we're often talking about you, about some project that
you're doing, some pet that lives in your IDE or some comic sans font using, all sorts of
fun things.
Yeah.
Rumors of a golden jacket somewhere.
Yeah.
Well, I didn't realize how close you were to the golden jacket.
That's amazing.
We have to work on that.
So just give us a quick catch up and then Shane, you can introduce yourself.
What have you been up to?
Anthony?
Have we spoken?
Yeah.
Anthony, have we spoken since you moved to Microsoft?
I think we have.
I can't.
I'm not 100% sure, but let's assume we haven't.
Tell people about what you're up to these days.
Yeah.
So I'm kind of working on advocating for Python within Microsoft and then working on advocating
Python outside of Microsoft as well.
So I'm still doing a lot of open source work, but then within Microsoft, I guess, trying to
integrate Python more into our products and stuff like that.
And also get the Python community and things like that more into how we work and find out
more about how Python is being used across the company and how we can do better as well.
So I've been focused on performance and security.
They're kind of two things I'm always interested in, but also like modern Python applications and
how they kind of come into play as well.
So yeah, so many things I couldn't possibly list them all over the last, the first year I've
been at Microsoft for over a year now.
And I made less than it was like 50 things I think I'd done in the first year.
But yeah, it's been a whirlwind, but really fun.
It has.
And you just came back from PyCon.
I want to give us a quick report from being on the scene.
Did I see you on the big screen, big stage giving a talk there?
Yeah, it's my first time doing that.
That was fun.
Awesome.
Congratulations.
Yeah, it's terrifying.
Yeah, so I gave a short update on behalf of Microsoft.
I was also in the diversity and inclusion.
I'm on the diversity and inclusion work group at the PSF.
And we had like a panel discussion on the stage.
And then I also gave a talk, like a full talk at PyCon.
What was your talk on?
It was on performance anti-patterns.
Yeah.
And that's it from your Perf Lint project?
Yeah.
So I basically gave background to the performance Lint project that I've been working on and
what things I'm looking for in code and why they slow it down.
And then just trying to demonstrate what the difference is to people on 3.9 or 3.10.
So like a simple one line code change can make 60% difference in terms of how quickly the code runs.
And then you can get into the debate again with people that no list comprehensions are just loops.
They don't make it any faster.
You're like, okay, can we run the benchmarks again?
And let's have another.
Yes, that's great.
So that's good work.
Last thing, what's the status of Perf Lint?
Is it a thing people are using already?
Is it still under development?
Yeah, it's definitely very early beta.
It raises a lot of false positives at the moment.
But it's raised some really interesting things on production code bases that I've run it against.
So for example, our serverless platform is Azure Functions.
That's all.
The Python serverless is all written in Python.
And it uses gRPC for communication.
So I'm actually running the performance linter against that code base to look at ways that we can make it faster.
And there's a list of stuff that I'm working through with the engineering team.
So yeah, trying to put that to proof instead of just making it theoretical.
That's a really good test case, actually.
And performance, if you can improve performance of the fabric of the cloud,
then you've made it better for everyone, right?
Yeah.
So there's a couple of loops I was looking at,
which probably get executed hundreds of millions of times a day.
So I'm like, okay, what if I can improve that by like 10%?
Then that's going to make a big difference.
Yeah, absolutely.
Awesome.
Well, it seems like you're having a good time there.
I'm happy to see you've found a new home.
Yeah.
Yeah, indeed.
Shane, welcome to the show.
Tell people about yourself.
Thanks.
It's a hard act to follow.
I know.
I did perf at my last job.
So I appreciate any perf improvements.
So yeah, I've been at Microsoft now six years.
It'll be six years in the summer.
So in about a month or so.
And it feels like some days it's six days.
Some days it feels like 60 days.
Others it's 60 years.
So yeah, what do I do at Microsoft?
I run an end-to-end and developer experiences team for Azure inside of DevDiv.
We do work closely with Anthony and other folks on his team too around just finding out what is hard about running Python and the other languages on Azure, on our tools, VS Code, Visual Studio, and how to get your code on the cloud and all the things that come along with it.
Everything from docs to the actual components, the services, and what's that full story and kind of where are those pain points.
And then working with those service teams to find out what makes sense to you, what feels like a Python developer should feel.
One of the early things that Anthony brought forward was, these are great.
It's great that we have logs, but it's not how I want to see logs, right?
So I think that, you know, that makes sense.
And that's the, again, like you talked earlier, that's the fabric of, you know, a developer.
Like I want to, when something goes wrong, we want to fix, you know, fix what it should look like so I can find that problem fast.
And those are types of things that we dig into and report up and help solve on our team.
Yeah, there's this story of when Scott Guthrie was put in charge of Azure.
Scott Guthrie being the guy at Microsoft, who was really responsible for a lot of the developer experience and took a bunch of the people on the team and had them all sit down and say,
okay, get an app on Azure.
And it was apparently a real struggle.
A lot of the people didn't succeed.
And it was like, this is the problem.
We need to fix this.
And I think that made it a lot better in some ways.
But it sounds to me like you're kind of doing a microcosm of that with Python, with the two of you.
Yeah.
And we do it for many, you know, for every type of developer, every language stack in Python is important to us for, you know, the very reasons that like Anthony mentioned, like some of our core components are actually written in Python, right?
And we want the, we appreciate that part of what we're doing and how those applications are written.
And again, the perf.
And that's a very classic story that you bring up because it's often referenced and probably a core reason why my team exists now does because we still have, you know, we have to solve those problems.
Yeah, sure.
Well, it's like we said, it's fabric, right?
And if the fabric is scratchy or itchy, you don't want to wear it.
And that's a really big problem, right?
You want to make this as smooth and seamless for people to get it right without bouncing off the walls too badly.
Yeah, for sure.
For sure.
Now, we're going to talk about this project that you all are working on, which is super exciting about structuring Python applications and deploying them to Azure.
Before we do though, you know, there's some other interesting folks working with you at Microsoft these days.
A lot of core developers, like Microsoft's doing a lot of stuff with Python these days in terms of the number of core developers.
I mean, obviously, you know, taking over GitHub is like a big step into the whole open source steps that you're all taking.
But, you know, the sort of the direct contribution to Python is super interesting.
And the most significant one, I guess, that we could talk about is when was this?
A little while ago, we had this big announcement that back in 2018, Guido Van Rossum retires as BDFL.
And that was it.
The steering council was created.
Governance thing was up in the air, but then figured out and seems to be really nailed.
And then hung out at home for a while.
COVID hit.
You couldn't really travel, do too much.
He's like, you know what, I kind of want to go back and do some interesting stuff.
So now Python creator Guido Van Rossum joins Microsoft and, you know, talk to him about that some and whatnot.
But still, very interesting.
You guys are working with him.
Most recently, I spoke to him and Mark Shannon about the Shannon plan and making CPython five times faster.
So, you know, Anthony, you want to give us sort of an update on the stuff you see going on?
I mean, I know you might not be like directly involved.
Yeah, we were actually testing.
And doing some of the PyCon.
So at the Microsoft booth, so the team that they're talking about, so Guido, Mark Shannon, there's now seven people on that team.
All core developers are working full time.
Apart from Guido, Guido is part time.
But all the others working full time on the Shannon plan and a whole bunch of other concepts.
And what they're doing is basically making changes to see Python core to make it faster.
Targeting Python 3.11, which will be out in October this year.
3.12 and 3.13.
Some of the ideas are actually penciled for 3.13.
Right.
This is like a five-year plan that Mark had laid out of.
If we could make it 1.5x better each year, compounding is good and we'll get fast.
Yeah, exactly.
So some of the fruits of that are actually coming out in 3.11.
So we were actually doing some live benchmarks and stuff at PyCon on different workloads and things like that.
I'm seeing 25% performance gain on most workloads, which is awesome.
And in some cases up to 60%.
So it depends very much on what your workload is.
But yeah, that's 3.11.
But I think some of the bigger changes are coming in 3.12.
So basically, there's a core team of people working full time now on CPython itself.
And not a fork of CPython, they're working directly on CPython with the core development team.
Right.
As amazing as the stuff that was done over, say, like Cinder and Instagram, right?
Really interesting stuff, but it was kind of like, we forked it.
Here's a sort of interesting thing we built.
Take it or leave it.
Take some ideas.
Off it goes.
It's really different to say where like the next time you just apt upgrade or brew, upgrade your Python, it just gets better.
Chocolatey upgrade, however you do it, right?
Yeah, definitely.
So yeah, the 3.11 changes already, I think, could benefit everybody.
And getting people onto the newest version of Python is definitely going to help everyone in the long term anyway, because it's got a list of other cool features.
It's pretty remarkable that after 30 years, you can make one of these big step changes of that significant of a performance improvement.
Yeah, definitely.
Yeah, it's great to have a dedicated team working on this, but I mean, they're not the only people working on it.
There are engineers from all over and other core developers working on contributions and stuff like that.
But it's good that we can sponsor a full-time team to work just on this specific area.
So Guido is kind of coordinating that.
And a lot of the ideas come from Mark Shannon's plan that was on the podcast last year.
Do you know any of the story around like the no-gil type of stuff?
Yeah.
There was Eric Snow's sub-interpreters.
There was like Sam Gross' actual no-gil stuff.
Yeah, there was actually an open space at PyCon on that specific topic and performance in general.
And Sam Gross is there, as well as the Cinder team, the team that works on Pyodide, and a lot of other core developers.
And that was discussed in detail.
I know that from what I've heard, I think Sam Gross is still working on his no-gil branch and trying to break it down into smaller chunks that can be merged, like smaller pieces that can be merged individually.
Because there's quite a number of changes in order to get that whole thing done.
But it's still carrying on because it was targeted against what was now an older version of Python than as Python continues.
Like 3.8 or something like that.
Yeah.
So Cinder, I think, was 3.8 and they're trying to get it to 3.9.
But yeah, as Python continues to march forward, it gets harder and harder to upstream those things.
Yeah.
Still very exciting.
Yeah.
So the reason I ask is, you know, the work that Vito and Mark and team are doing is sort of orthogonal to that no-gil work, right?
Like this is, a lot of stuff he's working on is just make it run faster single core.
And then if you could unlock it for multi-core and each core, like it's a really nice multiplicative thing.
You could easily see Python 20, 40 times faster if you could say, well, you can scale it across 10 cores.
And it got four times faster.
Yeah.
So Eric's still working on his sub-interpreters.
Mark is conceptually looking through a JIT specification.
And they're working through specialized compilation as well at the moment, which is partially coming out in 3.11, but then more of that coming out in 3.12.
Amazing.
So yeah, it's going to just leaps and bounds, I think, in terms of performance difference.
That's so exciting.
Last thing to ask on this topic, and then we'll get to the main topic.
Pidgin.
Pidgin is somewhere involved in this performance thing, your JIT thing that we've had you on the show before to speak about.
And so is that involved in any way, or is it sort of a parallel story?
Yeah, I'm sharing some of that with the team.
So things that I learned in Pidgin that worked, what made a difference, and especially in the JIT, like where there were gains to be made.
My desire, really, is that the learnings from Pidgin can be part of the future of CPython, and then Pidgin isn't required.
So if CPython gets its own JIT, and if some of the other stuff that Pidgin could do was part of CPython, then I think that's a win-win, because you don't have to install something separately.
If you just get the performance gains out of the box, then that's a win for everyone.
Yeah, absolutely.
Cool.
Well, that's really encouraging to hear all those improvements coming.
Awesome.
Thanks.
Well, let's start off our conversation here by just talking about deploying to the cloud, right?
I mean, your goal really is to make deploying to Azure awesome.
Yeah.
But let's just take a step back and talk about deploying to the cloud.
You know, when people talk about deployment, well, let's just say they have a FastAPI, Flask Django, whatever app has a database, they've developed it.
And usually it's a huge gap to go from.
Well, I got it to work on my machine using SQLite and the tutorial.
Now I need it to run.
And it all said, well, you need to learn about SSL and servers and Nginx and all these things.
You're like, whoa, whoa, whoa.
I don't even know Linux.
This is like a big step to take.
This portion of Talk Python To Me is brought to you by Sentry.
How would you like to remove a little stress from your life?
Do you worry that users may be encountering errors, slowdowns, or crashes with your app right now?
Would you even know it until they sent you that support email?
How much better would it be to have the error or performance details immediately sent to you,
including the call stack and values of local variables and the active user recorded in the report?
With Sentry, this is not only possible, it's simple.
In fact, we use Sentry on all the Talk Python web properties.
We've actually fixed a bug triggered by a user and had the upgrade ready to roll out as we got the support email.
That was a great email to write back.
Hey, we already saw your error and have already rolled out the fix.
Imagine their surprise.
Surprise and delight your users.
Create your Sentry account at talkpython.fm/sentry.
And if you sign up with the code talkpython, all one word, 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 other features.
Create better software, delight your users, and support the podcast.
Visit talkpython.fm/sentry and use the coupon code talkpython.
How do you guys, Shane, how do you think about sort of the spectrum of options and how people are doing it?
It's interesting because when you're creating that, you know, on your own machine, that's the environment, right, that you have to worry about.
And even when we are deploying to on-prem machines, at least we could walk over and touch the, you know, for you rack that was there.
We knew kind of what it was running on.
Right.
And a lot of times you plugged into, somebody had a database for you.
Yeah.
You ask them to create the database.
Right.
They ask you, you plead for a database to be set up and they give you a connection string and then that's that, right?
You know, here's your connection string and you're on your way.
I think the thought of now is, you know, how do I set this?
How do I provision it?
How do I deploy my code to the stuff that I've now provisioned there?
How do I make all the connections between my front end and my middle tier and my, my backend stuff?
How do I secure that with all of my environment variables and connection strings and, you know, monitoring is there.
I mean, then how do I just, you know, as a developer for me, I go, that's a great, I want to do that one time.
And then really, I just want to change my code and check in my code.
Right.
I just kind of want it to run.
Yeah.
That's for me.
That's, I want to get to that point.
And I think if, even if I have a very few amount of components, I've had meetings at companies that lasted three or four weeks, just talking about how are we going to set all this stuff up?
You know?
And the promise of the cloud is, hey, we can do this super fast.
And sometimes that's not so much true.
You know, it's still very challenging.
Yeah.
Previously it was, I need a server in our data center to be provisioned and we got to order it from Dell or wherever and wait for it to go.
And now it's really easy to go to the cloud and get it, but there's a lot of decisions to make.
Is it, are we getting VMs?
And then it's my job to run shell scripts to set up Nginx and other things.
How do I scale?
What's the topography of that?
How do I set that up for possibly what if we need to scale the web end or whatever?
Maybe we use Docker, maybe we use a platform as a service, right?
Like that could be a long conversation because ultimately it's somebody's responsibility.
If it doesn't, if it doesn't work out right, they're going, you know, you're going to have to come in on the weekend and fix it.
Yeah.
Or be at least responsible to make sure it keeps running.
Right.
Yeah.
Who do I call when it breaks?
Yeah, exactly.
Okay.
So where are you seeing people who you're talking to a lot going?
I mean, we've got, I think on one far end, like at the very far end, like if you turn it to either negative one or 11,
depending on which side you consider this to be on, bare metal.
That's very rare these days, but VMs and then Docker, Kubernetes, platform as a service, maybe, maybe some more functions.
Yeah.
Functions live in there.
Yeah.
VMs.
Usually 100% alone, but.
I think VMs are still very popular with, with some companies who are just trying to get to the cloud.
Right.
It's very easy to kind of park your car in somebody else's garage.
Right.
I think that's okay.
It's there.
Well, it's, yeah, it solves the biggest problem is how do I get a reliable internet connection that's fast and a server and network infrastructure that I don't have to take care of.
Yeah.
I think those are still, it's still very, it's a very viable option for some folks.
The PaaS option is, again, most companies can still run a very sophisticated system on PaaS.
The one thing that I'm seeing right now is that companies are wanting to, in small, even small companies, or even they hear Kubernetes, they hear the promise of it.
It's scalability, it's responsive, it's self-repairing.
Zero downtime.
Yeah, no downtime.
Scale to zero.
Like all the, all the buzziness that comes with it.
And, you know, there's the memes that go around with, you know, the tiny box on a tractor trailer.
Like I put my blog on Kubernetes.
You don't need it, but everybody wants it and they're not sure why.
And then it's just cost prohibitive in both manpower and management and cognitive load and all of the things.
So there's that aspect of it.
We want to find a place that is somewhere in between.
Like what if I could have all the promise of Kubernetes, but not have to learn Kubernetes, right?
And that's another thing that we're talking about with things like Azure Container Apps.
Right.
And being able to have kind of best of both worlds.
Right.
And looking forward, I don't want to get into it yet, but just to give people a preview is you guys have built a CLI tools for Python and some templates that kind of help people realize that goal.
Much more quickly than just, all right, well, I guess I'm going to set up a Kubernetes cluster and nodes and all that kind of stuff.
Yeah.
Okay.
Well, Docker is an interesting one, right?
To do Kubernetes, you got to do Docker, right?
Or you got to do containers at least.
There's the look how easy it is to run Docker.
I just, you know, get the image, Docker run, off it goes.
Unless you've got multiple tiers like many apps do, right?
I've got like a database layer and maybe a background worker service for like emails and other long running jobs.
And then all of a sudden coordination that becomes really hard.
Yeah.
I'd say that like kind of where people start off with containerization is the Python app itself.
So the Python code, whether that's in like a Whiskey application or using ASCII or something.
So that's like Django, Flask, FastAPI.
So like running that in a container is a great place to start.
But hardly ever is that the whole application.
You know, just Flask and Django alone, you need some sort of web app at the front end, like a HTTP server, like Nginx or something.
And then you need the distribution to Whiskey.
So you need Genicorn or Yuvicorn or Hypercorn or one of the other corns to connect between the HTTP front end and the back.
And then once you've got that in place, you're like, okay, I need to configure my SSL certificates and my DNS and stuff.
So you can do that.
But I think people start to try and try to jam everything into one container.
Yeah.
And that's where it kind of gets.
Until it absolutely explodes.
You're like, all right, it just won't take it anymore.
Right.
But preserve that.
Just call run on it as long as you can.
Right.
Yeah.
People I imagine are trying.
Yeah.
And they're not supposed to be persistent.
Like, you know, containers are supposed to be immutable, but you can attach storage to them, which is where it gets tricky with databases.
Because really running something like Postgres and Docker, you can, but like, it's not going to be particularly fast.
And you've got all these extra challenges of if the image stops, then what did you just lose?
So, yeah, I think containerization is great to get some of the Python environment complexities.
Like, you know, you've got a virtual environment to configure.
How is that installed?
What version of Python?
So, there's like all the bits of Python that are specific to getting the Python app running consistently in one place and another.
So, Docker is great for that.
Containerizing is great for that.
But you often find yourself needing more than one container, which is where things start to get complicated.
Because then it's like, okay, I've got Redis in there.
I've got, I want to run Nginx in one container.
I want to run my app in another.
So, then how do you like coordinate all that stuff?
Right.
And just how do I keep them connected, right?
Because in regular non-Docker world, you just say my Redis string connection string is this.
My database connection string is that.
Nginx says I route traffic over either this Unix socket or through this HTTP socket.
But those are not stable as these Docker images come and go separately, right?
It gets tricky to connect them still.
Yeah, there's a connection and the coordination of it.
And things like Docker Compose, I think, helps with that there.
Anthony mentioned a very valid point around databases and containers.
I think when container development started to kind of hockey stick a little bit, I can't tell you how many times I answered the question, should I run my database in a container?
And I was like, well, no.
And then it was like, well, why not?
And I was like, okay, here's the 15 reasons why you should never do that.
Yeah.
And I go to my framework and write in the tutorial that shows me how to run Postgres.
Yeah, it was more of a like, what happens when it dies?
You know, and they go, oh, no, I mean, I lose my data.
Yes.
It says don't do that.
But they serve very well for, you know, emulating those big cloud managed services like Redis and like, you know, Postgres and stuff like that.
They would typically run in a managed service instead of trying to have your entire world, if you will, running on your local machine.
And then the other part of that is how many is too many?
If you, you know, the microservices type of, you know, scenario of are you going to run 200 individual containers on your local machine?
There is a cap where it's just too much, you know?
Yeah, yeah, for sure.
And we're even seeing some sort of swinging of the pendulum, I guess you would call it, back to articles like, give me my monolith back.
Life just got too hard.
Now, you know, my personal philosophy, and I'm not suggesting anyone else has to adopt it.
But when I think about these things like microservices versus monoliths and Docker and Kubernetes versus more simple things is I try to keep the complex parts in the areas that I'm really good at and not push them to areas that I have a little experience with.
Like, I don't have a great DevOps background, so I don't want to push tons of the complexity to DevOps and keep the code simple because I can handle complex code, but I can't handle complex DevOps.
Yeah.
Not right now anyway, you know?
So for me, I kind of try to think of the balance of like, what works for me, you know?
I literally saw an example where somebody was saying, I manage all of my configuration in its own repo, and then that sucks into my DevOps pipeline.
I was like, what is happening?
I'm not even going to talk about that.
You know, I'm sure that works for you.
But like you said, unless you really understand that level of, you know, complexity, you know, it's no thanks.
If you specialize in that area, then maybe that's exactly your secret sauce.
Yeah, yeah.
But if you don't, don't like see someone else be doing that and go, I should just do that because it's working for them.
Like maybe, but it's not a clear, I should just go that way, I think is the story.
Yeah, and I think just like in a coding world, like we can use things like, you know, interfaces and polymorphism to the nth degree.
And for a simplistic programmer, you know, examples, they're going, why are you doing that?
Because I can just do it in a single file.
Thanks.
Exactly.
Why do we have like dependency injection registries when it's 50 lines long?
Like I really just don't.
Yeah.
It's just not.
It's hello world, man.
Yeah, exactly.
Exactly.
It's just a manuscript script.
Right.
All right.
So maybe that probably sets the stage a little bit for the work that you two have been doing in this project we're going to talk about.
But one more predecessor, bit of history.
So one of the notable things about the Azure CLI, that is the CLI that everyone uses when they're not working in the crazy, belated, very full management portal, is built in Python, right?
Yes, it is.
Yes.
But it's not that that actually makes any difference for Python people.
It's just an interesting detail.
But that one is not focused as much on helping developers get their code out as maybe helping IT DevOps side of the world, DevOps on Azure.
Right.
I would say its primary goal is referred to as kind of a management ops plane functionality.
There is some capabilities in there for, you know, pushing up simplistic, you know, web applications.
There's a web app command where I can kind of get a simple page up.
And there's some static web apps capabilities within that command.
But when you get into, you know, a full kind of job to be done for a developer focused type of activity that does not serve that type of persona.
Sure.
All right.
Well, that brings us to your project.
Does your project have a name?
Just so people know, at the time of us talking about this, this is not yet released.
Yeah.
But at the time people are going to be listening to it, it will be released.
And so.
Yeah, sure.
I'm kind of behind the scenes.
Maybe I can pull up your screen here and start from there.
We'll call it the like lowercase Azure developer CLI.
Okay.
Because if it's uppercase, I think that means it has a name.
So we'll say it's the lowercase Azure developer CLI.
It's a standalone install.
Command is AZD or AZD, depending on where you're from.
Don't don't alienate Anthony.
Yeah.
Much of the other rest of the English speaking world.
Yeah.
Everywhere but the US.
And its primary goal is to, you know, make it easy for developers to get up and running
with both infrastructure and code, you know, in Azure based on at least initially, we've
got some out of the box templates to help establish kind of a getting started kind of to do app,
which at least in this particular example, we have a to do application that's got a Python
FastAPI middle tier with a React JS front end.
And then the back end is supported with Azure Cosmos DB with Mongo API.
Right.
So the way it's going to go now is it will have the Mongo API, but Mongo, the Mongo API can be pointed
at Cosmos DB, your document database in Azure, right?
Correct.
Let me ask another really quick question on that.
What's the interaction with the Mongo API?
Like, is there an ODM they're using?
Is it just PyMongo or rather motor or something like that?
Yeah.
This app was built within ODM.
It was built with Beanie.
I love Beanie.
I've, I converted the talk Python.fm and Python bytes.fm over to it.
The really big one left for me is the training site, which is massive, but it's, it's getting
some Beanie on it as well.
Yeah.
So for like a fully async ASCII app on FastAPI, Beanie is a great option because it's
like async from end to end and it uses the async motor client for talking to Mongo.
Yeah.
So yeah, it's super fast.
So that's what we've built for the to-do app, which is like the demo application.
This portion of talk Python to me is sponsored by NordVPN.
I've been a pain and happy NordVPN customer for over a year now.
So when they approached us to become a sponsor of the podcast, I was excited because it's
a product I've already been recommending.
I use NordVPN almost universally throughout the day on all my devices, whether it's my
Mac, my iPhone, or my iPad, I enable the auto connect feature and Nord keeps my connection
protected and ad free.
I'm sure you've heard that VPNs can keep your traffic private on public networks.
And that's true.
But let me tell you why I use NordVPN.
Privacy and malware protection.
First, privacy.
Ad companies are slowly eroding our privacy.
Shadow profiles are being built for you and being built for me by combining tracking scripts,
ISP data, and through data brokers.
If these were just being used for commercial ads, it'd be one thing.
But we've all heard stories about how groups have been targeted to affect negative social
outcomes.
Think Cambridge Analytica.
With Nord's built-in network-wide ad blocking and IP hiding, you'll limit the data that all
of these players get to collect on you.
What's so sweet about using Nord for this is it works across all of your apps.
Not just a browser plugin, but even native apps on your phone can't contact or load most
ads.
These same ad networks have been hijacked to deliver malware.
Nord also includes network-level malware protection as an added layer of safety.
And Nord has a great offer for you.
Use talkpython.fm/NordVPN to get a massive discount on a two-year plan that includes a free
month.
Nord is also risk-free.
There's literally no risk to you with their 30-day money-back guarantee.
Give it a try.
And if, like me, you love it, great.
If you don't, they'll issue a refund and you can pretend the entire situation never happened.
Say no to being manipulated by ad companies and enjoy the free and open internet on all of
your devices.
Visit talkpython.fm/NordVPN to get your subscription started today.
Yeah.
So let me see if I can summarize this for folks before we dive into more detail.
Basically, you guys have built this full stack-ish.
I guess full stack fits.
Full stack, FastAPI, document, database, JavaScript front-end app that sort of natively integrates
in the ways that you would expect it to in Azure.
Not just you can get it up there and get it to run, but it's got different sections.
It uses a hosted database.
It integrates with CICD.
It has tests that plug into all those kinds of things and so on.
And so you can take that and sort of publish that to Azure.
But then, of course, you can just use it as a prototype to say, well, we don't need to do,
we need this other thing.
So we'll swap out, whatever.
Yeah.
Right?
Something like that.
Yeah.
I would say there's a couple of key components.
You know, we do all of our commands.
Again, it's command line based.
We focus on a CLI first approach to this for a couple of reasons.
A, it feels natural for a lot of developers who kind of are on a terminal constantly, but
also allows if VS Code wants to build an experience on top of it, if PyTorch wants to build an experience
on top of it, they can, you know, because they just call into those same hooks.
But also...
Can we consume the CLI as a Python library?
Well, that's a good question because we are also looking at making this an extension inside
of the core Azure CLI.
So we have actually wrapped this as a Python extension.
Okay.
For them.
Interesting.
Yeah.
I mean, you can always sub process it around all day you want, but...
It's written in Go.
Okay.
Got it.
Yeah.
So it's A, it's super lightweight.
It's like five and a half megs.
It's really small.
And once you have the binary, you have it.
That is one of the true beauties of Go.
Yeah.
The other parts of it, like you mentioned, if there's pieces of this that, of the app,
if I back up one section here, is that a lot of the samples that we come across, they are
a hello world.
They're a very simplistic app.
And once you kind of go through the process, when you're all done with it, you're like, okay,
this is great.
I built my hello world app.
Now what?
Right.
This is an opinionated structure that allows you to swap out components, build upon it.
Like I can take out the FastAPI if I want to use Flask or Django or whatever.
I can swap that out and do it.
Swap in Postgres if I'd like.
We have an infrastructure as code.
Right now we're using Bicep to do that.
And in the future we'll support things like Terraform and other IAC providers.
And that's just how we would swap out any of the infrastructure.
Right.
This particular sample, we are targeting the Azure container apps as a host, as our target
host.
But we do support paths.
And in the future also things like Kubernetes.
Yep.
And also in terms of the, how cloud native is it?
If you don't scroll away just yet, come back.
Okay, sorry.
Yeah, no worries.
In terms of just how cloud native it is, like how much does it reach into all those things?
Basically for areas that are interesting.
Azure container apps, right?
So you've got, Anthony, let me know what this sounds like.
You've got maybe an Nginx type of container.
And then you've got one that runs UVicorn, FastAPI, Workers.
Yeah.
There's two containers in this example.
But like, yeah, Azure container apps is more where you've got a collection of containers that
form an application.
Like if you put that in a Docker Compose or something.
Yeah.
And then we kind of spin those up for you and manage that for you.
So you don't have to think of or plan about things like Kubernetes.
And it does SSL certificates and DNS and everything else for you.
So nice.
So you don't have to worry about let's encrypt and stuff.
Yeah.
Does all that for you.
So nice.
And then that hosted Cosmos DB.
Yeah.
So Cosmos DB is the document database on Azure.
And when you deploy it, you can choose which API you want it to have.
You can pick the Cosmos API or you can pick a Mongo API.
So if you pick the Mongo API, then you can use your existing Mongo tools and clients with it.
Like Beanie and so on.
Yeah.
Exactly.
And that would just work.
Okay.
And then monitoring.
Azure Monitor.
This is like Sentry type stuff, right?
Like is it up?
Is it running into errors?
Does it also do performance or just sort of error?
Yeah.
It will do all of your calls.
Basically it does tracing between all of the different containers or different components
of the app.
You can look at telemetry between those calls.
You know, how long is a call taking to the database?
You know, you can look at the individual calls, see where the errors are, trace those down to
like it was a get call on, you know, the to-dos collection and actually look at those and
then introspect those inside of Azure Monitor.
So it's pretty detailed.
Yeah.
That's really nice.
Yeah.
I use that stuff all the time for my sites, you know, if I run into a problem, probably
the first place I go is the actual log.
But if it's not super clear right away, I'm like, all right, let's go to the monitoring and
see the local variables and see what was going on for real.
And then the last one is secrets.
Like it is nice to just check in your API keys into Azure and to GitHub.
I don't understand why I heard you're not supposed to.
No, I understand why you're not supposed to.
Yeah.
The Key Vault is really great in the sense of, yeah, this is kind of, it is the sauce, if you will, where we keep the connection string for the Mongo database.
And then within the actual FastAPI app, we can then connect to the Key Vault to pull that out securely.
And then really the nice thing about Key Vault is if we need to change it, we can just change that one key and not have to kind of redeploy all the other apps.
It's just great.
And then from a local development story there, we use environment variables to have that locally as opposed to passing it around or keeping it in a GitHub repo, of course.
Got it.
The apps kind of like built in a way that we said, if we were building a production app, this is how we do it.
So like Shane said, it's, it's the example app is opinionated because we've picked how we've configured Python version environments and how I've done the testing and how the ASCII configuration works and stuff like that.
But it's done in a way that it's okay.
This is a production style web app that we put together.
And here's how you would deploy it using this new, the new AZD CLI.
So the new Azure Dev CLI.
And the other important thing is that you don't have to learn all these new concepts.
So it's not like we've said, okay, we've got our own configuration language that we're going to throw at you.
And we've got our own, you know, like here's a hundred YAML files you need to write or stuff like that.
It's try to keep it as native as possible.
So in the Python application, in the web app, then there's a Docker file and there's a pyproject.toml.
And, you know, if you want to run the Docker file locally, you can do that.
One of the opinions that you're, you're choosing is like use poetry, for example, right?
Yeah.
So using poetry to manage the dependencies and make those, I guess, pinning dependencies and making them between creating things like lock files.
But also if you work on the repo, the demo repo in VS Code, you know, you can run and debug the app locally as well.
So you don't have to figure out all the extra complexity.
So, yeah, we kind of really thought, okay, let's write, you know, a production type application using all the normal tools we would use,
which is like Docker files and pyproject.toml requirements files.
And then on the front end app, like, you know, it's in React.
So we've got our normal project and Node.js configuration and stuff.
Right.
All the NPM stuff.
Yeah.
And then what would the, what would the developer need to describe that in a way that then can be deployed up to the cloud and trying to make that as simple as possible?
Sure.
Yeah.
So Shane, you spoke about Bicept.
Right.
As a way to get your things up.
And I think it might be worth touching a little bit on the Bicept story.
Sure.
I mean, that's usually arm wrestling for me, but I'm thinking, no, no.
Bicept, Bicept is, it's like Ansible or Terraform.
Yeah.
But it's, it's one of these, it's kind of a Azure native thing, right?
For DevOps.
Most Azure DevOps folks would understand if we said, hey, what's your arm template look like?
Azure resource manager.
Management template.
Yes.
Yeah.
Management.
Lots of JSON, a lot of JSON, thousands of lines of JSON.
Not easy to write, read, or kind of understand.
Bicept is a simpler format and kind of self-describing almost.
So we use that right now to describe the resources that we're going to provision and deploy our app to.
And in this particular case, in this template, we have a number of templates, but in this template,
we're putting together a container registry.
We're provisioning the container apps environments, you know, the web apps, the Mongo database, a lot of things that, you know, if you did those individually, it would take a lot of time to do.
So we're doing that all as a part of the one single line command to do that.
So we're looking at implementing, you know, other IAC providers like Terraform and Pulumi as well.
And, you know, if that makes you happy in your place, you know, we're not hiding anything in what we're doing.
We're more of an orchestrator of the tools instead of hiding some secret commands to make all this happen.
We like folks to kind of see what the steps are to do it.
We're just going to do the steps for you in a single press of the button, press the easy button, you know?
Yeah.
Yeah, absolutely.
Right.
That's great.
So maybe, Anthony, it would be a good time for you to sort of talk us through some of the code and the projects,
because I think that'll give people a sense of what they're getting in terms of what this app looks like.
Yeah.
So the demo app that we put together has got two main containers on the front end, which is the React.js web app,
which is all running under Node 16, and then a FastAPI API, which does basically the middleware between the front end and the database in the back end.
So the React.js one is an app that we wrote to demonstrate a lot of functionality and to-do management app, basically.
But in terms of the FastAPI app, that...
The canonical example that people may try.
Yeah, exactly.
And the FastAPI one is the one that I worked on with the team.
And that's really kind of looking at, okay, if we did a modern Python application, how would we write it and how would we deploy it?
And like I said, using poetry for requirements management and stuff.
But you could use whatever.
This is an example.
You don't have to use poetry.
But I'm just showing the latest approach and the latest design with the application.
And then if you want to swap out or change bits of it, obviously you can do that.
So yeah, the project itself has got a pyproject.toml.
We're using FastAPI, Uvacorn, and then Beanie is the ODM.
And then a nice package...
Maybe just tell people real quick about just what Beanie is, just so that...
I've had Rumin on the show before, but maybe not everyone knows.
Yeah, so if you're working with FastAPI, often you would describe models that the API reads or writes or reflects using something like Pydantic.
So these are kind of your data classes.
So Beanie basically allows you to write Pydantic style models, data classes, and then read and write those from a Mongo database.
So this app is basically written in a way that the to-do list items, the tasks and stuff like that, are all reflected in a models file.
And then Beanie does the work of actually putting those in a database.
So we have a to-do list.
We can also do things like to-do items.
And each of those are a document, but they're written in a way that's very similar, basically identical to how you'd write a Pydantic model.
Beanie also allows you to...
Right, just slightly different base class.
Yeah, Beanie also allows you to lazily reflect Beanie models into Pydantic models.
So when you're working with FastAPI, you can get all that nice functionality of using Pydantic, but you get a lot of the performance of basically trying to keep it as close to the actual document in Mongo as possible.
So yeah, that's one big challenge people have to overcome when they use stuff like Pydantic, which is like, when do you put stuff into Pydantic models?
Like if you're reading a thousand rows from the database and you're just going to give that straight to the user, there's no point in reflecting all that into Pydantic and then sending it back out again.
Right, doing all the conversions or whatever craziness.
Yeah.
Yeah, or just slow it down.
Yeah, okay, cool.
And so this is a really good choice because it matches the native MongoDB API and it matches FastAPI on at least two levels.
Pydantic models are all about driving the data exchange and the open API specification, which is fantastic.
But then also Beanie is an async ODM.
So what you do, it allows you to fully leverage the scalability of FastAPI.
I think it's a great choice.
It's a nice configuration and it's nice to run as well.
It's pretty responsive.
And then what we did on the app itself, so in FastAPI, a couple of things that you have to do are configuring cores, which is always fun.
And then we've put tracing in the app as well.
I just ran into a cores error on just an HTML file I opened.
I'm like, there is no server.
I can't do cores.
Please don't do this.
Yeah, it becomes a bit of a challenge.
It does.
So on FastAPI, we've been doing a lot of work over the last year on a project called OpenTelemetry.
It's a cross-company open source collaboration to create basically a tracing and eventing framework across multiple languages.
So you can use OpenTelemetry in Go, Rust, Python, and basically install.
Does it connect into the thing that Shane was talking about with the Azure monitoring?
Yeah, it does.
And it also connects into a whole bunch of other monitoring tools.
It's not the Azure monitoring library for Python.
It is an agnostic library.
Nice.
Which is, it's got support for FastAPI.
It also has support for lots of other Python components.
So when you get the actual logging data, for example, if your app crashed or somebody made a request which gave a 500 error, in Azure Monitor, you get the full stack trace and you get all the events that led up to that as well.
So it's not just a log file, basically.
We're actually putting stuff in the Python app to get all the tracing information.
You can also use it to see like performance regressions and like slow pages or slow requests.
So in Azure Monitor, you can actually go and see what are like the slowest requests I've had to the application and what was the cause of that.
Yeah.
And none of that stuff is proprietary.
It's all basically using OpenTelemetry, which is open source.
But we have a special source is the exporter.
So we export OpenTelemetry events to Azure Monitor.
Okay.
Yeah, this all looks super nice.
And the reason I wanted you to talk through this is the project looks really nice.
It looks like an app that I would like to use as a starting place for my final destination rather than just, oh, cool.
There's a main.py or app.py.
It's all just jammed in there.
And like, you know, it feels like a good starting point.
Yeah.
And then, like I mentioned, like debugging is set up already.
So yeah, in VS Code, you can either debug the React app or the API, the FastAPI app.
And that will run the whole application locally.
Does that run just on your local machine or does that like fire up the containers?
It just runs on your local machine.
So it would run FastAPI locally.
I give that a thumbs up.
Yeah, yeah.
So if you wanted to, for example, debug the front end and it needs to get, just go start the back end and then go debug the front end.
Something like that, right?
Yeah.
Just trying to keep it super simple.
Yeah, no, that's good.
And then we also wrote tests for both components.
So yeah, the ToDo app comes with its own unit tests for FastAPI and then for the front end as well.
And then all of that's set up in VS Code.
Well, it's all, they're all pytest tests.
So if you just want to run pytest over it, then you can.
But yeah, asynchronous FastAPI tests are a bit fiddly to set up the first time.
So we've done all that as a demo as well.
Yeah, this is great.
And one area that we haven't talked about yet, Shane, when you deploy this, and we can talk about how to do that in just a second, is that it automatically sets up, at least with one of those CLI commands, CI, CD, continuous integration and continuous delivery or deployment.
And these tests that Anthony's talking about, these automatically just like start running on check-ins for you, right?
Like that whole lifecycle is connected here.
Yeah, it's, Anthony, I don't know if you could maybe scroll up and touch on the GitHub actions that are included there.
So with every template that we're providing out of the box, we include the GitHub actions in order to run those.
So on the builds, we'll actually provision, deploy, and we would include the test run as well as a part of the container build.
If it's targeting containers or if it's paths, we would have the test command, which is not in this particular one.
But it would be like AZD test would be the command that would run.
It would run through all the testing that are in there depending on the platform.
Yeah, that's great.
So yeah, it gets us to that point.
Like I said, as a developer, I just want to check in code and know that my tests are going to run.
If they pass, it deploys to the environment that's specified.
And it gets me to a happy place as a developer, you know?
Right, right, right.
You don't have to know about this stuff.
And, you know, to some degree, that might not be 100% true, right?
Like if your code is running somewhere, you need to have some level of understanding, even if you don't have to directly touch it.
But I think one of the big benefits is for a lot of people, you can start running there and you can kind of grow into a better, deeper understanding.
You don't have to like swallow the whole, I learned all of the Linux configuration all in one shot just to get it to even start, you know?
Yeah.
And I think it's important to mention a couple of times is that even though we have a command, like in order to get this whole architecture that Anthony just walked through,
if I wanted to get this into Azure, I would just run AZD up and then pass in the name of the template repo, you know?
And it would then deploy all of that and run it for me.
Yeah, yeah.
Let's talk about like, we've got the app.
Anthony talked about running and developing it locally.
Right.
Now what?
Like I actually want to get it up and running.
I want CI, CD.
I want all the things.
Yeah.
So if I started from nothing, if I was just opened up, you know, VS Code or my command line or whatever I'm in in a terminal,
I could just run AZD up and then pass in a --template.
And in this particular case, it would be like to do dash Python, ACA dash Mongo.
Right.
And that would clone that repo.
It would then start to provision those resources on Azure, you know, based on your login to Azure and then use the BICEP infrastructure definitions to create that target host if it's PaaS or Azure container apps.
And then build and deploy, you know, the API, the front end, and then make all those connections and so on as we walk through how that's all put together.
Right.
And so it's worth thinking about that, those BICEP DevOps commands and configuration, if you want a slight variation of what this gives you, you change the BICEP and then AZD up just uses your slight variation, right?
Well, yeah, exactly.
And, you know, one of the services that is very common to use, you know, in our, in our apps nowadays is Redis.
Like if I want to add Redis and make a couple of changes, I could just put that definition in my BICEP code, add in the environment variables that are necessary to, you know, expose in my app and call up.
And then we would then push them into Key Vault, you know, provision the service, redeploy the code.
And hopefully if we typed it all right, it would happen right.
Right.
So that would be the way to do that for sure.
If I run the AZD, you know, pipeline command and help that establish my GitHub repo and kick off those workflows in the GitHub actions.
At that point, I could just make those changes to the BICEP files and check those in.
And then the workflow would kick off that process for me.
That's cool.
Can I start from code and then do this?
Or do I do the template to create the code and the GitHub repo?
Like if I already have a GitHub repo, for example.
Yeah, that's a good question.
And we have some documentation and walkthroughs on how to, what we call Devify your project.
And basically it will walk you through how to set up that an infra folder.
That infra folder will contain the BICEP definitions.
And we've got an Azure.yaml file, which will hold a couple of the kind of naming structures that we have as an opinionated way to name things.
And then also set up that target host.
Again, it's that PaaS or is it, you know, app service or is it container apps or AKS?
So a little bit of setup.
And then you can start using AZD up or AZD deploy.
You just want to deploy the app to then, you know, take your code and push it onto the platform.
Okay.
That sounds really good.
What about the, talk about the continuous delivery part.
So I've got this created.
I've got a GitHub repo.
It's up and running.
How do I associate a domain name, by the way, first?
Well, the domain name, we would push it onto the, obviously onto Azure and then create that.
Like your app.
Yeah.
Do it UID.Azure or something like that.
Blah, blah, blah.
Azure websites.net slash la, la, la.
Yep.
Then that would be part of that configuration inside of Azure portal or through the management
plane where you'd actually kind of go through of associating your domain name with whatever
your entry point is.
In this case, it's going to be the React front end, right?
So I would go into that particular app service and set that up with your DNS and such there.
Yeah.
You probably want to, you probably want the API if you want to surface an API out of fast
API.
Yeah.
And then you want the React front end, obviously, for most people.
Yeah.
And you could add, if you want to get into things like that, one of the pieces you could
add is things like Azure front door or, you know, API management or something like that
in front of those components too.
Okay.
Well, that step is like a separate step.
Yeah.
You go in there and you configure it because how often do you really want to have a thing
messing with your DNS?
Yeah.
As little as possible.
It's a one-time shot.
That's all I want to do with.
Yeah.
Please wait 24 to 48 hours for this to propagate.
Like, no.
You know, it's funny.
I haven't had a DNS chain, knock wood.
I haven't had a DNS chain to take longer than a few minutes nowadays, but.
Yeah.
It is a lot better than it used to be.
I've done it.
I just changed all of our email and stuff around and there's been a lot of MX records and the
like verification keys and yeah, it's.
No matter how many times you do it, you're sure you did it wrong.
Yep.
That's for sure.
Yeah.
All right.
So back to my original train of thought.
I was like, let's just sort of kind of wrap this up with the continuous delivery.
I've got the app up.
Now we know how to get the domain associated with it and whatnot.
You know, presumably go and buy a domain wherever you buy domains.
Point it at it.
Let it map over.
But then I make some changes and I get push a thing.
What happens now?
Yeah.
If you set up your, your CI CD pipeline, it would then run through that same process.
And we showed it in the GitHub actions here and talk through it.
It would run your test, do the deployments.
We do support multiple environments.
So we can help set up a, like a dev or a QA environment as well, other than just a single.
Like a staging.
Yeah.
Sort of thing that people can.
Yeah.
And then you could set up some processes, you know, within Azure, like, hey, this passes,
let me do a, an IP switch or however you manage that in, in a platform based on your scenario.
But yeah, we get to that point where we're just checking in code and having a positive track.
Okay.
And do you, what's the branching structure look like?
If I just push domain, is that going to go live and I got to work on a dev branch to not
do that?
Or is there like a prod branch or?
Yeah.
You can set that up in your GitHub action.
Right.
Okay.
Right now we have, the template is just going to work.
If I don't do anything, what happens?
It's main branch.
Main branch goes straight to production.
That's right.
I love it.
Y'all are just carefree to test for it.
Do it live.
The users are the testers.
Let's go.
Do it live.
No.
Okay.
Got it.
So you would just tweak your GitHub action Yable file and change your branch name or something?
Yeah.
You could set some conditionals in the GitHub action based on the environments that are coming
in.
Cool.
Anthony, what were you going to say?
Yeah.
It assumes a single branch strategy, but I mean, or you can tell it to generate the template
for you and you can put that template wherever.
It's pretty easy nowadays to say with GitHub, you know, which branch and stuff this should
apply for, or this pipeline should only run on pull requests.
Or my recommendation to people is that you keep main highly protected.
You don't let people push directly to main and it can only be merged into, and then it has
to be reviewed and stuff.
I think keeping a clean main branch is good strategy anyway.
You can have a feature branch or release branch separately to that.
So probably the main branch would be your dev, your sort of live dev environment.
And then maybe you want a feature branch or release, so main release branch separately
to that, but using the same templates.
So all you're really changing is the targeted environment names.
Yeah.
Okay.
That sounds like good advice.
All right, guys.
Well, we're getting a little short on time now.
This looks like a really interesting project.
I love the technical choices on the backend, you know, that you've made to sort of create
building blocks for people.
I guess we could wrap it up real quickly with, we've got this more DevOps-y management,
IT-like CLI that people have used previously.
If they're doing Python stuff and they kind of want this container-hosted world, this is
probably the recommended way, at least from you all.
Yeah.
If you want to get started and...
Fantastic.
All right.
Anything else you want to add about this?
I'd like to call it a show.
No, nothing from my side.
A template that you can kind of build upon.
Shane is frozen.
Something that you want.
Oh, no.
Shane is frozen.
A production-style app.
This is a great way to get started.
I thought he was just getting tired because it's late where he is, but no.
All right.
Well, Anthony, I'm sure this is not going to come as a big surprise given all of your current
work and stuff.
But I'll ask you the final two questions first, and then we'll hopefully get Shane
back shortly.
Good to write some Python code?
What editor are you using these days still?
Definitely VS Code.
But tell people about the font.
Comic Sans Mono.
So it's a Comic Sans font, but in Mono space.
Awesome.
Is it a nerd font?
There is.
I think there's a nerd font flavor of it.
I haven't configured my terminal to use Comic Mono yet because I think that'd be going
a bit far.
It actually looks...
It'd be madness.
It looks better than you think.
It looks good.
It looks way better than you would think Comic Sans looks.
And it's really readable.
I would totally be down to it.
I had to make a DNS joke.
You did.
You took yourself offline, but you're back.
And just in time to answer the question, have you written some Python code?
What editor are you using these days?
I use VS Code.
Right on.
I don't know.
I use VS Code for taking notes.
I mean, it's just...
Yeah.
It's Markdown or if it's in Mark...
Everything's in Markdown or whatever code, so...
Yeah.
All my notes these days are in Markdown.
If not like a Google Doc, Zoho Doc, something like that.
It's definitely in Markdown.
It was like...
I think it was like three years ago.
I was in a meeting with Chris Diaz, who's the kind of owner of VS Code.
And he pulled up his screen and he started taking notes in VS Code.
And I was like, I'm an idiot.
I should be doing that.
Yes.
Just go to the bottom right.
Change that little language to Markdown.
You're good to go.
That's right.
Absolutely.
Notepad.
Notepad is dead to me.
Yeah.
The problem I have at the moment is I've probably got too many extensions.
I just realized this morning I have 99 now.
So I'm nearly at three figures.
There might not be room at the UI to just display that number.
It might stop at two digits.
Just kidding.
Yeah.
That's awesome.
I tell you, I didn't even...
The first bit of...
Here's some irony.
The first time I ever wrote Python was...
It feels like 100 years ago, but...
Was actually to write a Sublime add-in to enable .NET IntelliSense for .NET Core.
So I was on the OmniSharp team to write the add-ins for that.
So completely like not Python related, but I was using Python to enable .NET and Sublime back in the day.
That's cool.
Yeah.
So very meta.
Yeah.
Using the editor to write the editor.
All right.
And then notable PyPI package.
Anything you want to give a shout out to?
I mean, we definitely mentioned a bunch of fun ones, but...
Yeah.
I'd say Beanie Perflint, which is one of mine.
But yeah, check out Perflint if you want to.
And check out Beanie as well.
It's a really nice approach to document databases in asynchronous front ends.
Yeah.
Especially if you're doing FastAPI.
I was going to say, I used to struggle with document databases and Pydantic and Beanie made my life a whole lot better.
Yeah.
I think we all concur.
Beanie.
Definitely a good one.
Good call.
Cool.
Yeah, absolutely.
All right, guys.
Final call to action.
People want to get started with this.
Once it's out, what do they do?
When they're listening to this, it'll be out.
So not to confuse folks.
I've got a link that folks can go and check this out.
It'll obviously be in the show notes.
It's a short link.
It's an aka.ms and it's try-aca-python.
Right on.
And they can see the project template, sign up for our preview, check out the repos, et cetera.
Cool.
Yeah, it looks like you need a project.
And definitely people are doing Azure.
It supercharges you into a ton of best practices.
Yeah, for sure.
Well, nice work.
And thanks for joining me to talk about it.
Yeah, I appreciate the time.
Thanks.
Yeah, you bet.
Bye.
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.
Say no to being manipulated by ad companies and enjoy the free and open internet.
Get NordVPN on all your devices.
Set auto-connect and relax.
Visit talkpython.fm/NordVPN to get your risk-free subscription started today.
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.
I'll see you next time.