Let's start with organization ! Where to put all your new ideas and resources. There are 3 main parts to organizing your resources:
To start building resources in Azure, you are going to need a subscription. It is a logical separation for your resources, it controls the billing part. A good practice is to separate the production and development resources with a different subscription.
You can still not build any resources if you haven’t created a resource group. It is Azure’s way of organizing resources! Resource groups are very useful because they can easily manage a group of resources.
For example: delete resources or add tags to them, but also IAM rules are much easier to manage because rights given to a user on the resource group are inherited to the resource within it.
A good practice is to create a resource group at least per project and environment (Dev, pre-production, production). It allows a greater control on your resources, because you often have different rules by application or environment. Per example, more restriction of resources in production.
When you start creating a lot of resources between your resource group and subscription within Azure, you are going to find yourself with a huge quantity of resources that do not meet quality standards. Per example, configuration can be too vulnerable or not resilient enough.
For this, Azure uses Management groups, which are a high level object that manages subscription.
They can enforce policies and compliance on subscriptions, thus resources.
A good practice is to create one per organization, for example the IT department wants only resources in 2 regions only, but the finance team needs resources in a lot more regions but needs to configure resources in a specific way.
You can find above a representation of this organization.
Now that you are building resources left and right, the networking aspect should arise within your architecture.
A bit of vocabulary:
There are a couple of things to know when deploying in Azure. The most important being that most resources are created by default without a network connection. They are public resources with a public IP and DNS.
The app service resource is by default exposed to the outside world and does not have access to a VNET / subnet. To do so, you need either a VNET integration or a private endpoint.
With both integrations, it can connect to resources within the VNET.
There is just one thing to keep in mind, a VNET integration or a private endpoint “locks” a subnet to a certain type of resource and number of resources it can host.
For example: you cannot configure a VNET integration of app service and private endpoint of a PGSQL database in the same subnet. You will have to create two different subnets.
You cannot put two app service plans with VNET integration in the same subnet.
Only Azure PaaS services have this issue like Azure App Service, IaaS resources like virtual machines and Kubernetes clusters do not have this issue.
Once your first bricks are set, make use of the Azure monitoring stack. It is composed of:
Log analytics workspace or LAW centralizes logs from every Azure resource. You can configure it by going in the diagnostics settings of every resource.
You can then explore logs from your resource. You can even find default request to enable you to find the critical information for your workload.
App insight is a tool to monitor live applications. It allows developers to have a better monitoring and debugging tool for their applications.
Per example: Developer have a live monitoring interface within the Azure portal where you can see live network incoming trace.
It can be configured with its instrumentation key on either:
It's a lot more than just monitoring, the security center scans every resource in your subscription and gives you recommendations on how to have a better security posture.
It is very useful to know the security posture of your infrastructure. It enables your SRE teams to fix and improve their infrastructure.
Now everything is up and running, but you detect some weird behavior of a resource within Azure.
You will need to use all the previous tips to understand what is happening. Sometimes this will not suffice, in fact when working with a cloud provider a lot of magic is hidden from us.
How does a resource work? Or how is it upgraded? Does it have any limit? These questions are dealt with when using virtual machines or Kubernetes, but for PaaS resources you can have surprises.
The good news is that Azure helps you understand this magic with the “Diagnose and solve problems” page.
On every Azure service, there is a page to diagnose and solve problems. It allowed us to detect that we were opening too many connections towards a database and the app service couldn’t keep up. You can also look at how long boot time takes for an instance within the app service.
If it detects an issue with the health of the service, it will also be displayed when you go to the page.
We went over resource organization, network configuration, monitoring and how to debug Azure resources. These are a couple of challenge you will encounter on your cloud journey! I hope that these few tips will help you make your first steps in Azure a bit easier.