- Hey, friends.
Changing the culture for developers
in IT organizations isn't easy.
But luckily,
Scott Hanselman is here
to discuss this challenge
on this week's episode
of Azure For I-
- Did you take my show?
- Of course not, Scott.
I'm just such a fan of the show.
- Okay.
- I've always been envious
of your guests.
So lucky me, I get to host you
on this episode of
"Inside Azure for IT."
- All right, well flattery
will get you anywhere.
So I'll be happy to come on
your wonderful show.
- Scott, DevOps is often
thrown around as a buzzword.
Something everyone needs,
but can you tell us
what it's really about?
And what does it mean to you?
- For me, DevOps is about
changing the relationship
between IT and developers.
It's about trust.
It's about trust in your team,
it's about trust
in your organization,
and ultimately it's about the trust
that you have in your code itself.
- That makes sense for developers,
but what is IT's responsibility
in the DevOps cycle?
- Well, in the old days,
I believe that the relationship
between IT and Dev was
a strained one,
and Devs would throw code over
the wall at the IT folks,
and IT would be required
to maintain it,
but they didn't have
a real ownership.
What DevOps does,
is it formalizes
the relationship between
Dev and IT.
It comes up with a pipeline
that is shared.
You can imagine a Venn diagram
of a Dev and IT,
and then we share that
pipeline responsibility.
And now IT is a team member
in that process,
they're a valued team member,
and we can trust the code
all the way into production.
And rather than IT acting reactively,
rather than IT getting involved
when there's problems,
they're involved proactively
so that everyone can
be successful upfront.
- That's one of
the biggest benefits
that I really see in DevOps
is that alignment
and aligning earlier.
And that's why I love it when
IT and Devs come together
to work on infrastructure as code.
Dev building the environment
they need as a code artifact
and then creating that
exact same thing
for Dev and test and
in through production.
This really gives the ability
for IT to set guardrails
and policies for the app.
And that partnership makes
lives just so much easier.
It really enables the developers
to get the infrastructure
from the cloud
and that the infrastructure
just becomes part of the app.
And then the customers I see
that get this right are freed,
they're freed up just to
speed their time
and their innovation.
They're not overtaxed
by opening ticket requests
for new servers and VMs.
And so it just makes that whole
process just so much more
seamless and empowering.
So can you share maybe
some practical examples
of how you've seen
this in action, Scott?
- So I've been software
now for 30 years
and many years ago you would
write a Word document
and IT and Dev would
share this Word document.
But the thing is that Word documents
don't break builds
and infrastructure as code
is a formalization
of this is how system
is supposed to be.
It's a declaration of how things
are supposed to work
and that code can break the build
and the build might
be the infrastructure
or the production system.
And the formalization of that,
not just a Word document,
but real code artifacts
that live in GitHub,
that live in AzDO,
makes a huge difference.
And then your point that
you made about policy
is hugely important
because the policy then
could be a code break.
I've checked something in,
doesn't meet security,
doesn't meet policy,
doesn't meet global geo naming,
whatever policy you have,
you have control now.
So rather than opening a ticket
when it was a bad idea,
we caught it on the check-in
and that's hugely, hugely valuable.
- So policy is an important piece,
but so is consistency,
and the ability to manage those apps
in a consistent way.
Can you tell me a little bit
about Azure Arc
and how that really helps
the DevOps process?
- Well, if I've got
a bunch of stuff in Azure and
I've got a bunch of stuff
that's sprinkled around my
infrastructure internally,
not being able to manage that
with a kind of a single pane of glass,
a single portal,
a single set of rules,
a single set of policies,
can be hugely challenging.
And Azure Arc is that bridge
between the cloud on prem
and the cloud in the cloud.
And being able to think about
a Kubernetes cluster
that is in the cloud and
one that's under my desk,
or when it's in my
internal data center,
is the power that Azure Arc provides.
And then we can then empower
that DevOps team
to focus on the automation
and the policy-driven configuration.
And that's what IT's good at, right?
They're gonna do all
those great things
that are gonna maximize availability
and productivity
for the developers.
That way the developers
think about shipping
and the relationship is intact.
- We're trying to simplify,
provide that consistency,
and really empower each of them
to live in the world
that they're great at.
So, which is awesome.
So I think, one of the things
that's really important
when we think about
building these applications
is making sure that
it's built in such a way
that the app is
a set of connected services
rather than a monolithic app.
And so if you have
one piece that breaks,
it's easily recoverable
and the team can really see
that if a part of the app is down,
they can figure out a way to
make it work in the best way.
And Azure is really, I think,
the best place to do this
because we can help you,
as you say, with Azure Arc,
across your entire estate,
not just in one cloud.
So let's shift topics a little bit,
which is about building those
brand-new, cloud-native apps,
but again building them in an
on-prem environment.
And so, let's talk, how can you deploy
containerized apps at scale
to Kubernetes clusters
that are running in your
on-premises environment?
- Yeah, that word cloud-native,
that means cloud aware.
Like this is an application
that was invented, created,
conceived of when the cloud existed.
So many applications existed pre-cloud
and we lifted them and
shifted them into the cloud,
but they are ignorant of the cloud.
Cloud native apps that
can run on things
like an on-prem implementation of AKS,
give us that ability
to run those containerized
apps at scale,
and being able to do
that both on-prem
and in the cloud is huge.
And that's why
Azure Kubernetes service
that runs on Azure Stack HCI
is such a valuable thing.
That way you get a cloud-style,
self-service system
that you have access to
using the infrastructure resources
that you can govern.
And rather than opening, again,
a reactive support ticket
after the fact,
you're gonna think about
those things ahead of time.
You can write your applications
targeting Azure,
and you can run them in the
data center that you control.
- Yeah, and going back to Azure Arc,
what I love about this
is when that application gets shipped,
you can then use Azure Arc
to manage the app's deploys
on top of those Kubernetes clusters.
And so you've just simplified
and connected
that whole DevOps experience.
So, Scott, this has gone so fast,
but for our closing topic,
whether you're talking about
IT or Devs,
what's your advice on how to help
convince a company leaders
to really invest in building
adaptive applications
that really work anywhere?
- Well, I don't know if you'll agree
with my opinion or not,
but I'm a big fan of
asking forgiveness
rather than permission.
So if you can put together
a hackathon team,
get your coworkers together,
do something on the weekend,
and try to make a proof of concept
so that leadership can really see it.
You can write a paper
and try to convince leadership,
but this is so easy and so powerful
that you can put these
prototypes together
and illustrate success early on.
Really say, "Look, this will
make our lives easier."
You'd be surprised how
quickly and seamlessly
you can stand it up and then
show that to leadership.
So put together a small team,
give it a test.
It really will cost you nothing
to try it out.
- It's amazing.
I'm sure so many things have
been done at Microsoft
in that way,
and so it's great advice.
So thank you, Scott.
It's always, these are great ways
for IT to get started
and I hope all of you have enjoyed
this as much as I have.
I've enjoyed having you here
and perhaps I'll see you
next on Azure Friday.
- Hope so.
- So as you've seen throughout
our conversations
in this episode, small steps can
lead to big results
when it comes to empowering people,
infrastructure, processes,
and investments.
And this will help you
overcome the challenges
at every step of
remote software development
and IT management.
Now be sure to check out
the other segments of
"Inside Azure for IT"
with Tara Roth and Jeff Woolsey.
And for all the videos,
deep dives, and skill in content,
head to azure.com/InsideAzureforIT.
Thanks so much for joining
and see you next time.