hello in this video I'm going over resource groups and naming conventions
in Azure hello this is Ciraltos I'm Travis in this video I'm gonna cover
resource groups because for a lot of people the concept is new most others
Azure services have some sort of on-premise service that's comparable for
example the concept of IaaS servers is not much different from physical servers
the concept of app services is not far from IIS or another web platform log
analytics is similar to any other type of on-site log collection service before
I go any further though just a quick reminder to subscribe every time someone
hits my subscribe button and angel gets its wings all right back to it nothing
on premises is comparable to a resource group in Azure resource groups are
used for two main things organization and billing and a security boundary for
role based access control per Microsoft a resource group is a container that
holds related resources for an azure solution notice it's not intended for
holding the same resources but resources related to an Azure solution for
example you would not put all storage accounts in one resource group and I'll
app services another instead you would put all app services storage accounts
related to one solution in a single resource group let's consider two
projects Project X and project Y both require multiple Azure services to
support the solution and two different groups will be working on the project by
isolating those services in one project X resource group and in one project Y
resource group role-based access control can be applied at the group level only
allowing access to those who need it if cost recovery is used billing can be
calculated based on the resource group when the project is over and the
resources are no longer in use simply delete the resource group to remove all
the resources this helps prevent orphan resources from lingering in your
environment there are no regional or connectivity constraints with resource
groups a resource group in one region can hold resources located in another
region and resource group will not constrain interaction between
those services for example two servers and two different resource groups can
communicate with each other on a virtual network deployed in a third resource
group providing the supporting configuration is in place let me give
you an example my current test subscription has one resource group for
all virtual networks this has a be net and the subnets and all the other
networking I need to support the services I have an IaaS domain
controller running that along with all supporting services such as a storage
account NIC are in a different resource group VMs and other resource groups can
communicate with that domain controller providing they're connected to a subnet
on the same v-net well I'm at it I'm gonna tack on one other subject in this
video the subject of naming conventions resource groups are one of the first
items you'll set up in Azure and you'll need to give them a name you can main
most resources just about anything you want but that doesn't mean you should I
can point out some guidelines for naming conventions but the most important
takeaway is to put some thought into all resource names before you start
implementing services this goes for any services not just resource groups
without a good naming convention resources and service names can become
inconsistent confusing and make the environment difficult to understand
Microsoft has a good guideline published on the naming conventions I'll include
the link below I recommend reviewing Microsoft's best
practices and coming up with your own naming convention that fits your
environment names in Azure are difficult to change you will be happy to get this
right right out of the gate if you have any recommendations on names and Azure
please leave them in the comments below for others to consider I hope you found
this helpful if so please subscribe like and leave a feedback if you're so
inclined thanks for watching