mergeconflict244 James: [00:00:00] Frank Frank, Frank, Frank, Frank, if there were some more Franks, we would have multiple microservices, a Frank Krieger's all over the world. See how I brought that altogether into the topic that you really wanted to talk about today. Frank. See what I did there. See what I did. Frank: [00:00:24] You did something. I do have a topic I want to talk about, but you used a word I desperately don't like, and kind of kept me away from this topic for a long time. And so now I'm a little freaked out. So I feel like I have to do a little debunking, which I feel like will come back at me and people say, Nope, Frankie road just don't get it. James: [00:00:43] Well, this is really good because. Surprisingly like my team at Microsoft, we've been kind of trying to focus in on specific topics to like, kind of like do an audit and do some PR promotion and things around it. And, and surprisingly, this month I kid you not, you did not know this is microservices. Last month was web API. And this is like internal, like how my team has been working and. And we did like, uh, Jamie and sessile just did this big let's learn event for.net where they like, kind of brought it back to the Oh five one, like, what is a web API? What is rest? Right. All these things. And you brought something to me very early on a second ago, which was, I want to talk about Docker compose, which is, which is like a file of Docker, which is like a very specific thing which most people would say. That bubbles into the world of microservices and microservices is our theme of the month for March, March for microservices. We didn't plan it that way, but until it happened and, um, I've been working with niche on my team. Uh, initially Neil, who's been actively really collaborating on helping people get into microservices because there's a lot of different technology. Out and around microservices and I've demoed it before, but at the same time, I never really understand what's going on. Cause you got, you got Docker, you got like instances, you got containers, you got like Coobernetti's you got like all these things and they're all kind of different, but connected, but. Not necessarily related to each other. So I don't think we're going to talk about all those things, because you just want to talk about a file called the Docker compose file. But I wanted to kind of set it up because I'm actually really excited. I've never been more excited because just coming off of learning a lot about web API, there's sort of a natural fit for microservices and Dockerization and things like this. So I'm really excited about this and I'm pretty sure you probably didn't want. Me to deep dive into the world of all of the things in and around microservices, Frank, but I'm excited about this topic. That's what I'm, that's what I'm trying to. That's what I'm trying to say. Frank, in the last two and a half minutes of me talking, I'm excited to talk about this topic and welcome everyone to merge conflict. This is a podcast where we get really excited to talk about stuff that we're doing in real life. Frank: [00:03:01] Boom. Boom intro complete. Um, I think we'll talk about most of the things that you said, except probably not Coobernetti's because although I have a vague understanding of it, it hasn't like I haven't built anything with it, so I don't want to talk about it because I'm just going to be repeating some promotional stuff. But we are here to talk about Docker and Docker compose. Why James? Why in the world would we talk about them more mobile developers? We're going to talk about them because we keep having to put up websites. We've talked about it in the past for one reason or another, we keep putting up websites, uh, to support our apps, to do whatever, all that stuff. Um, and my current happy spot roughly is. Do.net new, uh, web app or whatever it is, and then upload that somehow to Azure. And that's a really nice, happy place to be. But I do have a background of. Building up sites and servers, and I kind of enjoy it, but the parts of that, that I don't enjoy are maintenance and remembering how to recreate things. And that's why when Docker just Docker came out, I became very interested because w. Well, w w we'll review how you see Docker, but I saw Docker as this wonderful way to recreate machines, uh, that are exactly to my specifications without me having to keep, um, random servers of images and weird virtual machines around. It was an incredibly elegant solution to create a machine with a file. How do you feel about Docker files? James: [00:04:50] Yeah. W w when I think about, you know, Docker images and containerizing applications, I feel exactly the same way. I think the sales pitch of saying, to say, Hey, what we're doing is we're bundling up all of the dependencies that it takes to run your application, including the operating system, right? Including the, whatever the runtimes, everything that you need. And we're bundling that into the small little image. That you can take anywhere with you and you can run it locally. You can run it in Azure, you can run it on Docker. You can run it on AWS. You can run it where you aren't running your own machines or anything that you want to do. And what this means is that you can freely move things around easily without having to have something that's, you know, Pre-built that is going to be out like, this is the thing. Like, if you can run a Docker image, then you can run my application. That's what it, that's what it really says. So the, for the long-term you're not relying on other infrastructure. You are, you are in control of your own infrastructure. And I think that is an important sales pitch to creating microservices. And Dockerizing those microservices. Or just Dockerizing an application, right? A microservice is just, um, to me, a microservice is just a bunch of my services split up into smaller chunks basically instead of having a mega app, you know, you could just have smaller pieces that are deployed separately, but again, you can just have one mega app and it'd be to put that in a Docker image, right. Frank: [00:06:23] Yeah, for sure. Uh, you know, I'm just realizing that a part of this just comes down to packaging of apps kind of. And I always think about how that was always a hangup for me. I was always programming language, curious. I would use all sorts of different systems, but then I would realize whatever app I built in this. I had no idea how to package it up. Like turn it into an exe that, you know, you could give to someone else or sell. Or those kinds of things I, packaging has always been an issue and I like how you phrased all that. Cause it just occurred to me. Yeah. I, I didn't think of it as packaging. Honestly. I thought of it as reproducing a server, uh, quickly being able to spin one up and with the cool clever way they did it. Um, you can recreate dev environments too. So that was. Oh, it's been an issue. I used to be a PHP developer. Can you believe it? And you would never have an identical version of PHP as what was running on the server or, um, well, security things too, but I want to go be on the edge. Docker file now to kind of what you were saying, a web application, right. Is kind of boring as a single server. Technically you can put a million different things on it, but I think we've all learned that a good web application, you kind of split your database from your front end server, or maybe you put a reverse proxy on the front end so that you can do load distribution. It turns out that a single. Website is this complex company of different servers, all communicating with each other. And that was the point in web development where I said, I'm out. This has gotten way too complicated. I am never doing web development ever again. And I think what I love most about Docker compose is it enables me to build those kinds of complex scenarios without being. A dev ops person basically. James: [00:08:36] Yeah, no, I think that, that is a great point. Is that the, the bundling of this application and spinning this up, like normally dev ops is like, I need to also ensure that I have all these dependencies and everything is set up correctly and all these other things are set up are really an elegant, you know, orchestration of doing that. But if you can get it into an image and into a container, um, then you're good to go and I'm using all these words. I'm probably using them. Out of context, because again, earlier I literally was talking to Nish and I was like, I need, I need a website. Like I need a website that says, here are all the parts of the world of microservices. Right. And he's actually working on a new learn module, Microsoft learn module. And this I'm like, I need to understand, like, what is Docker? What is a container? What is an image? What is a file? What are these? What is he? The, all these things, because. Docker is a company and a piece of technology, you know, in, in general, but it's also sort of the basic building blocks of this containerization, uh, technology, I would say. Um, and they have a hub, right? There's and there's hubs and what you store things. But I think what's fascinating is you're right. It's a dev environment. So when you look at that Docker file that you created. Um, you know, which is this, this Docker file, this Docker new script, it literally says, um, please go use, let's say asp.net five, right? It's like, please go use the ASP down at five image or whatever from the internet that Microsoft is hosting and you suck that down. And it's like, okay, like here's the tool chain that I need. To build and run this application and puts it inside of there. And like you said, you could then emulate that to say, Hey, if my application can run, even in a container with these dependencies, I know it's going to run on down at five on it. Six dot whatever version of.net you can have these infinite scrolling of. Configurations of your application to ensure that it's going to run in all those places. And I think you're right, like when it comes to Python, for example, which I learned is fascinating to code in because there are these environments, which to me, these environments were basically Docker images. Like you had, you have a bunch of different versions of Python installed, but you need to have this like little. Instance, it's almost like a clone of, to say, like here, I'm going to run this app in this environment. And to me, that was like, basically I'm running inside of a Docker image and I could be wrong with the terminology, but you know, talking in R Python, which again, just like microservices, I basically know nothing about Python either. Frank: [00:11:19] No, it's fun because I mean, they're, they're similar technology is trying to accomplish the same goal. It's just that, uh, Dr. Docker is the sledgehammer to a pips virtual environment, little hammer, little chisel hammer. So maybe we should take a sec. And go really high level and define some of these terms really quick, just to make some sense of it all. So a container is just this concept of a sandbox, which we're familiar with, um, being mobile app developers, where your code is going to execute and are really. Controlled environment. And it's so controlled that basically there's nothing there to start with and that's called the container and the container creates, uh, um, a new namespace and Lennox parlance that says basically what hardware is available, what things are available. And the default containers are basically nothing's available. You're just a little server. Good luck. Little buddy. So that's all a container is it's just a sandbox and Docker, although it is a trademark hashtag copyright company, it, the concept of a container is somewhat universal. At this point. It's more of an, a, uh, an idea. And so the standard containers out there are these Linux containers, but you can have a windows container. Technically, you could have a Mac container. I think someone's done a mock container. No one uses those. Um, some people use windows containers, but the common ones are Lennox. And what does that mean? Um, it means that they import some version of a Linux kernel to execute a little bit, not necessarily the. Full Colonel because you are running under another operating system, but it's like that the real big revelation that a Docker gave on top of this container concept was that they have the Docker hub that server out there that gives you very easy access to images to execute. James: [00:13:23] Correct. Yeah. So I like that on a website and I'll put a link to this because I'm pretty sure Nish wrote this, but maybe it didn't, but whoever did it, it's great because it really summarizes what you just said in a single sentence really well, because if you didn't know what a container was, I think that this is the ultimate sentence. And then I want you to see if you agree or not Frank, because it's, it's pretty much what you just said, but it's containers combined an app. Plus its configuration and dependencies into a single independently deployable unit. Frank: [00:13:58] Yes. With one caveat I would like to add, but yes, that is an excellent, uh, yes. Paraphrase of everything. I just said, well said, can I go with the James: [00:14:09] caveat? Go for it? Yeah. Frank: [00:14:13] The caveat is one container. Think of it as one server. Although on one actual computer, you could run many containers simultaneously 100%, but conceptually. It's in my mind a server, it's a thing that has some ports. It has an IP address, IP six, IP four. It has a DNS entry. It's a server. Uh, in fact, they're usually called services server services. So the one caveat I would give is that services often need to talk to each other. So you are depending you are bundling all your software dependencies, but you might still have external dependencies that are unsatisfied. James: [00:14:58] Yeah, that's correct. Yeah. That makes sense. Because also you're right. You're you may often be running, like you said, multiple containers, right. And you have multiple apps and an advantage to that, by the way, I think of it as like, this is, there's an advantage to writing. These microservices and putting your apps in containers, because you can do things side by side with other stacks, too. Right? So you could, for example, um, have done it microservices that are mixed with no JS or Java or go, those could be in their own individual containers, or you could have multiple in the same container, right? As long as you're like, I'm going to use this microservice with this Java thing, you could kind of mix these pieces of technology together, or you can really. Like you said, break those down where you might have like a 25 different Python services, but they all might be running different versions of Python. And that's going to be a nightmare to try to manage on a single machine. This sort of gets rid of that problem. Frank: [00:15:54] Yeah, absolutely. And now enter Docker compose. So what Docker compose allows you to do is actually list out all your services, all your servers and reference the Docker file or the image, you know, whatever you could just pull an image straight off of Docker hub or, you know, Microsoft servers, whatever. And then tell it in entry point and environment, a network name and what other services it depends on. So this is getting to that higher level. So if you think of your Docker file in your container as one server, one service, then your Docker compose file, lets you list out all the services and their dependencies on each other. And this is the point James, where I just fell. Absolutely madly in love because this changes everything for how I want it to design websites from now on. Okay. Okay. So let's James: [00:16:50] get this, let's get this right. Cause I've been talking a lot about the Docker file, which is a definition of the applications environment. So it's just say, to say, Hey, this application runs, you know, done at five and it's running this executable, right? Yep. Yeah. And then the Docker compose defines the services that make up your applications so they can run together in and out in this isolated environment. That you've Frank: [00:17:17] yeah. Why don't I give an example of, I would consider this kind of a minimum website Docker compose out there. So these are the services I include. So I have a web service. Which, um, is just called web and it references a Docker file. That includes dotnet core some version of it who knows. So I have a web service. I have a database service and with the simplicity, because you can just download images off of a Docker hub. I can say database, colon image, colon PostgreSQL, colon latest, and through the magic of the internet and 2000. 2116, 2020. I don't know. Whenever this stuff came out, that is so magical. It just goes out there and gets the image, uh, start seeing since then I have another one, um, that I call the backup service, which just from time to time queries, the database server and makes a backup. And then I have one last server. Uh, proxy server, which is an engine X reverse proxy server, which is just doing a little bit of light caching and things like that. And, uh, throttling, you know, those kinds of things. And that again is just an image off of Docker hub. So I don't have, I didn't even have to write a Docker file. I just. Posted one straight off the server and would just those very few lines of code. I have a proper full functioning website with all DNS work in between them. And not only that one, that I can bring up multiple instances of call this a cluster, if we must have been trying to avoid that term. But you know, you're, you're a group of services. You can, uh, bring that up on a dev machine and you can bring that up on a really real server. And I think it's magical. James: [00:19:10] Yes. Um, you are getting into the Coobernetti's of the world. Frank: [00:19:15] We haven't said it yet. I want to see how much longer we can go without bringing it up. James: [00:19:20] It's funny. Cause I, I, I, you know, this is actually a really crazy that you're talking about all this, because last week, last week or two weeks ago, again, talking about niche, um, He really wanted feedback on these week. We, these two online tutorials on the dinette website and there's two tutorials. One is create your first microservice, which literally is doing what you're talking about. So it, you install. Um, it's really nice. You install Docker. Um, on desktop, right? You create your surface. It was like a little web API. Frank: [00:19:53] Uh, it should be clear. I just want to, because I said before Mac Linux, if you install Docker on Mac, it installs a virtual machine so that all the Lennox is work. So it's James: [00:20:04] Oh, also I will tell you this though, on windows. It is a delight because windows has the windows subsystem for Linux, the WSL windows subsystem for Linux and WSL two, which is the latest version, which Docker, desktop, which is the Docker desktop application, lets you kind of deploy and test your images locally. Um, It will automatically configure WSL two for you, which means you don't need hyper V. It is running natively on Linux, on your machine. So there's no emulation in it because it's running. Linux is in there. Frank: [00:20:45] Yeah, it's such magic. I remember back in that day, they've always had the Unix subsystem, but when they got the Linux subsystem, that's when things got really interesting over there, I will say it runs fine on Mac too, but Oh, good. Good for you windows. Well, I James: [00:21:01] would say like, that's the nice thing is like before you had to have hyper V and you had all these other things are fine. It just. Was like more dependencies and more things. And it was kind of a pain if you're a mobile developer, cause you're like, Oh, Android stuff, whatever. But anyways, you run through this and you run it. And then the next step is to deploy that to Azure. And that then creates like a Docker hub thing. You tag your images, you like create a cluster of on EKS, which is an Azure Kubernetes. Services I think, and you know, these are all the words that is still to, to my day. This can explain it to me over and over again. Um, I still don't understand. Um, but one day I hope to Frank that's what, Frank: [00:21:42] well, I want to defend Docker compose just a little bit more before I talk about its difference with Kubernetes, because they are accomplishing roughly the same coal here. Um, I think what the neatest. Part of all of this and they use a similar file format. So all of this applies across all of this is this is like open source software distribution model kind of done, right? Because it's not this weird world I grew up in. You get a new server, you log into it, you change a million config files. You create a backup. Of it in case you ever have to replicate that server and move it over, uh, this world of defining everything in a text file, especially a text file that I can check and to get hub is just been so impressive for me. I think one of the coolest hacks that you can do with it is that you are actually recreating the production environment on your dev machine. So things that I used to run into in the past when making websites is. Uh, like throttling and things where on the production server, I would have a proxy up front that rate limited people. But then in the dev environment, I would never bother, or I wouldn't configure that because it would be too hard to set up in your dev environment. But the neat thing is you create this one little top text file. You go to your command line and you type the words, Docker. Docker compose up. I think that's right. I actually write a script to do most of these things and just the magically that environment is brought up. You might have to futz around a little bit, um, changing, um, port numbers and things like that, but they have a Docker compose override files specifically for. It, uh, creating dev environments, but the knee effect is I no longer have any difference between my production server and the one on my machine. And so I can really actually tune that front end proxy server instead of just taking the defaults like I normally do because it's too hard to test, you know, on production. And so it's really. Transformative in that regard, I'd feel comfortable bringing up multiple servers now where I never did in the past. James: [00:24:03] Nice. Yeah, that makes sense. I think that that is a, a good, good point. What went when, whenever I think more servers, I think more costs too at the same time. Right? Because they're like, I'm getting this environment and that environment, and technically it's really not about the environment anymore. It's about just running and orchestrating these little, little images, little containers. Frank: [00:24:23] Yeah. Okay. So now let's actually talk about servers though, because the way I've been using this is these are just containers running on the same machine. And it's still a good way to break up your code specific where you, like you said, I might have one piece of code running. Dotnet five, another piece of code running mano who knows, you know, and it's just simpler if they live on two different containers. Where a Docker compose is not as good as Coobernetti's and. Yeah, I think, whatever, whatever, isn't there, an open source version of Kubernetes, ma whatever who cares Kubernetes is you can actually say how many machines to devote to these containers, uh, how those machines should be networked together. Uh, how to hot swap one cluster into another cluster. So it's almost like we're just keep building up this hierarchy with Docker files. We start with. The server, the container, but seats surface, I should say the service, the container, then a Docker compose could be how all these services talk to each other. Then Kubernetes is more like here. I have a bunch of machines and I want to describe how to distribute this app over a bunch of machines. I would say, honestly, that. Second Kubernetes step is really not necessary upfront. Uh, a little, uh, little virtual machine running and Azure can handle all these services just fine, but it's nice to know that this technology scales up to that crazy Kubernetes level, if you need it. James: [00:26:04] Yeah, that makes sense to me. Yeah. That makes sense. Interesting. Frank: [00:26:09] I just, I keep stressing the F there because like all of these conversations, everyone jumps to Kubernetes, James, and it's just, it's too complicated, right? It's not too, it's over complicated. You just don't need it under most circumstances. So especially if you're like a indie dev putting up a James: [00:26:32] website, I feel like it's, um, There's there's like basically this jump into the advance right away, because. If at some point you may get there. Right? So it's like, Oh, everyone's talking about Kubernetes. So you've got to learn about the Kubernetes, get out there. And I know that you can also run like a single instance, like there's Azure container instances, I think, which is like, Hey, just go run this thing. But I think that because microservices lend to the point of running multiple at the same time, I think that's why people often go to the Kubernetes as a huge need and need to learn this, like. At the beginning, almost which I think that some is almost too confusing to some developers, AKA myself, because I'm just like, I just learned how to get this one thing and this thing. And then why am I putting this thing into like an Oh an orchestrator thing? Like, I need to understand the full story, which would be, Hey, I want to, you know, Build multiple things and then figure out how they talk to each other. Oh, I got it. I need to put them in this orchestrator thing because I need to know the IP addresses of the other thing. Right. Because if I create a web API and it does 20 things, well, they can all talk to each other because they're all running on the same server. But if. They're in, if they're all independently in 20 different, a little images, then they need to figure out how to communicate with each other. And I think that's where Kubernetes comes in. Is that right? Is that wrong? Frank: [00:28:03] Uh, composed does that also? Okay. Truly all Kubernetes gives you is saying what kind of hardware this stuff is going to run on. Okay. It's it's kind of like, and, and I'm even being a little hesitant because I think Docker compose has a way to run on different hardware also. And you can certainly remote deploy also. So if there's a cluster out there, you can, you know, push yourself up to it. But I think that that is a fundamental part of Docker in fact, is how it handles networking. Hmm, and resolving all those names and things. And certainly it becomes more complicated in Kubernetes where you're dealing with the added abstraction of clusters and being able to move things around like that. So it's really just levels of complexity and orchestra. I don't want to use that word. I don't like that word. Got it into my head. James: [00:28:56] Sorry. I did it. It happened. Frank: [00:28:59] No. Um, but I, I just want to stress that. I think everyone can start out with this small version of it and stay within the small version and really have a lot of fun. I have been doing so much with it, even on places where you wouldn't think I need it. So I'm on raspberry PI, which is usually, you know, it's a simple little computer. You don't need. Advanced orchestration on it. I'm not trying to run services on it, but I still use Docker on it constantly because I get to specify the exact version of.net I want on there. I don't have to worry about it magically updating, or even if I do update the operating system, I know my containers will stout run on it, just fine. A Docker has some other neat things that we haven't talked about, which are volumes, where you can magically just create these volumes and. Docker manages them and you can clone them and copy them around very easily. Things like that. I also use it for training my neuro networks because it turns out every single neural network out there requires a different version of Python and a different version of drivers and this and that. And so far, every single neural network out there that I want to train, I create a Docker file because that is life now in versions. James: [00:30:18] Versions that I think that is what it really ends up solving is aversions all of the versions simplified. Frank: [00:30:27] It's true. It's true. And I've learned lessons over the years, too. Like in my Docker files, I would just install some Python packages like for the neural network. And you would say PIP install, blah, blah, blah. Okay. And then I learned, Oh boy, there's actually not a version there. And although I got lucky building that container one day, I came back to it to build that container again, because the files disappeared, but whatever, it's a text file, I can rebuild it and it failed to build. I had defeated the whole purpose. The whole point of this thing is reliable builds. Over time, over space at different times on different computers, time and space, I guess, and failed the lesson learned there was lock your version numbers down. So instead of saying, I'll take any version greater than 1.0, say, no, I want version 1.0 0.1. It becomes a little more annoying in the future when you. Why not update packages, you have to manually update those versions yourself, but in the long run, um, you need it in order to not to feed yourself so that that package can run for eternity. And I've actually been thinking about that with, um, my.net projects. I'm like, I should lock down all my new guts. This, this whole thing gets into like version lockdown mode. James: [00:31:49] Well, yeah, I was just about to actually bring them talk about it and you get with a version locking because I feel like we install. Um, specific versions of new packages. The dependencies become a little tricky, I think, um, usually because the new guy, maybe that's what you're talking about is like the new Gates we often say, Oh, use version of Newton, soft, Jason, 12 or 10 and above. And then, you know, that's the dependency that it has or whatever like that. Like when we go to install them, we, we pick very specific versions. But I actually wrote the Microsoft learn module on dependencies. And you can do crazy things in your CS proj and define all sorts of mins and maxes and, you know, have it auto select the latest one, which like nobody does, like by default normally. Cause if you use the package installer, it adds a version number, but I have, it's hard. I've. I've used to be a fan of like installing very specific versions of dependencies and things like this. But then with Android, it just becomes a pain in the butt. There's just too many, you know, Frank: [00:32:56] you don't have to do it for all of them. So like for the Android support libraries, which I assume is what you're talking about, because they're terrible. Um, you could do it for everything. Except those. And I, and I kinda like it. I think the default in.net is that they give you the minimum version that they can from the transient dependencies. So if you say 1.0, but you depend on someone who depends on 2.0 yoga, 2.0. You won't get 5.0, that might exist. So that's the default. But like you said, there is like a whole little min-max language you can put into your CS proj to change that behavior. I never do. I think I'm going to change it to be locked at a one specific version. Cause you know, if it's working, it's working, I don't need to update. James: [00:33:44] You do have that problem. Sometimes it's a, it's a bitter bittersweet, you know, balance because. Yeah. If someone then wants to use a newer version, which has a new thing, and then you're like, okay, I've seen a lot of people lock down the major number mostly and just do that like, Oh, I feel good about, Hey, I feel good about you and selling any version of at five. Like in my Docker image. That is done at five and 5.0 dot X. You know what I mean? Maybe I don't feel comfortable with five dot X Dato, you know, as, as doing the, the minor release. So it's sort of that, that, that balance of, of how much do you trust the maintainers to keep that consistency of the API? And this has been a long term, you know, You know thing, but again, if we talk about microservices, then it doesn't really matter because with microservices, you're bundling the entire environment up with very specific version numbers. And it's just going to run by bringing full Frank: [00:34:45] circle, uh, that could introduce security issues. So, you know, open SSL every other month, we got to find a bug in it. So there are things that you should do exactly. Like you said, so you, you brought up a great point. And that's probably what I'll do even more is locked. That major version number. I think most people out there as much as I hate Symantec versioning, I think we all kind of obey it or at least try to obey it. So I think that's a good place to start major, minor, or just major. Oh, I was fighting this Python library, dude. It was, I was stuck on Python version 3.5. But however PIP was working, it kept downloading transient dependencies that require newer versions of Python. So I would just have to run it, see the error, go to a website, scan through their old versions, figure out when they upgraded Python 3.6, find the version before that hard-code that version. And, and repeat that process like 10 times. James: [00:35:51] See, I remember I w the pythons of I was doing the go yeah. Create your little PIP file, and then just put the name of it. Like, I don't even know how to do versions, like, because my Pitt file just has like a bunch of names. I'm like, all right. I guess it's was going to figure it out. Like, I don't even know how that's working. Like, that's the one thing that like, kind of boggled me. I'm like, okay, like, When does, when does it know to update the package? Like when I deployed to my Azure function or like when it's running my Azure function, like, did it cool down and quote within spin back up and it just installed a new dependency or I have no idea. Frank: [00:36:22] Wow. So Azure functions, I would definitely lock the version then. Right. Cause that's very confusing. But then who knows? So like in the case of PIP, their default is the latest version. Yeah. Uh, but for new get their default is the oldest compatible version. So it's funny. The defaults out there. Boy boy, James: [00:36:43] isn't it like in no JS, you can do like a little like up arrow, the little carrot and be like that does something else. I don't even know even. Frank: [00:36:51] Yeah. Yeah. I mean, they all have it. So in Pitt and Python, you use greater than, and less than signs. So it's kinda nice. You say greater than 1.0, less than two point. Oh. And then you're good to go. I think. And, um, CS proj, they use square brackets and parenthesis. To differentiate between min-max inclusive, exclusive. I don't know. It's been a while since I looked at that part. And then yeah, NPM has that up arrow. I have no idea what it means. James: [00:37:21] Nobody does, uh, Frank: [00:37:23] download the internet. That's what that means. An NPM goodness. That James: [00:37:27] is anytime you do anything in NPM. Well, what is your next adventure here? Frank, into the wild wild. Journey that you're on with your new microservices and Dockerization of everything that you do. Frank: [00:37:41] Well, I want to learn how to put it up on the cloud. So what I'm doing right now is old fashioned Frank, I go get a virtual machine and upon that machine I installed Docker. And then I have my own fancy deployment scripts that took me absolutely forever to figure out how to do, because. Modern SSH security. It's so complicated, especially I did it all in get hub action. So anyway, long story short, I want to learn how to deploy this stuff to the cloud, which means I actually have to properly learn Kubernetes and how to define one of those clusters. Um, wish me luck. I really liked Dr. Compose. I really don't want to learn Kubernetes. But pretty much every cloud service out there talks Kubernetes. So that's lingua franca. James: [00:38:31] Yeah. You gotta, you have to do it at some point. I feel like that's the, that's the plan? Frank: [00:38:37] Uh, so more learning. Well, will we ever do a Kubernetes episode? I don't think you'll let me, James: [00:38:45] yeah, we can do on ones once. I know how it works. All tasks. I need to, I need to go niche. I actually wrote a bunch of learn modules and things like that. I need to go take them and then learn the concepts. Cause I do think it applies really heavily to mobile development. Like we've been saying, but also like all sorts of different development that you could be doing. So, and the more like I took the step into functions, I mean, I, I sort of th I thought of functions as. In enter, it's like a gateway into microservices because you're deploying bits of code that are magically being run on a server over here. And, but in this next step, it's like, you're bundling everything up into, into this image, right. Instead of just deploying your little code file up into the Azure function that has its own runtime and figure stuff out. And you're like, Oh, here's everything in general. So, um, It's nice in that regard, because again, you're not relying on a service because of Azure functions is like, Hey, we're no longer going to support Donnet whatever done a core, one O or something like that. I don't know. Then I don't know how that works. I don't know how that works. I have no idea. Frank: [00:39:52] Yeah, I think that's why we all like images because we don't have to worry about how that works. The idea is just go download a bunch of this code and then it works. I think functions are nice. Like good. They are a high level. And if you can get away with it, Working at a high level, you absolutely should. No one wants to work with servers. I should preface it all this by saying, I don't want to work with servers. This is just making it much easier than it used to be. If I could get away with just, um, some functions, I would. Absolutely. Yeah, yeah. James: [00:40:28] In a world where only functions existed. All right. Well, I think it's going to do it for our micro service. I would say like we're, tippy-toeing into the, the microservices and Docker waters. Definitely excited to see what our listeners. Um, our end to end this topic, definitely give us some feedback on a merge conflict at FM, and you can write us an email. You can ping us on Twitter having our discord or anything like that. That'd be super awesome. You'd also become a Patrion supporter. If you go over to merge conflicts out FM, there's a patriotic button up top and, uh, you can support us. We release exclusive episodes every single week. They're like kind of top of mind, just random Chitty chatter of. Stuff, just a random chatter is what we do. And it's quite fun this week, we talked about the DJI FPV drone, um, which is quite entertaining as well. You can, again, had to merge conflict at FM, become one of our supporters or just, you know, leave us some feedback. We would like it, but that's going to do for this week's merge conflicts. So until next time. Hi, I'm James Montana back now. And Frank: [00:41:26] I'm Frank Krueger. Thanks for Lou peace.