199: Is Azure Right for a Side Project? - Pamela Fox

Brian:

I'm a software engineer. I've got a side project, and I want to, like, you know, put something live. I've got it local. I wanna get it live. Is Azure for me, or is should I look somewhere else?

Brian:

Well, welcome to the show. It's kinda neat to have you here. So you're Pamela Fox. Right?

Pamela:

Yeah. That's right. Yep.

Brian:

Okay. That's a terrible intro. I'm I'm out of practice. So so, but you were recently on Python Bytes. I don't know how somebody did Michael convince you to come on there or something?

Brian:

Or

Pamela:

He just tooted at me. And Okay. That's that's cool. I I said I should, you know, go on more streams just so I change out of my pajamas on more frequent pieces.

Brian:

So that was episode 323. You're, tell me who you are and, like, you know, what do you do?

Pamela:

So I am currently at Microsoft on the cloud advocacy team, specifically the Python team. And I've only been here for maybe 6 months or so. Actually, no. 9 months because I basically joined and then I had my baby the the 5 days after. And my baby is now now 9 months old.

Pamela:

So yeah. Okay. Yeah. It was a it was a very quick rush to get set up before the baby came out.

Brian:

But did you get take time off then?

Pamela:

I did. Yeah. Okay. Yeah. So so after joining you know, I joined, I said hi to everyone on my team.

Pamela:

And then 5 days later, I disappeared for 3 months. And then I took some time off later too. So, so yeah. And before that, I was at UC Berkeley teaching Python for a year and a half. And that was nice because it was I never really had gotten deep into Python.

Pamela:

I'd used it for years years years years. But you know, I just I used it the way you use something to to, you know, build tools. I didn't really get into the nitty gritty, but when you have, like, thousands of students asking questions, you get into the nitty gritty pretty fast. So that was that was really fun.

Brian:

So this was what level? Was that, like, introductory, like, c s one one or

Pamela:

Well, that's a good question because this is at UC Berkeley. So it was c s 61 a and that's the first class in the Berkeley CS sequence. But, we usually call it as 1.5 And that it's this first class in the sequence, but it's really not designed for people who've never programmed before. So we we beg people to do an a like, an actual proper intro to programming class before they take c a 61 a, because it is really difficult. And at least when I was there, it was somewhat the Wiener course, and that your grade in it would actually determine whether you could be a CS major, which, you know, that everything about that sucks.

Pamela:

But, it was a very interesting course this, you know, if we ignore everything about how academia is horrible.

Brian:

Yeah. Well, at least it's Python because the the Wiener course I took is was Lisp. Or

Pamela:

Oh, I didn't mention it was also Scheme, if you want to

Brian:

ask about Scheme. That's what we did. So you did so they still do that. Okay.

Pamela:

Yeah. So our course is called the structure interpretation of computer programs. So it was originally taught in Scheme and then ported to mostly be in Python. And then at the end of the semester, we would do Scheme, and we would write a compiler for Scheme in Python.

Brian:

Well, that actually might be fun.

Pamela:

It actually I actually like that. I I think it's really interesting to write, to write compilers because you get to really understand, you know, understand it more. Like I like where you do, Museope, Scheme has something called Museope, which is a different scope than we have in Python. And so getting to actually implement that, I I think that's really interesting.

Brian:

Okay. So UC Berkeley, and then where'd you go there then after that?

Pamela:

Oh, yeah. So before that, I have had, that was my most recent. But, I just don't know what order to

Brian:

go in. But my first job was at Google where I

Pamela:

was on the Maps API, and that that's where I did a lot of JavaScript. And and then did some Python at the end when App Engine came out and, wrote a bunch of App Engines app in Python. And then after Google, I was at Coursera, where I was one of the first front end engineers. Although, of course, I was really full stack, and our stack was, was Django

Brian:

Okay.

Pamela:

At the time until we changed it all. And then I went to Khan Academy where I wrote most of the computer programming courses that are still on the site and also was a full 2nd year, and there, the stack was Flask, Con Python.

Brian:

Okay. Nice. The stack being the stack that you're right that the

Pamela:

Oh, for Khan Academy, it's the stack that it was running on. The courses that we taught, that are up there now. So our JavaScript, HTML, and SQL. So Khan Academy never actually taught Python, but it was running on Flask. They did recently did a whole whole big project to port it over to Go.

Pamela:

So I have briefly been a Go engineer as well.

Brian:

Okay. Alright. So, and before so that's that's your career. How did you decide to get into this in the first place? Oh.

Brian:

Do you remember?

Pamela:

Well, yes. Yes. Well, my dad is a computer scientist, and my mom is a scientific programmer. So

Brian:

Wow.

Pamela:

Both pretty into computers. They met at Caltech. So my dad was working on physics at Caltech and, like, early in the supercomputers movement. So he he built a supercomputer called the Caltech Cosmic Cube, which is a really, really cool name. And, and he was working with like so he's actually the advisor of Stephen Wolfram and he was working with Feynman.

Pamela:

They were, I think, both co advisors of the physics department or something. So, yeah, so he was Wow. He was way into computing because that was how they could do physics calculations more more quickly, especially parallel computing. And so he still does that today. He works on does a lot of distributed computing research.

Pamela:

And then and then my mom, she was at Caltech and then went on to work at JPL, and she would write programs for, software, you know, for satellites to, you know, go up in the air. And she she did a lot of analysis of spectrums, stuff I don't actually understand because I'm not a scientist.

Brian:

Well, I that that just sounds amazing. I'm just coming from a from a perspective of, like, everybody at my Thanksgiving says, so what do you do?

Pamela:

Yeah. Whereas the only conversations I ever have with my dad are about, cloud computing. He loves talking about cloud computing.

Brian:

Interesting. Well, I'm gonna actually ask you about that also. So, so the the the role this is perfect. So you're the Python one of the Python dev advocates for Microsoft. And are you so is everybody all the people I know, like, I guess you don't know who I know, but Anthony and others, are are they are they focused on Azure or Python or is it the same thing?

Brian:

Or

Pamela:

Yeah. So our team is Anthony Shaw and Jay Miller, Sarah Kaiser, and me. So we are the Python Cloud App C team. So if those are the people you know, we are all focused on Python with Azure. Although, Sarah I mean, the thing is, like, we all dabble into everything.

Pamela:

So, you know, we're also hoping that Python works well in this code, and, you know, we we do a lot of looking into that and code spaces and dev containers. Sarah, in particular, does a lot around the Jupyter experience because Sarah comes from a scientific computing background.

Brian:

Okay.

Pamela:

So that's that's more you know, she's the expert there. But, yeah, generally, we're tasked on helping Python developers be successful with Azure services.

Brian:

Okay. Well, so when I I'm gonna kinda guess I jump into the topic. When I I've looked at, like, the at when I, like, just search for Azure, I get azure.microsoft.com. It shows up. And it and then even if I, like, sign up or something or look at it's a little or at least I haven't looked lately, but it last time I tried to look, it was a little intimidating.

Brian:

So is and it actually, I was wasn't sure if I really should be there. Like, maybe I don't belong here. It feels like it might be perfect for a business. But how about and the topic I kinda wanna bring up is I'm a software engineer. I've got a side project, and I want to, like, you know, put something live.

Brian:

I've got it local. I wanna get it live. Is Azure for me, or is should I look somewhere?

Pamela:

Yeah. That's a great question. So I you know, when I was on maternity leave, I did get really bored because babies do a lot of sleeping in the first few months actually. They're primarily sleeping on on me. So, so I did start taking my old app engine apps and porting them to Azure.

Pamela:

And, I couldn't ask anyone on my team how to do it because in theory, I wasn't working. So so, you know, I had to I had to do do some searching myself and figure it out. So what I started with, was, app service, and that I think is the most approachable, way to get to get started and to deploy apps. And it's the most, akin to to App Engine, so if you're coming from come coming from somewhere else. So I basically went through these I found these app service tutorials and went to the tutorials and then started, started pouring my apps over.

Pamela:

So so, yeah, I think app service is is it's designed to be quite easy to get started, and it has code built in that understands about Flask apps and Django apps. So it actually tries to do the right thing for Flask apps and Django apps, but you can also override that code. If you you have your own configuration like your own gunicorn configuration or something like that, then you can override that code. But the build system, it's called Oryx. It does actually have all this code to detect Flax, to text Django, and set them up appropriately.

Brian:

Okay.

Pamela:

So I I think that is approachable for, you know, just a non enterprise software developer.

Brian:

Okay.

Pamela:

And the pricing for that is pretty good. Where it does get tricky is when you're starting up when you're adding a database because databases are more expensive than, than the hosting platforms.

Brian:

Well, if I've got if I've got Django, I've got a database. Right?

Pamela:

Right. So that's the thing. Right? If you're so if you're doing Django, you most likely have a database. And, if you were doing just like a single server somewhere, you know, like a server that you rent to the cloud, then you could use, you know, SQLite and yes.

Pamela:

Simon Wilson, you know, big fan of SQLite. And locally, of course, you can use SQLite. But you can't use SQLite in the on the, you know, in the at least in the Azure cloud because of the file system, how it's set up in the cloud, because of it being NFS, I think. Just the way the file system is set up, it's just not reliable to use SQLite, so it's not it's not recommended.

Brian:

Okay.

Pamela:

So that means you need a proper a proper a proper database. So Azure does have databases, the one that I use the most option often is the Postgres flexible server. But it does cost a minimum of about $12 a month depending on what region you're in. So so that that to me is could be a this the decision factor for someone to you know, are you willing to spend $12 a month on your database? It it depends on, like, what level of, you know, hobbyists that we're talking about here.

Pamela:

Right?

Brian:

Right. Okay.

Pamela:

If you're hoping to spend $0 on the database, but, you know, if you're okay with 12, then then it is a nice option.

Brian:

Okay. So, like, so that that well, what's the rest of it? So if I'm paying $12 for the database to what's the rest of it? And okay. I'm gonna be like I've told you this, but I wanna be transparent with everybody else listening.

Brian:

I have a side project. It's one of the reasons why I've been kinda absent since, like, last August or something like that, is I've kicking around the side project idea. So I wanna get it off the ground. I, it's still just sort of in the idea phase. I've been doing a lot of research, but I do want to get it to the point where it can make a little money.

Brian:

And for me, I think $12 a month, I can I? That's fine. Yeah. But but what is the rest of it? I mean, that's the database, but am I paying for the the application also then?

Pamela:

Yeah. Good question. So, there's this pricing calculator that I've started using recently because you can actually put in all the services and, and do the do the calculations for it. But you can also just look at the individual pricing pages. The thing is that the pricing does vary on region, and I think maybe where you yourself, where you live perhaps too.

Pamela:

But if we look at the app service pricing oh, yes. By currency. Okay. So, like, central US, USD. So the thing is that there are there's different SKUs, different configurations depending on how much, you know, how much traffic you're gonna need.

Pamela:

Right? So there is on app service, there is a free a free usage tier with, like, you know, starting off with your free free account. Then you could go to a sheer a shared environment, and they they call that for just dev and test. And that would be point 013 per hour. Then if you go to basic, they still claim that's for dev and test, but I I run all of mine on basic.

Pamela:

Let me I should double check that, but I think I think all mine are are running on on basic. There you get 10 gigabytes of disk space up to 3 instances, and then that's 0.075 per hour. So how many hours are in a month? 730. Okay.

Pamela:

So 7:30 times 0.075. So that one says that's $54, but I haven't paid $54 for any of my, any of mine. So I must be running maybe I'm even running on free or shared right now. So, you know, I think it does depend on what, you know, what's the traffic you expect. Can you do caching?

Pamela:

Right? So I put all of my things behind, usually behind a CDN. Right? It depends on what you're doing and whether you can do any form of caching. But the CDNs are, you know, generally cheaper because all they're doing you know, they're just to cache, so you don't have to do a lot of computing.

Pamela:

And so that that lowers my prices quite a bit. So let me just see which app service plan I'm using on my personal account. I do try to do things on my personal account just so I can feel the, you know, feel the pain of budgeting myself.

Brian:

Okay.

Pamela:

So I am using b one, basic one. Okay. But that has not really cost me very much. For me, the thing that has cost has been the the the, Postgres server.

Brian:

Okay. Well, the the, the per hour thing is confusing to me. Is it, like, is that just the hours in the month, or is it the hours that it's actually getting used? Does it

Pamela:

Yeah. That's a good question because the postcode server, you can actually stop it. So I actually with one of my apps, I just it's an app that allows people to type in things and then see it translated into 20 languages. It's called translation telephone, and people were typing some horrible things. So I just I shut it down recently while I worked on a better scheme to prevent people from being horrible on the Internet.

Pamela:

But I discovered that I could actually also just stop my Postgres server, and I won't be charged for it.

Brian:

Well, yeah. But I mean, like, let's say I've got, I think I'm gonna have users, but nobody's using it today or Right.

Pamela:

Right. Right.

Brian:

For 12 hours or something like that. Do you do you pay for the that also or because because this is

Pamela:

good question.

Brian:

Maybe this isn't the shouldn't be the focus. But it's not free, but it's not terrible if you're actually gonna make some money.

Pamela:

Yeah. Yeah. I think that's a that's probably a good description. And these and these are good questions. I'm still trying to wrap my head around the pricing.

Pamela:

And I think that's one of the hard things about, about cloud computing is is trying to understand, how the pricing actually actually works. And it depends on the service. Like, with some services, it is, you know, the the amount of time the service is running. Some of them is whether it's actually servicing requests. Some of them also has to do with CPU or memory.

Pamela:

So I need to look into that more.

Brian:

Okay. Well, so that's the, the app, app service. Is there I mean, is that that'd be a good place to start then, do you think?

Pamela:

Yeah. So in terms of options on as your, for Python developers, the things you usually consider are app service, functions, container apps, or Kubernetes service. So app service is our, you know, the thing you'd call a a platform as a service, which does the most for you and is the one is the thing that's recommended if you're doing a standard, you know, website, where you've got users coming to the website, doing stuff on the website, you you know, updating database. You know, functions could work well, you know, serverless. If you, you know, have something that, you know, let me it's a chatbot hitting up a function, you know, then you might use a function.

Pamela:

And then container apps or Kubernetes. Container apps is basically a wrapper for Kubernetes. So we recommend container apps if you're doing a microservice type architecture, but you don't wanna deal with Kubernetes. And then, of course, Kubernetes if you wanna deal with Kubernetes. So if you're doing a Django app, most likely, you're looking at app service.

Brian:

Okay. And so you you mentioned Django and Flask. Yes. Those are very common. But, the upcoming thing is fast API.

Brian:

Can I do fast API and app service?

Pamela:

Yeah. You can. Yeah. So I was actually I almost deployed one this morning on app service. So right now, most of my fast API demos, they do run on functions.

Pamela:

But I was talking with Anthony the other day, and he actually thinks that they might, they might actually work a bit better on app service, just because he he thinks there might be some initial startup time for fast API. So we actually want to do a little comparison with putting a fast API app on app service versus a function Okay. To to see the difference. But, yeah, you could definitely put it on app service. I'll probably put one on app service later today just for just for fun.

Pamela:

And Well,

Brian:

then let me know what you find out.

Pamela:

Yeah. Well, what I should do is put the same one. It's it's actually really easy to switch between the 2.

Brian:

Okay.

Pamela:

Because, they they actually both run on top of similar infrastructure. So when you create them for both of them, you create an app service plan as well. So they are actually both running on fairly similar as your infrastructure.

Brian:

Okay. And one of the things you're looking at right now is your, your GitHub profile. Yeah. That's github.com/pamilofbox. There's there's, like, a ton of little demo things that you've done, and this is pretty cool.

Brian:

These are so these there's got you have Flask. You've got, best API, a whole bunch of stuff, Django even. And there's a column there that's AZD. Mhmm. Now what is that?

Pamela:

So AZD is this, CLI, the Azure developer CLI, and it is actually gonna get renamed fairly soon from what I've heard. And I don't know what the new name is, but it's in it's in preview right now, and I'm I'm a huge fan. I'm like the fan girl on on the team. So that's why you see me making everything AZD compatible. But the point of it is actually to use infrastructure as code in order to define the resources for your resources for your app so that you can then, provision those resources and reliably deploy it.

Pamela:

So it's basically, you know, if you know Terraform, it actually supports Terraform. Right? So Terraform is how you can declare infrastructure as code. Azure also has its own language called Bicep. So I I happen to write Bicep, but I should conceivably learn Terraform as well.

Pamela:

But the point is just to declare, you know, declaratively describe the resources that your that you need on, you know, on the cloud, so that they can be easy to create.

Brian:

Well, Brooke, what do you mean? So let like, the service services, like, you have a services column that is CDN a service that you Yeah. Figure also then?

Pamela:

Yeah. Okay. Yeah. So if we look at, so it's all the resources that you would need for your app. If you so it meant if you were just doing a Flask app on app service and you deployed that, you would only see 2 things in your portal.

Pamela:

You'd see an app service plan and you'd see app service. Those are two resources that you need for an app service app. But then you start to add a database. Right? So then you're gonna see a database, and maybe you're gonna have some logging.

Pamela:

So then you actually see this Log Analytics workspace. So they're all these Azure resources that you mix and match together. And that's something I actually found really different when I came from old school App Engine to Azure. Because with the old school App Engine, the you know, before their their recent stuff, everything was bundled up. So you, you would use the App Engine database, you would use the App Engine Memcache.

Pamela:

It was all bundled and you would just deploy it all in one go. I think these days, App Engine is more of a mix and match, like, like Azure. But that was that was something that was a little tricky for me to understand at first. Like, oh, wait. I have to I have to decide what resources I want, and then I have to put them together.

Brian:

Okay. And

Pamela:

so that I so that can be a little tricky. Right? Because, you know, you're figuring out what you need. Because if you add a database on, then you've got a database. But then, if you wanna, like, make that database secure, like, of course, you should use a good, you know, password and IP protection and all that, but you could also add a virtual network.

Pamela:

So, you know, in my Bicep, I can declare a virtual network. I can declare a private DNS zone. So there's, you know, there's all these things, a CDN. These are, you know, all things that resources that you may want to, may want to bundle with your app. You know, and by having it all declared in infrastructure's code, then you can have repeatable deploys.

Brian:

Okay. So you're showing me the like, a file that's for one of your apps, the domain dot bicep. Mhmm. Is this the easy version? Because this, you said there was a CLI that made it easy.

Brian:

This doesn't look that easy, actually.

Pamela:

Well, it's now that I've written it, all you have to do is type AZD up, and it'll go up. So Oh, yeah. It the thing that's hard is writing the infrastructure's code. And, yeah, we were actually debating this yesterday. Do we expect software developers, you know, like you and me, to be writing Bicep, or writing Terraform?

Pamela:

And that's a good question. I'd actually don't know I don't know how many software developers are are writing those. I find it really empowering now because once I have these BICEF files written, I can, you know, go to any of these apps and just type ACD up, and then I've got it all deployed even if it's, you know, 10 different resources interacting inside of virtual net. Right?

Brian:

Well, that's pretty cool. Yeah. I just, yeah, I'm glad that you have these examples up because if I try this, I might wanna use some of yours examples.

Pamela:

Yeah. So, like, here's an example here, which is this is actually the one I would point you to because this is a Postgres server, that does not have a virtual net. Because you may not you know, it's it's up to you whether you think it's necessary to have virtual net level security because that also is gonna increase your cost. The other thing you could do is, you know, use the most recent Postgres. So should I should be so flick 14, and then, you know, use firewalls to only allow 0IPs or only allow your own IP.

Pamela:

And and that might be secure enough for you. That's your decision to make. But this particular bicep declares a Postgres server with that firewall rule, declares an app service app, and then an app service plan, and an analytics workspace, and that's it. So it's a 100 lines of code. It's already written.

Pamela:

So you could just take this and, you know, make some customizations if you wanna change the Python version, if you wanna change the environment variables, if you wanna change the startup script. Okay. But change those.

Brian:

Okay. But this would, like, do things that connect my, make it so that my app can see my database and things like that.

Pamela:

Yeah. Neat. And,

Brian:

and then there's a AZD up something that can or, you know, the the script formerly known as AZD?

Pamela:

Yeah. So if you just install the Azure developer CLI and then and then you just use the command AZD up, what it does is, it looks at your infrastructure files. It figures out what resources you wanna provision, and it does the provisioning. And it only creates things if they're not there already. Right?

Pamela:

And it updates things if they need updating. And then it will bundle all your code up together, whatever code you tell it to to deploy, and it will actually, you know, upload that to the Azure servers so that your app is ready.

Brian:

Neat. So my code's on my computer. Now it's in the cloud. No. It's not in the cloud yet, or the services are.

Pamela:

Once you do AZ up, it's doing provisioning and deploy.

Brian:

Okay. Now do I do that again when I make changes, like, to my app?

Pamela:

Yeah. You can do you can do AZD up. You can also do AZD deploy. If you know that you haven't changed the info at all, you could just do AZD deploy. And then it's not gonna even, you know, look.

Pamela:

I just do AZD up because I'm lazy, and I know that it's just gonna skip over the resource creation if it's the same. But you can also just do AZD deploy, and that will just do the the deployment stage.

Brian:

Okay. And if I've got, like, database migrations, that's a completely different ball of wax. Right?

Pamela:

Yeah. That's a good question. I was actually talking about database migrations yesterday with with Anthony. So right now, we do that in the startup script so that each time you deploy so here, this is a Flask app. Right?

Pamela:

In the startup script, I run Flask DB upgrade. But I think realistically, if I was doing this in production app, I would probably, I would probably, deploy the new schema. Right? So you always deploy the schema first, not the changes to views. Right?

Pamela:

So deploy the new the new schema, and then go go to the portal page on Azure, go to the SSH, so you can SSH into your app. And then I would probably just run it manually from SSH. That's, I think, what I would do. But, then we we were actually debating what the, like, you know, what the strategies are for for, upgrading. So I'm curious what other people do there.

Brian:

Okay. And I you know, the people listening aren't gonna be able to see the stuff we're looking at, but the individual pieces don't look too terrible, so I'm glad that there's some examples to look at. And I'm sure that there are other places people can find some examples, but we'll we'll link to the your, Flask DB quiz example Mhmm. To look at. So, and so that's pretty cool.

Brian:

So I got my idea. Now it's up. And after I do AZD up, I assume at some point, Microsoft will send me an invoice or I've already set up my, credit card probably with them and everything. So Yeah. It'll it'll be there.

Brian:

But, so what do we need to worry about? And you you mentioned security a little bit. Mhmm. Since I'm gonna assume that I don't know about security. I mean, I I know that it the word, and I that I should care about it.

Brian:

But for like, let's say I'm not I just kinda wanted to stay alive. What's the minimal security that I should care about right do you do you have an opinion?

Pamela:

Yeah. That's a good question. I mean, if you're doing a Django app, you should follow the Django best practices. So you wanna, like, configure the the, you know, the CSRF and the allowed host. So I I always do that in the in the configuration.

Pamela:

Right? So in the configuration, I only allow the host name that's deployed. And you also wanna generate the secret key if you're doing any sort of user login. And, actually, this particular repo doesn't follow that best practice. But you should so on production, you know, setting up the allowed host, setting up the secret key, and, generating those correctly.

Pamela:

So following Django best practices. Right? That's what you should be doing when you have a Django app anywhere. And then, and then the big thing is the database. Right?

Pamela:

So can somebody hack into your database? How secure is it? So, I typically always have SSL mode required, which is good. And then using the most recent version of Postgres 14, that's a good thing to do because it has, some security improvements. And then using a properly random password, so, like, 30 character randomly generated, you know, not password with funny symbols, and then setting up with a firewall.

Pamela:

You know, so that's you you can either set up a firewall or and or a VNet. But if you're, you know, trying to be minimal about it and about cost, then, you know, setting up a firewall so that, you can you can have it so it only allows Azure IPs. So that's that's a pretty good level of security.

Brian:

Okay.

Pamela:

You can watch Anthony has a a great talk I watched, from CitizenCon last year about hacking into Postgres servers using the little hacking tool he wrote. So, you could run that hacking tool and see see if it can get in. Yeah. It tries to get, you know, gets a lot of a lot of passwords. So that's pretty good.

Pamela:

And you could also run these tools in the portal that will give you recommendations on security.

Brian:

Oh, really? Okay.

Pamela:

Yeah. Sometimes I follow them, and sometimes I always follow them.

Brian:

So the, one of the things you brought up with secrets is that I assume there's, like, a secret service that I can use also to store things like passwords and things like that?

Pamela:

Yeah. There is. It's called it's your Key Vault. And so I do use that in in most of my recent stuff that I do. I do use that because it's actually it's pretty cost effective to stuff to put stuff into Key Vault, and there's built in support for app service to grab things out of Key Vault.

Pamela:

So it works really well, to to store secrets into Key Vault.

Brian:

Okay. And then, do you, like, bring it into an environmental variable or something? Or how's that?

Pamela:

Yeah. It's so it's built in that app service has a way of let me see if I can pull it up. But, app service has a way where in your environment variables, you can either type in the value or you can tell it to reference a secret. It's called a secret ref. So, yeah, I have to find it.

Brian:

I love that. But You had, like, a a Azure API key or something like that. That's what and then and any I mean, I think a lot of people that are, so one of the I had to figure this out not too long ago when, setting up deploys from from GitHub to PyPI, for instance. Mhmm. Because you you get your secrets from PyPI, and you stick it in a place in GitHub, and then they know about each other.

Pamela:

Yeah. Yep. So I would recommend Key Vault. Each of the different Azure services have slightly different ways of working with Key Vault, but it's generally, there's generally a good way of storing stuff in KeyVault, because then you can do secret rotation and that sort of stuff. So at the bare minimum, you know, put it in environment variable.

Pamela:

But even nicer is to put it in KeyVault because then, it's it's it's harder to compromise. Right? You you have to go through a fair amount of effort to actually see the value. Right? With an environment variable, you know, it's it's they make it easy to see the values of environment variables because that's something you might wanna look at.

Pamela:

But with a secret, you know, you have to click and say, like, yeah, I really wanna see it. So it's generally better to to store stuff there.

Brian:

Now the you one of the things that I was impressed by is well, I mean, you're kinda in it. You're living it, and you can do things really fast. So how how fast? When you're when you're if you had to, like, come up with a new demo for something, aside from the figuring out how to do it in the first place, how long does it take you to get it live from not live? Like

Pamela:

Yeah. It depends if it's if it's an infrastructure I've done before. So if it's infrastructure I've done before, then it's quite easy. Right? So this weekend, I wanted to make another example of container apps with CDN.

Pamela:

So I made this, API using the API Flask framework that outputs charts using matplotlib. And, and that was actually no. So it basically just took me the weekend. And by the weekend, I mean, just my baby's nap times on the weekend. Right?

Pamela:

Because that's that's what I'm working on stuff. So, and so they're like the infrastructure was our I didn't have to really change the infrastructure at all. It was it was already there. So I was just learning API Flask and, this schema thesis library for testing. So if it's an an existing infrastructure, then it's, you know, it's easy.

Pamela:

I'm just copying over files. If it's a new infrastructure, you know, it depends if there's something that's not straightforward about it, or that's not supported by Bicep or the Azure developer CLI. And there are a few things like that that might be a little complicated. Or, like, I you know, it depends how many service you're involving. So I'm also working on, if you know Django cookie cutter.

Pamela:

Have you seen that?

Brian:

I have not particularly, but I know cookie cutter and Django.

Pamela:

So there there is a Django cookie cutter repo, and it's quite popular. And I am working on adding Azure support to that to see I don't know if they're gonna accept my my change, but, you know, I wanted to see if it was possible. And so that's been the most involved template I've made because that involves, you know, it involves the database, but it also involves, storage for media uploads. It involves, Redis for both the Django cache, you know, decorators, but also for Celery. It has Celery built in.

Pamela:

So that's definitely the most involved template that I've made, and I want it to be really nice. So I'm I'm not done with that yet because I really wanna refine that and make sure I'm using all the service as well. So sometimes, you know, things might take time if it make to to, you know, if I'm trying to, use a lot of services or just really shore it up.

Brian:

And now this might be a dumb question, but in the end, I've got something live. It's got some random IP address or something, I assume. Mhmm. How do I connect to my thing my cool domain name that I registered to Yeah. The live thing?

Pamela:

Yeah. Good question. So I I do I run pamela fox.org, off of Azure, as well as translationtelephone.com. So they're both running off of Azure. So Azure has custom domains, and sometimes I define that in Bicep, but it's actually easier to do that one manually.

Pamela:

So let me see how I set that up. Right. So oh, yeah. So I have my over way over engineered personal website with a 0 container app plus a CDN in front. So I am gonna rewrite this via static web app.

Pamela:

But, so we set that up and then you connect it to a custom domain. So for CDN, the c CDN just has this thing on the left hand side, which is just says custom domains. Right? So each of them, where it makes sense to have a custom domain, there's a way to do it. So it depends what you're connecting to it.

Pamela:

So if you're connecting to the app service directly let me get my app service one up. How did I do that? Custom domains. Yeah. So they both I just go to custom domains on both of them and and set it up.

Pamela:

I think it did take the DNS caching took a long time on pamilafox.org for some reason that might had to do with my particular DNS registrar. If you're doing a whole new domain from scratch, then, you know, that should be fine. But DNS caching can be pretty annoying.

Brian:

Yeah. I mean, like, you know, be patient. It it I've never had it take too long lately. I mean, I've had things. I remember back in the day having to wait till the next day or something like that for things

Pamela:

to show up. I feel like for some reason, Pamela Fox.org took a long it felt like it took a long time. I don't I don't know. Okay.

Brian:

I

Pamela:

don't know. It may be dependent on the browser too. Maybe on you know, we use a pie hole. There there's a lot of things that could be affecting it.

Brian:

But I'm a I'm a impatient person now, so I'll, like, hook hook everything up and then go check it, like, minutes later and go, it's not up yet. What's going on?

Pamela:

Well, maybe it tends to work faster also if it's a brand new domain. Right? Whereas I was trying to repoint it from Google to Azure.

Brian:

Okay. Yeah. Maybe. But, well, neat. Now am I overthinking this?

Brian:

Is or is this kind of the stuff that people should be thinking about? They wanna go live. Is there is there stuff that I haven't thought about?

Pamela:

I mean, so one thing I would do, you know, because you talked about security and that's something you should look into, but also looking into budget. Right? So I would use the pricing calculator. I would also set set up a budget, and that's something I've done on my on my personal account, because, you know, I wanna try stuff out, but I don't wanna be spending a lot of money on my personal account because this is my job. I was supposed to get paid for it, not paid for it.

Pamela:

So in Azure somewhere in Azure, you can set up a budget. So I have a budget of, just $16 a month. So if I ever go over $16 a month, which is, like, a fairly little bar, then I do get a notification, and that's a good reminder for me to go in and check to see what I'm, you know, what I'm spending, you know, spending money on so I can look at the, you know, the charts and, and get a feel for, for the cost. So you can do that pricing calculator ahead of time to try and preemptively not spend too much. But then you should definitely be checking in on that budget because this is real money and be checking to see, you know, how much is it that you are, actually spending.

Brian:

Okay. Interesting. I mean, like, I got like, my database is taking $12 a month already. Right? So Yeah.

Brian:

Yeah. Good. Yeah. Okay. Well, that's that's pretty cool.

Brian:

And I I I I know that you're able to spin things up in a weekend, probably an average human the first time. What am I looking at? Probably, you know, it it's hard to tell, but maybe a week to have, like, couple hours a night working on this, I can maybe get a a site live, or is it gonna take way less than

Pamela:

I I mean, our hope is it takes less than that, but it's a great question. Right? How much how much friction is there? I actually did I did a test, in October where I tried to get a container app going on Amazon, Azure, and Google, and I actually recorded myself the whole time, so that I could share the experiences. Because we wanted to see what the experience was like across them and, like, you know, what where the frictions are everywhere.

Pamela:

Yeah. And and so it you know, roughly, in the end, like, each of them only took me a couple couple hours to get through their, you know, their respective tutorials. But but those were, like, spread over a couple days. Because, you know, sometimes you, like, run into a wall. Right?

Pamela:

Yeah. And you're like, oh, this doesn't make sense. And then you just have to walk away. And then you come back the next day, and it's all okay. Yeah.

Pamela:

Suddenly right? It makes sense.

Brian:

Oh, I didn't see that button there.

Pamela:

Yeah. It's Yeah. Right. So there's, like, how much time it took you of actually doing stuff and then whether, you know, there's something popped up. I mean, one thing you could do, I would probably recommend just doing this, the, there's this article on deploy Python PostgresQL app, to it here.

Pamela:

It's yeah. There we go. Deploy a Django or Flask web app with PostgreSQL and Azure. So I would recommend going through that tutorial first because in theory, this only takes, like, 30 minutes. Okay.

Pamela:

And I actually did just update the the article today. I don't know if it went like it. But, I would recommend going through this tutorial first because it's gonna give you a feel for, you know, parts of the portal and stuff like that. So it's it's a nice, like, gentler introduction before you know, try trying to start with your own app. Your own app has, like, complexities and edge cases.

Pamela:

Right? So you don't wanna deal with the edge cases first.

Brian:

Do a toy zombie first.

Pamela:

Yeah. That's what I would generally recommend with maybe anything is to, you know, to wade into wade into it first with something that is supposed to work.

Brian:

Oh, that's a good idea.

Pamela:

And then and, yeah, and then have a a go, and, and I'm happy to point you at, you know, infrastructure files if that's the route you decide to go.

Brian:

Okay. Now we kinda brush back brush by container, but there are quite a peep few people that are now used to working with containers a lot. So they're even developing their own stuff as a little container on their own machine. And then what does that look like in this situation? Does that mean that that my my Postgres and my Flask and everything is together in one container, or or do I have, like, multiple containers with Flask and or the database in 1?

Brian:

And

Pamela:

Yeah. That's a good question. So with app service, by default, it's just going to get a bundle of your code, and it's gonna take care of setting up containers in the cloud. There is an option for app service called bring your own container.

Brian:

Well, at

Pamela:

least that's what we call it. That's the official name for it. But, there is an option where if you do have you do have a a Docker, image, you can you can point at that Docker image, and then it won't try to do any fancy build. It's just gonna use it's just gonna use your image and throw it on the you know, make container from it. So, so that's another option.

Pamela:

So, you know, if that's something you're into, I don't I don't think it's I don't find it so necessary to do that because it's already a fairly repeatable I found it to be fairly repeatable deploy experience. But if you did wanna have a little more control over you know, because I was saying, like, this build process tries to do the right thing. If you wanted more control over that, then you could just say, like, well, here's my here's my image. It does the right thing. Right?

Brian:

Yeah.

Pamela:

But you would still get all the advantages of the app service scaling. Right? And all, you know, all the all the ways it works that is designed to be good for a user facing website. So that's definitely something to do with containers. The other thing you could do is is your container apps.

Pamela:

So, yeah, so you were asking, like, oh, are you putting everything in one? So if you were doing like an app on Azure container apps that had a Postgres database, I use Docker Compose locally for developing that. But then when I deploy it onto Azure container apps, I'm just deploying the Dockerfile for the Python app, and then I'm having that Docker app communicate with the managed Postgres service from Azure. Okay. Because then I'm getting all the benefits of the fact that the Postgres team has put in a lot of, you know, expertise into running, you know, this, you know, highly redundant available, Postgres in the cloud.

Pamela:

And so I don't have to manage that myself, you you know, and and figure out what that's like. I think you could also if you wanted to, you could alternatively, you know, deploy a Postgres image on, on container apps and communicate with that. I haven't done that myself.

Brian:

Okay.

Pamela:

But it it seems like a possibility, and it's a good question as to

Brian:

I don't know if it's a good question or not. It was just the I don't do these things stay together? Okay.

Pamela:

Yeah. So I tend to use the managed services. No. I know there's people definitely who, because I'm going to giving a talk at the Postgres conference, CitizenCon, and they asked me to specify whether I was gonna talk about the Postgres managed service or about running Postgres on Azure VMs. And I told them I've never done the latter.

Pamela:

So so we're talking about managed service. So I've used the managed service for Postgres, I've used it for Redis, because there's Azure Redis. So I tend to use the managed services, but for all of those, in theory, you could also be deploying, deploying the Postgres image, deploying the Redis image, you know, on container apps or Kubernetes, or even VMs and in using them that way. So I I think it depends on how much SysOps you wanna do.

Brian:

I don't wanna do any. But

Pamela:

Right. Exactly. That's why I use that's why I use managed.

Brian:

Okay. Yeah. I mean, when you brought up Terraform, I'm like, I know that that's a word.

Pamela:

Okay. Good to know.

Brian:

I mean, this

Pamela:

is But I swear it's, like, really cool. So I'm also giving a talk at Python Webcom where I'm gonna be talking about about AZD, but really just about how much I love infrastructure as code. And I yeah. I you're right. I also did not.

Pamela:

I knew Terraform was a word, and I remember interviewing someone when I was, like, CTO of this, chatbot. And and they were talking about Terraform, and I'm thinking to myself, like, I really should learn Terraform. I really should learn Terraform, and I never I never did. But now but now I love it because it's just repeatable deploys. I love repeatable deploys.

Brian:

Yeah. Yeah. That's cool. The okay. And a lot of what we're talking about really is this gap between so I go and somebody has, like, a a tutorial on how to how to do an application in Django or how to do an application with Flask or FastAPI or something.

Brian:

And I go run that, and I go, oh, cool. It's kinda like what I wanna do. So then I go and modify it for the thing I wanna do, and it's running on my local machine. Now go from here to live is this huge it seem feels like a huge hurdle. So, so that's this doesn't look this doesn't feel too terrible now.

Brian:

So thank you. It still feels a little scary. Yeah. But Yep. But not too bad.

Brian:

Cool. Well, thanks a ton. Now I'm gonna I'm gonna hopefully include a bunch of these links if I remember them, in the the show notes and, hopefully get this out soon. So thanks so much for your time today.

Pamela:

Sure. Yeah. I'll send over those links, and if people have questions, you can just toot at me.

Brian:

Toot at you. We'll leave a Mastodon link to for you then as well. Cool. Thanks.

Creators and Guests

Brian Okken
Host
Brian Okken
Software Engineer, also on Python Bytes and Python People podcasts
Pamela Fox
Guest
Pamela Fox
Currently a Principal Cloud Advocate in Python at Microsoft.
199: Is Azure Right for a Side Project? - Pamela Fox
Broadcast by