Welcome to episode 348 of the Microsoft Cloud IT Pro
podcast recorded live on August 11th, 2023.
This is a show about Microsoft 365 and Azure from the perspective of it pros and
end users where we discuss a topic where recent news and how it relates to you.
You get a subscription and you get a subscription and you get a subscription.
Today we talk all about Azure subscriptions,
the nuances around them in considerations for having multiple subscriptions
regardless of your company size.
Did you wanna mention your Hashi Corp news that you posted out there?
I saw that link. Yeah. This was interesting. Yeah, ish.
I spend a little bit of my life thinking about how
we interact with our customers with open source tooling,
right? Like I've got easy copy and s STKs and all these things.
And we certainly wanna encourage customer contributions.
I work with customers to help them sometimes like think about ways to do like
data migration and maybe wrap a copy rather than building your own data
migration engine thing, thing, things like that. So, you know,
all our stuff is like out on GitHub with a fairly standard m I t license. Yep.
Like you know,
another customer could come and they could fork one of our projects,
take it on and pick it up and make it their own thing and they could support it
and do what whatever they need to from there. So HashiCorp,
so they're the purveyors of Terraform. So it,
Terraform has traditionally been an open source project and
it's been,
I believe it was licensed under an M I T license previously.
But regardless of that, you know,
they've been in a position where they publish things like the core of the
Terraform engine out to GitHub and anybody can come and clone or
fork that project and do what they need to do with it.
So that could be a customer, it could be an I S V, it could be a partner,
could frankly be a competitor, and then competitor. Uh,
and then HashiCorp like many other companies that publishes open source tooling,
they have an enterprise entity as well.
And that entity is out there to make money and keep the rest of the business
going. So HashiCorp made the decision this week, yesterday.
Today is Friday, August 10th, 2023.
As of August 10th, 2023,
they are going to A B S L or A B
U S L. But it's a business source license.
So it's an alternative license
that puts some restrictions in place,
particularly in the areas of what competitors
can do with that code and where they might need to acquire a
commercial license from HashiCorp.
But if you're like a big open sourced purist,
I can't say I'm like exactly evangelical about it, but you know,
for all the FAQs and everything that HashiCorp put out and blog posts and things
like that,
like this effectively makes them not open source in
like the true, you know, evangelical kind of sense of things.
I don't think there's a major impact to customers.
There should not be a major impact to customers.
Like everything stays up on GitHub, you still have access to SDKs,
APIs.
Where it starts to get interesting is in how those restrictive
covenants potentially impact others from working with Hashi
Corp. So now it becomes really a Hashi Corp decision
for who they choose to really dive in and work with and grant
additional licensing to beyond their B SS L licensing.
So if you think about being a hyperscaler, right? You're Microsoft with Azure,
you're a W Ss, Amazon with a w s, your Google, which E C P,
all those kinds of things. There are pretty decent hooks in Terraform.
And we've talked about this a little bit in the past for like working with these
hyperscalers and having kind of ready to go providers in
Terraform for all the major clouds, all the major resources, things like that.
So technically at this point, per that, B Ss L,
depending on how like HashiCorp kind of chooses to look at it,
like if they didn't already have a relationship with Microsoft and Amazon and
others, that could be kind of bad.
Like they're saying they're gonna continue to work with all these companies.
Clearly they made this decision for a reason.
Like they must have some competitors who are leaning in like way too hard and
they feel like they're using their IP that had been previously released under
that earlier. It wasn't an M I T model, uh,
it was the M P L Mozilla public license.
So under that model that was out there before,
it's gonna be interesting maybe to see like over the next year,
six months to a year,
like who has to drop out and can't stay in the race because of that.
There's been a lot of this lately,
like HashiCorp isn't the only company to do this. I,
I don't know if you follow along with Linux distributions and things that are
going on there.
Red Hat had kind of a big bruhaha around what they've done with
their enterprise licensing and how that formulates
and comes back to things like CentOS and what was gonna get out in
mainline. It's kind of like Java did,
Oracle did with Java a couple years ago, however long ago that was now,
and took all those things down that path.
So we shall see where all this stuff goes.
I think it's a weird time in open source land,
like if you're an open source purist does a lot of these entities that have
open source components that then they've commercialized maybe a little
bit more than support on top of, and they're truly product driven.
Like they're trying to peel their products back and own more of that and own
more of their future along the way.
Yeah. I read this and I, again, I couldn't figure out exactly to your point.
This doesn't change a lot in,
I've used some of their stuff a little bit and the one paragraph, well,
one paragraph, one sentence they have in here, uh, about halfway down it,
well it's towards the bottom of the article,
there's comments and stuff is that it really impacts, like you said,
the vendors who provide competitive services built on their community products
and their ability to incorporate future releases, bug fixes, security patches,
all of that. I didn't even think like, would this really affect Microsoft?
Because does Microsoft actually build competitive services built
on their community products?
So Hashi Corp owns the underlying engine.
I don't know how it is at a W s and G C P,
but in the case of Microsoft, yeah.
Direct contributor to the resource provider in Terraform
for ARM resources. And there's some kind of, there,
there's some logic behind that, right?
If you think about companies like HashiCorp put Terraform or
Pop and Chef and some of these other orchestration engines. Yep.
They don't necessarily always know like what's coming next, right? Like, hey,
when's that next new feature going to come in that service?
Or there's a new service lighting up.
So sometimes like at least in the case of the hyperscalers,
like we're more well positioned to own that stuff and kind of push out
updates down downstream. And to do that,
it's gotta be a back and forth relationship, right?
Like we need to know what's coming in Terraform and folks at HashiCorp need to
know what's coming on our side. So that needs to be a little bit of a,
a dialogue.
'cause like Terraform for Azure used to move a lot slower until
kind of Microsoft stepped in and took on some of that dev effort upfront
to get those things moving. So I don't know,
like if Hashi Corp came back and they said, oh,
we want to build all of our own providers now,
and those are core to the Terraform experience, like for the hyperscalers,
like what does that mean for the hyperscalers, right? Like I, I don't,
I don't think it would get there,
but the kind of metapoint is Hashi Corp is in full control of that
now. So back to that whole like eh,
what's open source thing and is somebody gonna be like a little bit more
evangelical or a purist about it?
It's a little bit of a different place to be right when the enterprise
steps back in and takes that on for themselves.
Interesting.
I thought it was a fun one And, and like I said,
like no major impact to customers I don't think unless you're using a competitor
product that somehow runs a foul of this thing.
And that's when it becomes interesting in like six to 12 months because you
know,
as new features come out on the HashiCorp side or in the core of Terraform,
like can they keep up with it? Like eh, I don't know, we shall see.
But if you're just a regular customer and you're out there and like, Hey,
I use Terraform and I deploy it and I use these things like, you're fine.
No major impact for you there.
If you wanted to go out and build a competitor business though, you're like,
Ooh,
I just became a Terraform expert and now I wanna build a competitive business on
top of it. Like depending on what you wanna build that could be rougher.
Right? 'cause that's what I'm gonna say.
As long as it sounds like you're not actually building anything that competes
with Terraform, you're still not, there still isn't any impact for you.
It's only if you use their stuff to build other stuff that
competes with their stuff.
Yes.
That's my reading of their B S L and kind of reading between the lines and their
F A Q. But you know,
folks gotta go out and and read that for themselves and take it in. Yeah.
And I should, I am not a lawyer. .
Yeah. Or a licensing expert. So yes, I agree.
Go figure it out.
Have your lawyers figure it out if you think it might impact you.
But to your point, if you're out there just building stuff, deploying stuff,
managing state with Terraform and all that, really nothing changes. Correct.
All right, so, so since we've been talking about Terraform and deploying stuff,
you wanna talk about deploying stuff?
Let's talk about deploying stuff.
So I had a client come to me and they
said we want to deploy,
and this is this for anybody listening or those of you in the Discord anxiously
waiting,
this is the discussion Scott and I were having right before we jumped on live
today. I had a customer come to me and they said,
I want to deploy Microsoft Defender for cloud,
but I'm not gonna give you access to the subscription.
I will only give you access to the three resource groups that we want to push
Microsoft Defender for cloud to.
And we don't necessarily want to turn it on for
everything.
We are a small business segment focused on a particular app
that it's three resource groups, same subscription, dev test, qa.
Frankly I don't even know what other resource groups are in there or
how many they have. What are the resources they have? And I was like,
okay, let's go turn this sunlight up for the VMs.
And I knew I was gonna have to go into the subscription you turn on Microsoft
Defender for cloud at the subscription.
I don't know that I ever put two and two together until I went to try to do
this. That you cannot only
light this up for a subset of
resources,
whether they be on a resource by resource basis ish.
There are some exceptions to this, but just a couple,
or even at a resource group level,
like all of the defender for Cloud is published with pricing of like servers
$15 per server per month for defender, for cloud plan two,
so much for Azure sql, so much for storage accounts, all of this.
But you go turn this on at your subscription and you can pick and choose which
resources you want on.
So you could only turn it on for servers or only turn it on for storage
accounts.
Yeah. Uh, pick which resource types, which.
Resource types. Yes. Good. Yes.
Clarify that Resource types only turn it on for sql but it
will get turned on for all of that particular resource type at the
entire subscription level. So in this case, this small business segment,
because they just did resource groups in a much larger subscription that
realistically could have 300 other resource groups in it for all I know cannot
leverage Microsoft Defender for cloud without impacting the other 297
or 506 or whatever number it happens to be without
impacting and conversely paying for that
resource type protection across the entire subscription.
And I was complaining about that because I wanted to have more granularity
in which resources this gets deployed to. I said there are some exceptions.
There's a couple of 'em. Like I noticed storage accounts.
You can go into a storage account,
go into defender for cloud and essentially say don't inherit the settings from
the subscription and just disable defender for cloud on the storage account.
But that does not hold true for every resource nor is there any way to
do that with like policy or exclusions of a
certain resource group.
It's like a manual resource by resource toggle
that you could probably script it out.
But I was annoyed and I was complaining to Scott.
I love this as a good lesson in
potentially how you approach deploying
a new service in the cloud. So it sounds like,
and it's kind of an unfortunate situation,
but it sounds like that customer that you're working with didn't take
step one,
which was go read the pricing docs like the,
like that is the,
the most important piece of documentation that you could sit down and kind
of start to consume and touch.
And I don't know that the defender team has done a great job
with kind of disambiguating what is an individual resource
constraint within their service and then what's just the broader
defender for a cloud thing. So step one would be, hey,
let's go read the pricing docs step two.
And we kind of do this on all the do the cloud streams we do, right? Yep.
Like when we wanna start playing with this stuff is, hey,
let's go read the overview docs. I've never touched this service before.
Let's just see what's going on with it. What are you kicking around?
So you know, you and I were chatting earlier about it.
So I started going down that path. I'm like, all right,
lemme go look at the pricing docs. Lemme see what's happening.
Lemme go look at the overview. And if you go look at the overview for Defender,
it very quickly points you to a place which says how do you enable paid
plans on your subscriptions? And I,
I absolutely love the way this is done is if you go to that link that I just put
in, uh, discord it be in the show notes there, that is the, it has a note,
you know like one of those like purple boxes in the Microsoft Docs.
And that is the one place where I have found so far that it calls out
here is the specific set of resource types
that are going to be available for individual like resource level
enablement, like you mentioned storage accounts. There's defender for sql,
which you gotta be careful with 'cause there's defender for sql,
like defender for like SQL services like Azure sql. Yep.
And then there's defender for SQL like ias VMs.
So that one's a little bit weird. You have open source relations,
relational databases, so like my SQL MariaDB, things like that.
And then you can also do workspace level defender
plans for servers and defender for SQL servers on virtual machines.
That being said, defender is like a slew of things.
I forget how many they have there.
There's gotta be at least 10 different workload types that they cover if not
more within there today and they keep adding more of them on.
So the way I like to think about Defender in the back of my head is defender
is fundamentally a subscription scoped thing, right?
Like I'm gonna light this up and it's gonna protect everything in my
subscription for a workload that I enable.
So I go enable defender for servers great.
Or let's pick one that it like can only cover everything.
So I go to defender for app service,
every single app service regardless of scope within that subscription.
Like if it lives, you know, in this resource group over here,
this resource group,
like all of them are just now protected versus that defender for storage thing,
which then I go light it up one piece at a time and and turn it on that way.
The other thing that I've seen that's very con uh.
Storage accounts, it's the opposite way.
You go turn it on and it lights it up for everything.
It's on by default for everything You have to go disable it. Yes, yes. It's not,
you can light it up and then go enable it one by one.
It's you light it up and then you have to go through. So in my case,
like let's say they have 300 subscriptions,
I'd have to go into the other 297 subscriptions and turn off every storage
account across, across all those subscriptions after I enabled it. Yes.
I can't just enable it and then say go just let's go manually turn it out on
these two or three.
You want me to give you like another little bit of nuance here that's probably
gonna annoy you even more. Sure.
You don't enable defender for cloud for resources like that
in the actual resource provider of the owning service.
So like for a storage account,
if you want to manipulate defender for cloud for storage accounts,
you use the defender for cloud rp, their resource provider to do that.
Which makes sense, right? 'cause it's a defender piece of functionality.
But I have seen like customer asks come in where they go,
Hey you don't have a commandlet in storage or I can't do this through your A P
I. And it's like well 'cause it's not us that did it, right?
It's the defender team that did it right? They own it.
We give you the storage account and now you wanted to do something else with an
additive service that was technically outside of storage. Like alright,
you've gotta go potentially solve for that one and figure it out.
So, so defender becomes kind of a,
a wonky service in that way 'cause it's really like a
big bundle and then a bunch of attributes that are applied to it for workloads
and then you can potentially get really granular, uh,
and go down to the resource level.
But that's all dependent upon the defender resource provider and their building
model and and all the things that they do there.
But I think another interesting thing that came outta the conversation we were
having was I'm starting to talk to more and more
customers where there's this inherent just
fear of additional operational complexity around
having multiple subscriptions in Azure. I totally get it.
Like if you've been doing Azure since the A S M days or I'll say pre
management groups in Azure AD and id, all that stuff,
like if that's the mindset you're coming from and you've never played with
management groups, then I think multi subscription gets a little bit scary.
Like it's tough. How do you have insights into things?
How do you deploy policy at scale, all that good kind of stuff.
The other thing that I run into is
customers get scared of multiple subscriptions because they think
multiple subscriptions means a bunch of manual process. Like oh you know,
I'm a customer on an M C A, like I,
I transitioned from an EA an enterprise agreement over to Microsoft customer
agreement and because I made that transition, now I'm just like,
uh, I'm on some kind of different plan. I don't know what I'm doing over here.
If I wanna create a new subscription,
I'm gonna go out to my licensing portal and spin it up that way. And the one,
the portal that I still remember and is near and dear to my heart is the EA
portal.
Like I go in there many a time and manually created a subscription
but you don't need to do that.
Like there are avenues to programmatically create Azure
subscriptions and it's not for everybody. And when I say it's not for everybody,
it's only available to certain classes of subscriptions or certain types.
So specifically EA M C A and M P A subscriptions but
totally doable. And then once you go down that path,
like so if I can programmatically create a subscription and
I can manage all of my subscriptions at scale through
management groups at least in the lens of policy and getting that down,
that's kind of two big buckets for me.
And then I think the third leg of that chair tends to be security.
So I also see customers that still don't necessarily
grok the whole Azure ad enter ID isn't actually Azure
thing like it's kind of like this meta service sitting out over here.
So they go, oh I have to create another subscription.
Well that means I need to redo all my security and I'm gonna have another
identity provider and I gotta go back and I gotta do my security groups.
It's like no, no, no, no,
let's take a step back because now you have an A tenant that holds your
identity,
you're gonna take that new subscription and associate it with that existing
tenant so it gets all the existing security you can use the same
security groups, same enterprise app, same spns,
all that kinda stuff is available to you.
Management groups are gonna be the construct that lets you come back and apply
policy consistently across one or more subscriptions that you've
grouped together. And you can have, I forget how many,
how many levels to the hierarchy or management groups,
like eight or nine levels, something like that. Like it was.
I can't remember. There's.
A ton of flexibility there that's available to you.
But you need to shift your mindset a little bit out of like,
oh I'm doing everything manually over to how do
I automate that and start to move things forward a little bit.
Do you feel overwhelmed by trying to manage your Office 365 environment?
Are you facing unexpected issues that disrupt your company's productivity?
Intelligent is here to help much like you take your car to the mechanic that has
specialized knowledge on how to best keep your car running intelligent helps you
with your Microsoft cloud environment because that's their expertise.
Intelligent keeps up with the latest updates in the Microsoft cloud to help keep
your business running smoothly and ahead of the curve.
Whether you are a small organization with just a few users up to an organization
of several thousand employees,
they want to partner with you to implement and administer your Microsoft Cloud
technology, visit them at intelligent.com/podcast,
that's I N T L L I G I N
k.com/podcast for more information or to schedule a 30 minute
call to get started with them today.
Remember intelligent focuses on the Microsoft cloud so you can focus on your
business. So here you go.
You can have 10,000 management groups in a single ad tenant and six levels of
depth not including the root or the subscription. So Gotcha.
You've got levels and lots you can create. Yeah.
And and then I think the other thing to think about here is,
and we got a couple folks mentioned it in the chat is if you're an SS M B,
like you're just a a small business really,
like I get that there's friction,
but how much friction is it for you to go to the Azure portal and just spin up a
new subscription like next, next, next. You're way through it.
Even if you're a PayGo customer and you have to put a credit card on there,
like I do this as a pay customer.
Like I have to keep some Azure subscriptions around as just pay subscriptions
because like there's,
there's only certain ways to get into functionality that I need or,
or I need visibility in the way customers see things versus the way they are in
like our preview portals and stuff internally and I just need them in like a
bog standard subscription. So it's, it's easy enough to do. Yeah,
I think for a lot of it, and it's gonna sound harsh,
I know it's gonna sound harsh but I don't mean it to be harsh.
It's not as hard or as much friction as a
lot of folks are thinking about it to be.
Like once you sit down and and think about it like it does not take more than
five minutes to create a new subscription if you just want to next, next,
next your way through it.
It's not like a three month project to figure it out and get it going and
start living your life that way.
Yeah and even as a C S P,
so I do indirect C S P stuff and I have some clients that buy Azure
subscriptions from me and even from my side, same thing,
they need a new subscription. It's like sure, let me set one up for you.
It takes me 30 seconds to go log into the portal, click new subscription,
they're good to go.
And I agree like there was those questions in the Discord chat of like
to someone asked typical number of subscription in a small business.
Some people are saying at least two I think like at least to your point in
mine, some of it is because of my Azure credits but I have like 12 subscript,
12 Azure subscriptions and there's me and Sean and
I have JP doing it like there's three or four of us.
But it allows me to separate stuff out.
Like I can go flip on Microsoft defender for cloud to see it and make sure I'm
only hitting like one of each resource type so I'm not using a bunch of money to
test it. To your point,
I think people way under create the number of subscriptions
they realistically should and I don't know that people
put a lot of thought into it. Again,
I'm going through this with another client right now where they have five or six
subscriptions, we're going out to 11.
We may even spin it out to even more for reasons like this.
Like there's a lot of stuff at the subscription level.
I think the other barrier I do see people run into is subscriptions and
it's something to think about is how do you do your networking if you're gonna
start spanning a bunch of subscriptions because you do run into that a
vnet,
a network cannot span multiple subscriptions so you end up having
to do different things to connect these together.
One could also argue it's good because it helps you separate out your networks
and create maybe a true hub and spoke type model,
separate out those networks because maybe you shouldn't actually have all those
resources in the same network anyways.
It's trade-offs and kind of rationalizing your way through it.
So I'll go back to the docs thing again here.
So Microsoft has a couple of frameworks.
So there's the well architected framework like when you're actually getting
ready to like build things out like hey what's the best way for me to build this
application or design it with services, things like that.
There's another framework that's called the cloud adoption framework.
And inside of the cloud adoption framework there's tons of guidance
around things like how should you think about organizing management groups
and I'm specifically gonna say management groups,
not management group because you're probably gonna have like multiple levels
that hierarchy and multiple groups within them.
If you go out into the caf,
that cloud adoption framework and you start going into the
resource organization stuff like you just threw a link in the chat for like
organizing subscriptions,
just pay attention like everything is pluralized ,
like it's not organized subscription, it's organized subscription.
And even to the point where you get down and you like,
there's some use cases like hey specific use cases.
All the documentation is not create your initial subscription,
it's create your initial subscriptions,
scale with multiple subscriptions, organize your subscriptions.
So the thing that folks need to get out of their head and or potentially kind of
just wrap their head around is if you've been doing Azure for a long time,
you were taught to treat your subscription
and then your resource groups inside that subscription as units of
management that are aligned with your business needs, right?
So like I had one subscription and then I had my business units like finance and
HR and maybe I had a resource group for each of them and then I went and
deployed my things and and sprinkled them out there and and did that.
In today's world where it is easier to create,
operate, manage and maintain multiple subscriptions,
you can really uplevel that and think about it at a higher scope and you can go
from treating your resource groups as a unit of management that are aligned with
your business needs to treating subscriptions as a unit of
management that are aligned with your business needs.
And then once you do that you're in a totally different place
like it.
It is a different mindset and a different way to think about it.
And I tend to find as long as all your subscriptions are in the same tenant,
like you talked about having 12 subscriptions across multiple tenancies and kind
of the pain that comes along with that, like I totally get that, that's a pain.
But as long as I can do things like AZ login once to my tenant
and then have access to all the subscriptions, set it like I,
I really don't care if it's in sub A, sub B, sub C, whatever it happens to be.
Uh, subscriptions is subscription.
I just want to get down to the underlying resource that's available
with it there.
I agree a hundred percent that it,
it absolutely wasn't the early days and I think this is to your point why people
are struggling with it. People were doing stuff at the resource group level,
it was resource groups for departments, for business units,
for applications for use, tagging use, all of that.
And I think it's very much transition to subscriptions and if you wanna do a
SharePoint analogy,
it's kind of like the transition we've seen there where it used to be let's
create a SharePoint site collection and create all the SharePoint sites
underneath it and it has transitioned to now let's just do site collections for
everything and there's no point in creating sub-sites for those of you that are
in the office 365 space and need an analogy to that. You.
Go back to like even the SharePoint analogy in SharePoint you never
create just a single site collection. No you are going to end up with.
Multiple ones, you should.
and I go back to like that calf thing,
like if you go into the docs it just keeps driving you this way saying like hey
here's recommendations.
And they're not even recommendations like we're in like patterns and practices.
These are things that have been proven out across multiple customers over time
and this is the way like stuff is managed at scale.
Like these are like direct learnings from Microsoft having to do itself,
you know their major customers, even their internal services, right?
If you think about like you know Azure sql,
Azure SQL is an Azure service that is built on top of Azure as well.
Azure storage is a service built like we're all built on top of Azure.
And so you have to get into that mental model in that mindset.
So like even if you go to the hey create your first subscription guidance in the
calf, it's not create your first subscription,
it's create your first two subscriptions,
here's how to create your production and your non-prod subscription at the same
time. Like just go ahead and get this done from the start and
then you gotta figure out the next friction points like how do you deploy
things, how do you move things around, how do you secure them?
And there's tons of great prescriptive,
like really good really prescriptive guidance out there for that with
things like landing zones,
you mentioned network topologies like hey there's a ton of
guidance out there for thinking about like do I do hub and spoke?
Do I need uh connectivity back to my wan? Do I do virtual wan?
How do I think about IP addressing across multiple subscriptions,
multiple V nets, multiple subnets, all those kinds of things.
How do I think about security?
Like it all just starts to kind of tie back together once you have
that initial mental model in your head. Yeah.
And Pirate is asking in the chat too,
like do you think it's purely a conceptual thing and I'm assuming you're meaning
like getting over that barrier,
having multiple subscriptions and thinking through all those concepts
and I would say a hundred percent especially from
people that have been doing Azure for a long time and been listening to
Microsoft talk about it for a long time is that it's
like you said,
it's a step upwards in the architecture that's as it's grown as people have used
Azure, if we've learned more as we've architected more,
it is absolutely a step upwards in the architecture and thinking through
how you plan this out And you even look at like some of the Microsoft exam stuff
around architecture and going back to hammering home,
this multiple subscription thing is Microsoft more and more hammers through
and it came through like Scott said,
the landing zone through the cloud architecture framework, all of that is,
this is one of those things that anybody that's standing
up Azure now or looking at uh moving forward with Azure
needs to understand these concepts and really put thought and planning
into this ahead of time.
I do feel for companies that maybe have been on the same Azure subscription for
eight, nine years, they got on Azure when it first came out,
when it absolutely was do everything in one subscription.
They put it all all out in resource groups and now they're running into
challenges.
It is not easy to go take one subscription and break it up into a whole bunch of
different things because you can't just pick up resources or pick up
networks and move them from one subscription to another subscription.
There is absolutely some rebuilding that is involved in that. I think.
It's getting better the number of things that kind of tend to
cause friction or pain like that list,
like if you thought like hey that's my shopping list of stuff.
Yep I gotta go grab off the shelf.
Like it's getting smaller and smaller by the day.
So that could be things like honestly moving
resources between subscriptions these days isn't really that bad.
Where it becomes painful is typically when you're trying to move resources
between subscriptions that are in different tenants.
Like back to that wrap your head around like how your tenant model is gonna tie
into your subscription just about everything else. Like not too bad.
The other big pain point with resource stuff is just being able to like move
your resources between regions.
Like sometimes companies choose to go down that path,
it's a little orthogonal but you know that's another consideration for you and
that's where stuff like resource mover comes into play and and keeps you kind
of where you need to be. Networking is a sticky one.
The thing that I see and I I'd be curious Ben,
like what you see with your customers is I still run into folks who are thinking
about networking and v netting as really little itty bitty V nets,
like slash 20 fours versus slash 16 kinds of things.
So you know they're,
they're running out there with like 254 ips for 250
ipss 'cause of all the reservation like for this thing and then they're running
for two 50 for this thing and for this thing and then they're trying to tie it
all together and they're trying to figure out how to get a firewall in there and
get a subnet for their bashing thing and they're like,
I just don't have enough and I can't figure it out and now it's gonna overlap
with this other thing. It's like alright so we gotta take a step back,
we need to maybe plan things a little bit.
Like I think like a lot of this stuff like it is super helpful to go back to
the prescriptive guidance. Like I know not everybody learns from documentation.
I get it. Like I am sympathetic to that.
You're not always gonna find a video for this stuff and you're gonna have to go
read some things though just to,
to move them forward and if you find the Microsoft documentation a
little squirrely, like it's just like obtuse to you,
I get it but you still gotta like lean in and and go down that way.
Maybe there's some YouTube videos or some plural say things but I think like the
definitive resource for this stuff is gonna be the Microsoft
docs.
Like once you start to get into it and you know get hands on with it I think I
think it helps a lot too.
Yeah,
I do see a lot of still those smaller networks like you said I did just post a
link to in the chat that gives you some guidance around moving networks because
like people are asking in the chat networks is probably the biggest one,
especially if you have peering like you're gonna have some downtime 'cause at
least if you're moving a vnet with peering you need to remove the pairings then
you can move it, then you can reenable the pairings.
But thinking about overlapping address spaces and networking
is, I would say by and large probably the stickiest part of moving resources.
V P N gateways are another one if you do have V P N gateways,
hopefully you don't have too many of those depending on how everything's is
configured. But yeah, it's, it's interesting .
I get it. It's hard. Change is hard.
Like I struggle with that stuff all the time but I think a lot of,
I know it sounds harsh and I don't want it to be a harsh thing.
I want it to be a a realistic thing.
If you're looking at this and you're going like wow, that's a lot of friction.
It's like I get it but there is tangible r o i
there for you should you choose to go in another direction, right? And I,
I'll take it like let's circle back around to defender for cloud customer,
right?
Like they want to be able to enable this and restrict it to a set of resources
like with the current billing model for defender, for cloud.
Like the reality is like you're gonna need multiple subscriptions to make that
happen and some of that friction comes in if you don't already have
multiple subscriptions.
Like you don't have that mental model so now you gotta go step back and do what
for some people was foundational work but for you could not be like it's you
circling back around to it and having to rethink things and then maybe that has
a a,
a knock on effect but if you had already had one or you already had two
subscriptions or maybe three like you had like prod,
non-prod in your sandbox or like your dev like your real like dev playbook
test area,
like spinning up another one of those should be pretty common at some point and
you'll just kind of get yourself to to where you need to be.
Absolutely. So I don't know,
I don't know that I have anything else on that topic.
I think we covered it pretty well other than to summarize,
go create more subscriptions than you think you need .
Uh, yes there is. Are we at peace?
Like it helps to have at least two when you're starting out.
Well thanks Scott, that was an interesting discussion.
Always good to talk about structure.
I know we have some videos too out there that I think we talked about
management groups a little bit. That was in the to the cloud membership stuff.
I gotta.
Get you to post those videos. I did those, those,
yeah we do have a video where we did management groups created 'em,
kind of talked about some of the nuance of putting that hierarchy together,
moving things around and management groups, all that stuff. I just gotta, I,
I gotta get my editor to post 'em something.
To do this weekend I can go edit that video and get it posted for everybody so
they can watch where we were playing around with management groups. Awesome.
Well thanks Scott. I think we'll wrap it up. Go and enjoy your weekend.
Try not to melt. It is way too hot.
I'm gonna go sweat it out.
I apologize if anybody heard my AC running at a million percent or
my fan that's spinning above me at, at a million miles an hour.
But it is currently, oh what is it? Uh,
feels like it's currently one 13 as the sun just streams in behind the sun.
Sun hits me more. No, go away. Yeah, it's hot outside. Yeah, I'm gonna,
I'm gonna sit here and have my ice tea and .
My kids went out to the pool today and lasted like 45 minutes. They're like,
it's too hot out the pool is like 88 degrees, said the same thing.
It feels like 115 or whatever And.
Yeah,
my dogs go outside and I know it's hot when they don't even wanna like play with
a ball or do anything, they just go outside.
They do whatever they need to do and they turn right back around and come in.
I don't even have to say like, hey come inside.
It's like normally I have to like go out and hurt 'em and nope,
they're all ready for ac so.
You know what that means, Scott, you should have ice cream for dinner tonight.
We used to do that when it was too hot. When I lived in Michigan,
in Florida it's too hot too often to do that but every once in a while I.
Had ice cream for lunch. Oh.
That.
Works. I had a pint to Ben and Jerry's for lunch. So ,
I don't know if I should watch my figure going in the wrong way,
wrong direction like that. Well just.
Get on the treadmill for a little bit Now that's if you eat ice cream while
you're on the treadmill, that's okay, right?
Absolutely.
like everything I know about exercise I learned from Peggy Bundy. Right?
Like gimme a bon bon and a couch and I'm all good .
Perfect. Alright, so now we literally will wrap it up. Go enjoy your weekend,
enjoy your ice cream and we will talk to you next week.
All right, thanks Ben.
If you enjoyed the podcast, go leave us a five star rating in iTunes.
It helps to get the word out so more it pros can learn about Office 365 and
Azure.
If you have any questions you want us to address on the show or feedback about
the show, feel free to reach out via our website, Twitter, or Facebook.
Thanks again for listening and have a great day.