The Azure portal

The most obvious place to start would be the All resources page. This shows all hidden and visible resources on the account.

The Azure portal is your one-stop shop for everything to do with your cloud subscription. Here, you can do the following:

• Create new resources (there are several hundred different kinds available in the Microsoft catalog at present).
• Create resource groups for grouping objects.
• Manage your virtual infrastructure.
• Monitor the health of your resources.
• Check pricing levels.
• Update object performance by scaling up. This means that your resource will perform quicker, but for an increased cost, as more resources are provided for it to use.
• Add object reliability and high availability by scaling out. This means that your resource is always available.

Refer to the following figure:

Figure 1.6 – All resources showing connections and other visible resources

You will find yourself becoming a regular user of the Azure portal if you intend to build logic apps!

Resource groups

A resource group is a collection of objects. It typically contains objects used by just one department, one location, or a stage of development.

Typical resource group names could therefore be the following:

• Geographical: Such as North, South, East
• Departmental: Such as Research, Production, Marketing
• Development Stages: Such as Sandbox, Development, Testing, Production

This book is going to focus on the staged model – a model that is commonly used by development teams. It also aligns with the Agile model.

Here, we can see a list of resource groups I have created. Some are specific to a project, and others relate to an environment stage for an enterprise-level project:

Figure 1.7 – Resource groups in my subscription

Looking at one of these groups, we can see an object (in this case, a storage account) that is housed within this resource group:

Figure 1.8 – My storage object is my first resource in the resource group

Tip

Resource groups are a logical means to separate objects based on their stage, their purpose, or any other grouping. However, it is common to create a General or Core resource group where common objects can be reused across other resource groups. For example, an Azure function could be reused by development, testing, and production resource groups.

The object home page

Each object has an overview page that illustrates the status of the object. From here, you can determine whether it is running, can start/stop the object, and can scale it up (add more processing power/storage) or scale it out (copy it to other servers to provide fault tolerance and reliability). The following figure depicts my storage overview page:

Figure 1.9 – My storage overview page

You will notice that each Azure page is highly visual and richly detailed, containing tiles for further information. Information is categorized in sections and the object is highly configurable.

Blades and slices

You will notice that each Azure page starts on the left with a panel allowing you to select the section you are interested in. This is referred to as the blade.

Figure 1.10 – sqltestmjb showing blades, slices, and tiles

In the preceding screenshot, you can see the storage blade showing a series of slices and tiles relating to access control for this storage object.

A blade is a starting point to determine how to customize an object.

Figure 1.11 – Blade

A slice is a section detailing the options you have to customize your blade action.

Figure 1.12 – Slice

A tile is a specific element you wish to customize.

Figure 1.13 – Tiles

Each object follows this principle, and, as we turn our focus on later chapters to logic apps, you will also learn about the configurable sections of objects.