How'd you like to listen to dot net rocks with no ads? Easy? Become a patron For just five dollars a month you get access to a private RSS feed where all the shows have no ADS. Twenty dollars a month will get you that and a special dot net Rocks patron mug. Sign up now at Patreon dot dot net rocks dot com. Hey Carlin, Richard Here, as you may have heard, NDC is back offering their incredible in person conferences around the world, and we'd like to tell you about them. NDC Oslow
will be made twenty first through the twenty fifth. Go to NDC Oslo dot com to register. NDC Copenhagen is happening August twenty seventh through the thirty first. Go to NDC Copenhagen dot com for more information. NDC Porto is happening October sixteenth through the twentieth. The early bird discount for DC Porto ends July twenty first. Go to Eddcporto dot com to register and check out the full lineup of conferences at DC conferences dot com. Hey, welcome back to dot
net and Rocks. This is Carl Franklin and this is Richard camp in our respective hiding holes for the moment, at least, trying to bear this crazy winter that finally showed up. Would you get a cold one too, dude? Oh yeah, we had a We had a cold snap hair nice and it's just coming out of it now. We got a foot and a half of snow overnight. You're crazy. I know, what do you guys do in snow? You don't have snow. We don't have snow. No, No, you have rain. You know. We got out there, We
got out there and shoveled. Yeah, that would have been a perfectly fine evening rainfall, but nope, it turned into white stuff and stuck. So you actually have snow shovels. They sell them. Oh yeah, are their plows? Yeah, not very many. No, it took it took twenty four hours for the cold decide to get blowed. It's funny. The West coast and the south typically of you know, of North America don't typically get
snow, and they're they're like, what is this. I was in Pasadena when it held on them earlier this week and everyone was just in shocky. Whoa what was that sound? Oh that was Brian Foster. I'm sorry. Go ahead, Richard, But even if it rains in Los Angeles. The responses, as near as I can tell, when you see rain, get in your car, taking the highway and park it. Yeah yeah, all right, enough of this small talk. Let's get right into it with better
know framework. Awesome. Alright, man, what do you got? Well, it's a new story no longer the new ie apples Safari sixteen point four to bring a hundred and thirty five new features. What the I know?
Well, I just loved that somebody else is using my line. Yeah, well, I think some they must listen to this show, The New I E. Because not only did they say all of this stuff, but they said the likely reason for Apple's hesitancy over implementing web technology is that it helps to ensure that apps for iOS are delivered by the App Store, a major profit center for the company. See somebody else gets it too. But some of these I'll just tell you what the features are Web push notifications. That's
big. So for progressive web apps, we can have notifications even on the Apple Watch. How about that. Wow, that is a big deal. That's a huge deal. That means that progressive web applications are actually viable again, remember I was just lamenting that a while ago, just broken shadow doom meaning scope CSS, nice support for lazy loading I frames, new jobscript features like import maps, web assembly, SIMD support, and numerous web animation features
and fixes. And they go into detail in this article about each one of those things. So it sounds like a big catch up about freaking time. Yeah, big gold catch up. Yeah. And they also say that the shift may have to do with the new legislation that the EU Digital Markets Act potentially impacts Apple policies. But even so, I think I hope the non cynical knee hopes that they just came to their senses and said, you know, we don't want to be the new ie. So maybe they were listening
to you, Richard and me and got a hint. Yeah, maybe I got the hint. But you know, somebody finally said we should just keep up with standards like it's not helping anybody in the end, right at best, you know, Apple's already got their walled garden effect where each other's their products work really well with each other more so than anything else. Right, you don't have to be more difficult than that, right, please please? So anyway, I'm really happy about this news and you learn it, love
it. Who's talking to us, Richard? Yeah, grabbed a comments off a show seventeen nine, which you did back in April twenty two with our friend Chris Kluge. Yeah, we were talking when he was comparing all the different infrastructure as code strategies, and that of course naturally led into a DevOps and a pipeline sort of conversation with the tooling, and I thought it would tie in nicely with our conversation today. But this comment comes from Devin Gobel.
It's just back in May of twenty two. He made his comment where he said, my hot take on DevOps is that too many practitioners start off with rigid, preconceived notions of what they want to do. This is normal. Our decision making is always going to be shaped by our scars, remember that. Yeah. Yeah. However, it helps to approach DAVOPS technology as any technology was an open mind. Start by looking for whether or not the out of box functionality is sufficient, and if not, why, Here's my
favorite line, are the scars running the show? He'll love? That is all pain holding you back? Yeah, it's all pain dictating the plan. Right, There's always going to be some amount of custom work that needs to be done. But if our first step is always to start by figuring out how to get the pipeline to run a cosh some Bash or PowerShell script, you're probably doing it wrong. Yeah, you aren't that special, Yeah right. If the can features can get you most, if not all the way
there, start with those. They are almost always going to provide decent airror handling, logging, and parameter checking, especially if their first party offerings. Keep in mind that there's going to be some differences between greenfield projects to lift and shift that might still require some extra work. I like to think about
it. For most any cloud project, if step one is to create an Azure VM and it's all sequel server, you're going down the wrong path, right, fair enough, Devin. I appreciate you thinking, and I think we're all in violent agreement with you. Actually absolutely. You know you don't
want one hundred percent. One hundred percent is unlikely, but eighty percent is a given right, and so you know, find the eighty percent and then at least see that there's enough for room to do the customizations you need to do, and that the customizations aren't going to punish you for the rest of your life in the process. So thanks so much for your commented. A copy of music go by, it's on its way to you. And if you'd like a copy of music, go buy, write a comment on the
website at dot at Rocks dot com or on the facebooks. We publish every show there and if you comment there and I read it on the show, we'll send you a copy. Mused to go buy. Yeah, the facebooks, like like you get that at Walmart's. Yes, it's like mom speak by going through the internet tubes, the internets. Yes. Yeah. So by the way, Mastodon is where somebody tuted me about this new stuff in coming in Safari. You got tuted? How about that? I got tuted?
Man? So yeah, I'm enjoying my tutors, the my followers on Mastodon a lot. There's a lot more engagement down on Twitter. So you should follow us on Mastodon. I'm at Carl Franklin at tech hub dot social and I'm Rich Campbell at mastodon dot social and send us it too, because you know, sometimes that's how we learn things that we talk about on the show. All right, you heard him before, chime in there, but
let me formally introduce Brian. Brian Foster currently works at Microsoft as a senior Cloud solutions architect and a mentor for the Microsoft Founders Hub, which we definitely have to talk about. His career started as a full stack dot NEM engineer and grew too various leadership roles from team lead to CTO. Brian found a
passion for building teams and cultures that focus on cultivating developer velocity. He loves the development community and appreciates how it has helped his career over the years, so he decided to give back by co founding the Salt Lake Azure Group in twenty eighteen. When Brian's not coding, you can find him either in his wood shop or in the mountains trying to hide from the cell service. Oh don't we all need that once in a while. Sometimes it's some long hikes.
Yeah, well, welcome to the show, Brian, Thank you, thank you for having me. You bet. Yeah. What is this micro
Soft Founders Hub. That's an intriguing name. Yeah, it's a program Microsoft started to kind of just help startups embrace technology and to give them the advantage to start and not to be held back from technology because it can be a kind of daunting experience, daunting the learning curve to get into, especially if you're non technical startup and so us as employees and Microsoft, we've been given the opportunity to volunteer and kind of ment toward those and it really comes down
some awesome conversations. Rarely are technology driven in that sense, but more just how do we how do you swim through this lane of technology? Yeah? I could. That's good. So, yeah, I appreciate that, especially for non techie people who are starting companies. That's a that's a great service. It's kind of fun to talk to those clients and kind of foreshadow what's happening, what's coming down the road. You know. We had some big
things coming with chat GPT recently. I don't know if you guys have heard of that. Yeah, maybe you've heard of it. Yeah, I'm probably honestly the only human being in the world that hasn't actually used it yet. I was using yesterday. Yeah, it didn't help, but it tried really hard, but it's information was too old. Yeah, And so it gives those people understanding what to take the proper steps moving forward, what's the next best step it's going to outlast for a while and I have to come back.
You know, we talked about those scars in that comment, and you know that I always relate to the pain driven development. Yeah, and you know why why self inflicts some of those pains and those scars if you don't have to. But so they give you resources from Azure, They give you Azure credits along as referent with these knowledge experts. They give you credits through
GitHub and partnerships we have with Microsoft as well. So utilizing some of those SaaS offerings to just give you that edge that normally you probably wouldn't think of as a startup, but to then take advantage of that and go, hey, here's some new possibilities. Wasn't there a program called biz Spark that was like this Yeah yeah, yeah, that was kind of like the start of where this is at. So it's like the great grandfather of this program.
Okay, yeah, this park was the old way and now there's a new way. Yeah. And they have it in like a tiered setup. So if you're just kind of like an ideation of a startup, you can apply up to almost going to production so to speak, and you know, right before you get your funding or going public. So you have these different tiers, and each tier correlates with the larger cost for Azure credits, the larger headcount for geth hub dynamics through sixty five, and there's CRM services and so
you really we it's that journey. I think a lot of people, you know, as you get into cloud, it's a learning journey. And we hold that startup and help those startup founders go through that whole process from just ideas and where you go to actually implementing those ideas into the cloud and what technologies to use and how to best you know, solution their products. So
you're not even necessarily looking for technology people at all. Just if you want to start a business, they could be talking about Yeah, yeah, I worked with a company in Atlanta startup and really what they did is help people
consume remote work. Since covid started, you know, you have a lot of people that don't even know where to start, right, and so they came up with packages and kind of tutorials how do you even get going, how to set up microphones, what quality of microphones and web cameras and laptops and certain programs and where they sit and a lot of that conversations we had with them is how to scale out, how to handle scale because they can't
do it by myself. And so you talked about a little bit of technology how we could scale out and their offerings digitally and things like that. So I enjoy because it's the human aspect of technology or I think it really brings that spice of life to our field. Yeah, and then innovation aspect. So you mentioned in your bio the word velocity. What does that actually mean to you? Well, for one, it does not mean judging developers work
during their sprint. K lox is not a good measure of develop Yeah, you know that was one thing when everyone's like we're gonna make sure everyone's programming fast and they're they're hitting X, y Z, and I'm like it that you can't do that. It's hard, you know, humans hearts. Sometimes
you're working on harder projects than easier projects and you make more progress. To me a developer, velocity is how to get you how do you get your ideations into the cloud faster or into for wuistion, And what I mean by that is, you know you always have those like kind of water cooler talks and those that have been in departments for a while, I'm like, Oh, it'd be really cool to do idea X, y Z, but how
do we get started? And there's certain roadblocks built into the corporation or just through the history of how we handle it infrastructure and development, to where you know, maybe you can't get to those resources allocated quick enough, and that kind of idea and then inspiration kind of passes by because life moves on, work comes, more paying drim developments coming, and you lose that party.
So I look at it, how do I get a developer from whether it be new or into the company to produce code and be productible member of society. In our department, just getting someone set up that's new to the team to a point where they can check a bit of code in and it actually shows up in the system often is not a trivial problem, like no, unless you've really worked on it. Like I've seen organizations get to a point where it's like, in a matter of hours, we can build out a
dev box and have you able to check code in. But you have to have spent time building that to make that that quick. And I've spent a lot of time doing that myself as well where that's what's kind of spiked these interests like how can I simplify this, make it faster but yet flexible, you know, I think that's a key. Two's a lot of these earlier day situations are very confined and how we do it like this is your image,
this is how you program good luck. But we know as software is coming out every week and new releases, we have to kind of stay updated with that too, So you have to have that flexibility of keeping that environment moving forward with progression. You do, have you noticed intimidation or imposter syndrome those kinds of psychological things holding people back when you know they can if they just relaxed and you know, head down, figure some things out, and
and everything will be okay. I think one hundred percent. I think honestly, we all face I've faced it myself with almost every new position I've gotten, because as humans, you don't want to fail. You know, we seem to look down at that in a negative sense. You know, we come with compensation from our employment and you're like, man, if I, you know, don't succeed here, do I can I really justify that compensation? Like it almost is outside of the development realm, and so I think
it's you know, to set up a safe area for developers. It's it's key in leadership to be able to say, hey, look we have this built in a way where you can go and make mistakes and we're not going to be mad about it. We also set up where we're not going to be hard about it. Yeah, that's pretty hard to fail and learn from it. Yeah, you have to, yeah, you know. And there's
that statement quick to fill. I like to kind of modify and say quick to fill smartly, like, let's assess what we're going into, let's as set uh you know, where our code is, how we're going to deploy, if we're going to deploy, and be prepared for any of the negative outcomes. Quick to recover from failure. Yeah yeah, yeah. In fact that I think it's a better policy because when when the cost of failure is really low, you'll be more experimental, Like you'll move faster because the breaking
things part's not that big of a deal, right yeah. Yeah. And you know modern data velment too, a lot of it is focused in the cloud, you know, whatever cloud provider you're using, and so a lot of us uh, you know, you come into cloud your first From my experience and from what I've seen from a lot of engineers, their first experience getting in the cloud is through the portal, like through the web UI and you're clicking on things and dragon and they do like as you're specifically, does
a fantastic job of building a UX where it's even if you're not an infrastructure knowledgeable person, you can build out app services or as your functions decently quick and kind of know what's going on. They have a great breadcrumbing through menu you to go through and to build that out. But it's same time, it's human interaction and what are one thing that humans are really good at?
Or just making mistakes because it happens, you know. I always love how Microsoft's like oh were the elasticity in the cloud of being able to scale up and scale down and set those scales is so easy. Like it is, but it's also really easy to scale all the way up to the highest level price skew and forget about it through the week and let it run through the weekend and go don't worry, I'll find out. You'll find out at about
it soon. And I know a little about that. Yeah, thirty days later, they're like, hey, what's you know, a company comes to you and goes, what's this bill, and you're like, I have no idea. Let me go find out. Why do I owe twenty thousand dollars
this month? Yeah? Yeah, that's my backdoor cryptomoney. Yeah, but you know, and that could be scary for our new employees, right if you're new to the company, say six months, and you do something like that, and they're coming back like, hey, here's this cost, it's just scary. A lot of those new newcomers are young in the field as well, and so they don't even necessarily have that experience of making those mistakes. And I think that's even a steeper threshold of right, so you spend
a bit of time teaching cloud governance ide that. Yeah, yeah, I think that cloud governance too expands more just from the developer. I mean, Richard, I know, with your background and managing hardware and IT, you know, in enterprise levels, that's kind of a fight against developers and IT management. Sometimes. I've seen some companies where I stick with that mindset. I mean, I'd never blame a developer for the fact that they were able
to leave a bunch of infrastructure on that they didn't need. That's on it, you know, infrastructure versus possible Yeah, right, they that should have been caught and cleaned up. Yeah, and it. But that's also I don't want them to be afraid, Like I want them to have the confidence of go ahead, fire up as much stuff as you want, you know, but you're gonna have to fight hard to keep it alive more than the end of today. Yeah, Like that should be the hard part is leaving
stuff on, not leaving stuff off. Yeah, And I think that's the natural evolution to of like infrastructure's code as that started to come out. You know, back to the comments about all the different offerings. You know, we even as those that manage the cloud, they don't want to manually bring
up storage accounts and vms and virtual networks for every request. I've seen that where we've had enterprise companies, large companies where you talk to the developers about building out this idea of this project, this innovation, my air quotes here, this application innovation, and they're like, well that's great, but I need to throw a note over to it to build out this infrastructure. And
that's a two week turnaround and then we'll have access to it. You're like, oh man, well, because it used to be a nine month turnaround, like it is, feeling pretty good about me deliver that in two weeks when? And the reality is it should be a minute. Yeah, right, there has to be self service. Well, you think of the price. If you've heard de priatories your daily work tasks and what you want to do doing up resources in the cloud for people's requests, I'm sure probably bottom
on your list of doing that day in and day out. And if you could take that ten percent of repetitiveness and automate that, you can now stack that free ten percent on top of your priority list and start working on things that will drive business value for your department or for your role or responsibilities. Is they're tooling around that whole self service idea. There's some tooling. We
are starting to formalize some of those toolings. You know, you talk about infrastructure's code and run it through saying like an as your CLI or starting to run it in cic D. But it's still kind of fragmented amongst the teams, right, it's you know, someone always seems to control it and because
they know it. I think that's one thing that's kind of key in this devop side is you get certain people to kind of overlap responsibilities because they're like, I need to know a little bit about cic D for my development, so I'm going to learn infrastructure's code. Infrastructure code starts to dip into knowing infrastructure, which now I need to bring in my people. Right, So
there's a little bit of fragmentation there. But Microsoft is done really well and they've actually recently released a new resource, a new concept in the cloud called as Your Deployment Environments And this kind of encapsulates all those theories, methodologies, and process and tooling to automate these processes and to actually join those developers, developer manager and the IT management teams together, because I think that's huge in
the culture as well of even DevOps being successful and development teams being Succesful's communication. Let us all know, we're all on the same team here, So how do we work together, how do we evolve together and bring that business value? And so you know, and as your Deployment Environments is fantastic.
It's it's a concept the specific resources that come into the cloud. It's called the dev center, and that dev center is where you can come in and you can kind of manage the infrastructure's code what we call catalogs, and that
contains all the infrastructure's code for these specific projects. And then on top of that, you can manage that certain environments as they're going to because on top of me and making sure you're in the proper virtual networks, you need to worry about that the people that are in them are authorized to use those resources.
Right. You know, from your various environments of development to QA to staging, you're going to have various roles that are going to need different permissions, and potentially you don't want the developer into the QA environment or don't want anyone in the staging environment because you want to keep that, you know, its own thing. Make sure what's going out in production is what's going on.
Protections. I'm modified from the single source of truth of the you know CICD, those pipelines being built, and so in dev Center you can set up those environments and then you can set those r back permissions and who has availability for those and so then what you can do from a dev manager perspective
is you can execute these environments to build out the sandbox environments automatically. One thing we see in deployment procedures is you branch from features of your projects, so you could have multiply dozens of projects going on at once for that same core application, you know, different features or wims. When that bug, you know bug and production hits it Tuesday at two o'clock in the afternoon, it needs to be fixed asap, we halt all work, right and they're
like, okay, let's focus on this bug fix. Let's get it back into production. The dev center gives you that ability to scaffo out a whole environment for that bug fix, fix it deploy you know, down near your cic D is staging, as well as bringing that bugfix down in the code repositories for your say, your dev environments, because it's going to need that updated code, and so you have a lot of agility there in those environments.
You're not sitting there personally building out as your infrastructure, you know, by hand, you're setting up resources and functions and app services and whatnot. So we have that automated process. Sounds just like the natural evolution of source control to me. Yeah, yeah, And it's more onlike the infrastructure side of the infrastructure side. Yeah, now, and you would be feeding these deployment environments from get hub actions. Yes, you can get hub actions there.
These infrastructure's code files are stored in a code repository, whether it be gethhub or as your DevOps, and we have a manifest file inside the structure that kind of points out what files belong and kind of gives it some order. And that's how the dev center is, you know, recognizing these files
and that structure. But you know, behind an azure and that control plane, as we know, everything is spoken to that ARM level at as your resource manager level in those files, and so whether you're running it from the cic D process or as your CLI, it's always going to go through that layer. And you know, currently we only support ARMED templates. But this
is a public preview resource that just came out in October. But we're we're looking at aiming at terraform of being kind of a first class citizen as well. Okay, great, So it's kind of exciting, and we're encompassing all flavors of infrastructure's code, you know those popular flavors. Pullum me too, I guess is on that list. Yeah, bring everyone in too, you know, welcome to the cloud. I guess to say, you know, yeah, we're not the Microsoft of old. Yes, that's true. Yeah.
And when I when I hear azure ARM, I think BICEP. These days, I as well, I rarely type in Jason Arm, you know what we had back in the day, usually SPICEP, which I feel like is a good middle person between ARM and Terraform. I stick to bicep, man because all of my work is in Azure and so that's just a personal decision of mine. But yeah, Terraform will still quickly become a first classes
one's gas later this year. Yeah, I think a BICEP, mostly because I know the listeners are programmers and BICEP is more programmy and less um yamily. Shall we say? Yeah, no one liked the amial said no one ever? I like you almost said no one, right, there's your quote, But yeah, Biseet, Like when Infrastructure's code started years ago, as a developer, you quickly kind of get into that object oriented mindset of like, oh, I want to build out a lot of functions. How do
I build out multiple functions? You know, before there was looping and those type of things. You're like, well, you have to have a separate function file. You recall the file multiple times, so you always had to kind of introduce scripting into that sense as well. But now you know breaking
out your modules. We kind of call it like a bifurcated infrastructure repository, where in a sense, before deav center, you could have a repository that stored your infrastructure i AC files for networking, for VMS and kind of bring out to that sandbox guardrails and then you know, maybe a generic app service. But then a project itself, as a developer is working on it may have infrastructures code files for their particular function or app service and the details that
go into that. Maybe it's a certain tails setting, custom domains, type configuration, auto scale rules you know, we'll have you know, autoscale rules specifically could be different for every app service, right, so why would you want to maintain that from like a core spot where it's the same across the board. You want that flexibility, and so you can have those inside each
project's repository. And then when your cic D starts to execute and you're starting to release this code, you bring in the big building blocks from your management I REPO, and you bring in the building blocks from the project I see, and combine those two together to then build out to that infrastructure if necessary. So you have both plane at hand, right, You have your infrastructure management plane at hand as well as the developer's agility plane at hand. Here
for that success. Because even I, as a developer, I get over my skis really quick when it comes to infrastructure and making sure everything is secure and where we need to go. You know, I really want to focus on the code and on the application at the same time. We can't just have our blinders on and just say I'm coding, I'm deploying. It works on my machine, let me continue going, right. That's the statement of two thousand and two. It works on my machine, right and before that.
Yeah, But it feels to me like most evs would be able to take a branch, do some modify, do their work, get it running on their machine, merge to the branch, somebody else picks up the PR as soon as that PR happens to get hub action kicks off, and now it's up in the pipeline, sitting in the deployment environment waiting for the next
step. Essentially pretty much qa's now going to take it out for a spin, maybe do their own set of tests so far, or it's ready to go to staging and then and somebody else is going to push it into production. Yeah. And that's the thing is like, once your build the code and ready to deploy, the question is where are you deploying it? Where is it going to sit in the cloud? Are we going to manly build out those infrastrues you know those environments for QUA good deesos. You wouldn't want
to get hob action just pushes to the production app service. I mean, who would do that? Nobody does that? Did you skip the whole pull request part? You just simply pushed a master? Is that what you did? Okay? I just opened a visual students said right click deploy. So I worked on a project where it was a requirement to have a pull request that had to be approved by a guy who only worked on the project three days a week. Oh boy, And they wondered why I was going so
slow? Yeah, yeah, yeah, especially if he's on vacation or you know, it gets hit by a bus. You're in a hard, tough situation. Yeah, it was tough. And then they finally said no, just go ahead and just forget that. We're going to remove that request to remove that block. Well, and to me, it's not even that, it's that you didn't get the code out there like gaff. Now you're gonna work on several other things before any of that stuff gets checked in. It
just makes merge merging terrible. Merging gets terrible, and if there is a problem, it's out of your head. Yeah, right, like you got to start over basically, Yeah, it wasn't fun. And folks, before we continue, I've got some very important messages to share. And we're back. It's Don and Rocks. I'm Richard Canaball. That's Carl Franklin Woo too. Talking to our friend Brian Foster a bit about this idea of development velocity
as a as a metric around DevOps like keeping folks that aerating fast. I mentioned just before the break there, this whole idea of like, I want that code you just worked on still in your head, so as soon as I can get problems back to you the quicker, they're going to be able to fix them. Yeah. Yeah, I think that that agility is key, right, That's where the innovation comes from, is that being able to
to be nimble and to test these type of concepts too. I know you had a previous guest on Tom Kirkhov who talked about API M and part of his conversation talked about how you're LOWD testing and this is kind of a scenic tour, but as you're load testing, is a fantastic resources come out to start doing that edge testing quicker at load right, Right's nothing like building something.
I've been there, you know, you follow say Anity frameworks, Hello World tutorials and you kind of start building that out and you're interacting with your data and it works, and when you go into production, all of a sudden, at volume, it just kind of blows up on you. And there's no way to mimic production environments on a local machine, let alone in
like a dev environment. And with resource like as you're load testing, you can throw all kinds of instance engines at it and get to that production level volume coming through. Yeah, so those slight cynic route it's still kind of allow lines with that velocity right to get that feedback and that data back to understand, hey, are we ready to go to production? Did we handle
this properly? Sure? It's kind of key there, I mean, and there's load test of failure, but there's also load tests to performance or load test of requirements. You know. For me, again wearing my IT hat,
it's like, I don't care that the apps now slower. I care that I've provision enough for Saturday, and so running it through the load tester to compare last week's version of this week's version at least tells me I need a provision ten percent more to get the same overall support for the previous week. And you don't want to find that out in production either, the site stepping over because we didn't provisions sufficiently. Yeah, what's always Dave, the
coder's fault. When that happens everything you do. That's become the running joke in my house anytime technology doesn't work, My wife and I say, I blame the programmers. Yeah, yeah, we call them George George, George the developer. But I think another flexibility perspective too of asure deployment environments in this dev center is handling the various environments of a development department within a company.
Right, whether you are a small company it was say a solo dev or a small team of devs that are ready just to build on their laptops and kind of work from their machines and program to remote workers. Because then you bring in another security aspect there is you have people off premise connecting into your infrastructure, connecting into your codebase that are working on these things, which
I'm sure set off some red flags and red alarts for people. And then you have you know, offshore development, contract development, where how do you know on board these people for these various projects quickly so they can start working towards it. And then what happens when they leave? You know, you don't want to necessary that code running on their machine and they go, Hi,
see you later, Richard. I quit on a Tuesday, and I just started all your proprietary knowledge there right and that code and so dev Center, with the combination of another attribute called a resource called as your dev box, plays a big part in this velocity. It's kind of just another brick
on the stack here to increase the velocity. Dev Box is something as well has come out recently over the last year and is in still public preview, but is an environment for a virtual environment for developers focused on the developer long lasting state in sense of working on that project. You know, you can customize that image for your development environment. So whether you're using visual Studio or
using some jet Brains products certain lines. I think that's key. When when we talk about, you know, worked on my machine, it usually comes down to, you know, different MPM versions or different framework versions, right, and someone's machine just randomly updates because you're like, oh, yeah,
accept all updates and make my machine the best it can be. And then all of sudden, all the projects break because now you have, you know, newer versions of these libraries, and so now you can have like that consistent developer environment across the board for specific features. You know, maybe you have a project you're working on where you're starting to update these libraries, but again that bug scenario comes in and you're like, oh, I need to
work on this bug. What are the current steps? Now current it's like, well, let me re license knocked down the versions of these frameworks, or let me pull out a whole nother repository and kind of retweet my machine. Now we don't have to necessarily do that because we have these dev boxes and in the middle ground between that it's been containers. I mean, I
would be a fool not to bring in containers. You know, every project should be in a container in my opinion, Yeah, because it helps alleviate this scenario we're talking about, right, how onboard a new dev how to get various developers machines running this project. You know you use a container, but that's at the project level, and so how do we expand that? So you're talking about a container for the dev environment, Well, not necessari
for the dev environment, but for their codebase. Sorry, so for container on the project. Yeah, you know, before containers, we had those visioning issues all the time, and I think it ran on my machine was more of a bold statement and very common. Then we bring in containers to the project to kind of alleviate that issue right to where I can run on my Mac, you could run on your Windows machine and we can build the same project because it's based out of that container. To me, the container
has really brought the manifest mindset. It catalyzed as opposed to petized the workloads right that we're used to just generating the workload from scratch. Again, remake this machine not CATALYZEDATA, but cattle at Las, cattle not pets. Yeah, we said at all time Yeah, treats your infrastructure like cattle, not pets. No, no pretty naming, yeah, kill it well, kill it and recreated on demand, right, so that you know that the infrastructure
is code. The manifest of the container is the source of truth because there's nothing you in there anymore when you restarted. But I think it's very different from like if I wrong. Dev box is virtual desktop configured for developers. No, you're you're kind of spot on there. It's a slight evolution of
it. But yeah, and we create these deav pools that work for these specific projects that you've built in your deav center, right, and your project is associated to a specific infrastructure's code catalog that's going to build out that environment. So again, feature X on project A, Yeah, and you can have multiple people working on feature X, and then while you're working on feature X, you know, bug A comes in and you got to work on
that. So you have multiple dev boxes running for each specific situation. Sure, and so you have these dev pools coming around, and but it's managed from you know, those that are responsible for managing infrastructure and kind of what those images should be. But just like an AVD, you're generating a compute you go in the compute gallery. You know you're building a custom image or a golden image for these deav boxes, right, and then you're assigning these
specific images to these projects. So even you think on companies that have a various need of projects, you know, going from mobile to web applications to back ends, you know you may need different under running OS systems or you know needs to run that project, and so you can get that specific environment for your developers. Well rather than having to buy a PC and a Mac for your devs because they need to develop the sub development on a Mac,
sub development on a PC. Just having dev boxes and really almost nothing installed on the local workstation, then like yeah, arguably you have more compute available in the cloud than you have on the desktop. And just to be clear, a dev box. We're talking to VM in the clouds somewhere that you use for development. Well, you said AVD, you mean as your virtual desktop. So rather than you owning the VM, this is a service that
does the virtual desktop stuff. Okay, yep, and so does this does this work differently if you're a remote or offshore developer on a team as if you're in house, I mean, is there are there any other considerations there for ADE. Well, that's the glorious part of it is is no is you can come up with a solution that works for all those scenarios. And so we talk about that velocity of coming in from a business standpoint as well as you have a way to build an environment for all those scenarios, you
know, and COVID kind of threw that all outgoing remote kind. I mean that all first class, like oh we need to make sure remanage this and so no, like I mentioned, you know, if you are a startup engineer and you're the solo engineer, you can set up dead box so you can you got to think ahead and scale because eventually as you bring more people in, this scenario will work for them, you know, handling from a
dead box perspective. Bring in in remote developers, same thing, they have their access that's set from dev center, they log in, it's in that Azure dev box where they can then access the code repositories where you can have that kind of lock down, that security so they can't just take it and walk away. Yeah, as well as consultants. One feature I'm waiting for us for Microsoft to change laws of physics so everybody's in the same time zone.
Can you guys do that? Coming from an experience of corporate for an exchange around the world, I can understand the pain of time management lining Matt Well. And presumably you can run Microsoft dev box on in any Azure data center, so if you do have offshore devs, they don't have to run in the as your data center as close as you. They run in the data set as closer to them. Yep, yep, brings out you know,
lowers that latency and brings that developer bospia. Yeah. Nice. Well, at the same time, you do have control and you're also maintaining standards on configuration and like there's a bunch of advantages to doing that way and he's strange for you kind of figure out how to sell us stuff up and you're paying by the hour, yes, and that's a key to that consumption based Like we can have scale down to idle or scale down to zero for these
deav boxes too, so you're not paying for that usage over the weekend or whenever. These developers may not be working, and that's kind of a cost satience perspective two of that. So you know when you go on vacation for two weeks. We don't have to pay for your machine for two weeks, so to speak. How do dev boxes work with mobile development? Are we forced to use emulators or can we use local devices? You know? To
be honest, I don't know at the moment. I know what Dot and MAUI come out with a lot of new technologies and that kind of hyperphone development. I would assume looking down to being native devices is key, you know, for that kind of testing, production based application. I mean a minimum, you could go through the Hockey app pipeline and push it onto a device. I don't know how fast that is. I have used a USB over network tool too that I installed on my VM and my local machine that sort
of passed through over USB access to my phone, my local phone. It only worked on Android apples. A little more persnicity about stuff like that, and it's also just takes more time, right yeah, yeah, But anyway, I think that you may have to push through the build pipeline to get auto device. Yeah, when it's a remote instance like that, now, I mean there's an upside to that, which is it's the same build process that you would do to go push to the store and so so it's kind
of legit. It's just a question of how long it takes. Like you can't beat USB cable plugged into phones sitting in front of you on your desktop when we're alrighty struggling for you know, development velocity for mobile. Yeah, I would assume the evolution goes that route, right. The hybrid phone development is has been growing over the years, you know, MAUI has made that first class citizen, you know, with the point too where you don't necessarily
to build these out in native languages. But yeah, I could see that going heavily into the future because I was always laughing my friends talking about dead boxes, like you can now kind of change the world from your grandma's penny and two machine if you have a modern browser on it, right, right, because you don't need that type of compute. Yeah, and so it opens up all kinds of possibilities, you know when you think about that. And I mean, I use the term hockey app, but that's not even
a thing anymore. I think it's just called mobile apps now. As a service inside of Azure, that's supposed to be all of those you know, sign on integration push services that kind of thing. Yeah, it's been a bit since I've been in it. I know, I used Cordova and phone gap back the day when I was doing some of my hybrid development, and I just remember old school, but I remember having multiple laptops and iPads and
tablets. Yeah, and you had to like link them remotely and that connection would always break and wondering why you're not getting the latest bits on the device, and you know, it's it's been exciting to see from my perspective, like dot net MAUI coming in and that evolution of that stack. And when I think, you know, if I'm not doing anything that I need a native access to the phone. Hybrid phone application is where I first would look.
Yeah, talking about you know, being able to use your C sharp skill set and I'm a C sharp developer and just being able to open up the project and get going quickly. And then they're hybrid integration with Blazer and bringing that into from that web tech. It's talk about agility. That's it's it's been fantastic and it just keeps getting better. Yeah, I'm just not
though that we're all the way there yet. No, No, I mean recently they just release the media elements to the dot neet mallue where you can actually stream video files. And so I think that's a big heavy, you know, blocker for a while because there's a lot of applications to utilize that medium. Yea, but yeah, yeah, there's a lot of heat growing behind it, a lot of momentum too, So it's exciting to see.
Well and you know, my better no framework about Apple Safari is encouraging too, and a lot more helpful than people realize for allowing allowing people to go down that path of progressive web applications without restrictions which we've been having to put
up with to this point. Love it kind of cock back about this velocito for a developer, you know, with modern day clouds, it's it's coming in a point too where you are involved in infrastructure, whether you like it or not, the cloud and who manages that from a think of it from a company perspective, who's managing the cloud and those costs and in the worries they may have. I've never met any CFOs like I don't care where our spend goes. Just do what you need to do. We want to build
a product. Yeah, you know, they always have some sort of handholds on it. And so there are various steps we can take to this cloud governance perspective of four developers that may not directly relate, you know, something as simple as like as your policies and being able to put in policies so we're not deploying in random, unapproved regions, or we have certain skews allowable. So I think you could code to that manually. I'm sorry, did
you say as your policy was simple? Yeah? What's you know? You learn the learning curve relatively, you know, like it's easy once I know it. Yeah, but it's kind of one of those layers, right,
you have that as your policy built in to help guard rail. I always think of it as the bumper lanes on like if you're ever going bowling, you ever popped up those bumper lanes to make sure you don't gut or ball you're you know, on your role, And that's kind of the same things we're doing here in the cloud for the developer, and it prevents, you know, helps the business. Like said, it prevents offset costs as you're tagging. Is another thing on top of as your policy where we can monitor
and maintain what resources actually being built out in the cloud. And so if you have a certain scenario in your business about you know cash, but you know chargebacks for infrastructure and you manage you offer subscriptions your clients, you can now manage that and you know what's going on there. And that brings a developer of loss, you know, knowing what people or your developers are building
out and then tagging that and knowing where it's sitting. Right again, another thing it's automated through that devth center too, of building out these environments through that infrastructure's code and set all those up and so you can pop up for one developer fourteen sandbox environments and everyone's comfortable where they're at because we have the security around it, we have the networking around we have the r back permissions
around it for a user and those interacting with it. Access control, Yes, the role bays as control for users whether you know there need to read those resources or actually contribute to them and interact with them, deploy to them. So I mean part of those policies would be this stuff turns off after work is over, Like how do we think I'm looping us back to the beginning there where it's like, hey, don't leave all these things on.
We now have the dev center. We have a center, Like we have all these great tools, but they're also going to help us clean up, right yeah, yeah, and we can set those One of those features too, is from these projects when they're completed, you know, we've built them out, they're running. That project's done, we commit the code to that the main branch. Do you go to production when that project is done,
we end it. It'll remove that infrastructure too, so you don't have those orphaned resources yeah, just sitting there, you know, with cost or potentially just I see a tactic a lot of people say, well fixed scales down to zero, we just leave it because it doesn't charge us money. But then you just you have a mess though you have a huge cattle. Heard
of cattle sitting around not being used, you know. So well, I like the idea of using tagging to say this is actually a dev resource, so it's like if no dev is currently going on, this probably shouldn't be here anymore. Yeah. Well, and even when we build out those resources from devs the dev center, it builds it out in a resource group too, so it kind of already groups them together as well, so it's just
easy to organize and maintain, especially if you're working through the portal. One of the hardest things that I've had to do in the portal is go through some old resources and wonder, is anybody else besides me using this? This was like something I can't remember what this was, and you're afraid to delete the resource because yeah, yeah, what was that hasn't been used in two years? Is it? Delete it? And then production goes down. Yeah.
Easiest way to get a phone call when you're feeling lonely just delete a couple of resources and wait, look they let me again. Job security. You missed me, didn't you. Yeah, just for one little right click stop, there we are, Here comes the love. Yeah. But it was as funny as that joke is. It's true, though, how easy it is to build out and how easy it is to ruin something that's you
know, stub your toe. Well, yeah, and that's I think one thing too with his automation, that it's not only to have that velocity move forward, but also to make sure you don't hurt yourself or your team as you're moving forward, which is going to increase that velocity as well. Yeah, Brian, can you share any training or documentation or video resources that we can point our listeners too if they want to learn more about this? Yeah, yeah, I'll send you some links. I know John Saville, he's
a cloud sosition architect as well. He has a fantastic YouTube series really breaks down in the details a lot of what goes on in Azure, but he addresses kind of the infrastructure's code and DevOps perspective specifically. He's a fantastic resource for those great cool I know who Johnny is, the big guns guy. And what's next for you, Brian? What's in your inbox? You know?
For me, I've always been struggled to kind of keep on a blog and you know, podcasts always like the ideas and so the consistency has been hard to keep up. So I'm kind of aiming for starting to write a book on leadership and debt do it? Yeah? Sorry, it's a little book, a little book, right, let's just say that out loud,
Richard. Yeah, sorry. You know. Wherever my my journey leads me to help continue on working with the development community, I really enjoy I love watching young developers, new people in the field, and just have that lightbulb goal off like, oh, look at the potential, you know, and so whatever means, whether it's conferences or more podcast like this, I would love to be a part of the help great, awesome. Hey, thanks for spending this time with us. It sounds sounds like really good stuff.
Thank you, Thank you. Looking forward to checking it out and we'll talk to you next time on dot net rocks dot net rock. This is brought to you by Franklin's Net and produced by Pop Studios, a full service audio, video and post production facility located physically in New London, Connecticut, and of course in the cloud online at pwop dot com. Visit our website at dt n et r ocks dot com for RSS feeds, downloads, mobile apps, comments, and access to the full archives going back to show number one,
recorded in September two thousand and two. And make sure you check out our sponsors. They keep us in business. Now go write some code, see you next time. We got van