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