Geekly Articles each Day
📜 ⬆️ ⬇️

Detailed description of development capabilities with Microsoft Azure Cloud Services



Let's talk today about one of the fundamental services of the Microsoft Azure platform - Cloud Services.

The main idea of Cloud Services is to implement a multi-level solution using one or more web roles and worker roles (web role, worker-role) for distributed processing of requests or data.
')
So, the introductory definition: Cloud services (Cloud Services) Microsoft Azure is the ability to create multi-component applications that are somewhat rethought toward a role model and flexible scaling.

For example, if you increase the load, you can scale only the handler on the server side, but leave the number of web frontend instances.

Note:
General points and the main differences between Cloud Services and Web Sites, how each of these services or scenarios implements each of the services can be found in the article Comparison of Azure websites, cloud services and virtual machines in Russian and in English .

Cloud Services Architecture and Roles





Consider the principle of a role model based on a typical Web application written using MVC (Model-View-Controller).



Access to the application is provided by the final access point (HTTP or HTTPS).



To receive data from a view ( Web- role ), the handler-controller ( Worker- role ) is traditionally used by Middleware as a queue service.

At the same time, for example, Microsoft Azure Storage Queue or Microsoft Azure Service Bus can act as Middleware.

Using Middleware is a great example of developing fault-tolerant distributed applications.
Instead of developing a tightly coupled system for which the loss of one of the components (for example, a web role) would mean the inoperability of the entire system and the loss of data, the developer can use Middleware in broker mode (Brokered Messaging).

This means that the Web- roll simply puts messages into the Middleware service (in a queue), where they are stored until the garbage collector takes care of them, or until they are processed by the Worker instances.

At the same time, the Web- roll has no idea how many processors deal with messages coming from it, whether these handlers exist, whether they are offline or online, and does not know about the processing status of these messages (unless this is specifically provided for).

It is obvious that the connectivity of the system is significantly reduced, because now the failure of part of the system will not lead to system failure as a whole.

As seen in the Cloud Services architecture diagram, each role exists in a number of instances that perform the same role function.

This means that by clicking on a link to a Web site, a user can go both to the first instance of the Web role, and to any other instance in rotation of the load balancer .

The following describes in detail the types of roles and their main characteristics:






To ensure that the service continues uninterrupted while performing upgrade activities, as well as to meet the requirements of the service level, you must define at least two instances of each role.

Cloud Service Configuration


For the description of the configuration, by Cloud Services we will understand the project a set of files that describes the cloud service. This project can be used in Visual Studio.

So, the configuration consists of two XML files:


In the Microsoft Azure configuration files, it is also possible to set two parameters indicating the version of the operating system that will serve the deployed service. The first parameter is the “family” of the operating system, the attribute osFamily, the second osVersion is the “version” of the operating system.

The Microsoft Azure service, which received this setting, searches for a specific image of the operating system defined by the developer family. The default value of this setting is “*”, indicating that the service will be launched on the newest version of the operating system and will be updated as new versions become available.

When deploying a Cloud Service solution in Microsoft Azure, both configuration files are processed by a special automatic service Azure Fabric , which, based on these files, searches for free resources that match the configuration, initiates the creation and installation of virtual machines and further deployment of the solution.

Therefore, proper configuration of configuration files is of great importance when deployed to the cloud.

Environments


Each instance of Cloud Services provides the developer with two locations for the deployed solution, Production and Staging , which are used for the variant running in a real environment and the solution deployed for testing, respectively.



During the deployment process, the developer configures the location in which his solution will be deployed.
These locations are called deployment cells and differ only by domain name and internal routing rules .

For the Production cell, the DNS name specified by the developer when creating the Cloud Service is configured, for example, http://appname.cloudapp.net , while for Staging, a temporary DNS name of the following type is created : http: // [guid] .cloudapp.net .

After successfully testing the solution in Staging, the developer does not need to deploy the solution in Production, it’s enough on the management portal to initiate the VIP Swap procedure, which in turn sends a request to the load balancer in order to “swap” the Virtual IP used for the deployment.

Thus, without any transfers or migrations, in a few minutes the solution from the Staging-cell is transferred to Production.

If errors are detected in the Production cell, the VIP Swap procedure can be re-initiated to continue testing the solution in the Staging cell, which by the way is not available to the end user.



Cloud Service Scaling


For Microsoft Azure Cloud Services, it is possible to automatically scale based on CPU load or the current number of messages in the Microsoft Azure storage queue.

The developer can track the scaling forecast in the administration panel, which will inform about the need to perform scaling for the cloud service.

To configure automatic scaling of the cloud service, you must specify a waiting period (in minutes) before each zooming.



Scaling based on the number of messages in the queue in the queue is useful if the number of messages in the queue exceeds a certain threshold value or falls below it, role instances are created or deleted, or virtual machines are included in the availability group or excluded from it.

The developer independently sets the number of messages in the queue, at which Azure will automatically scale the service.





Often, when scaling a role, it is also advantageous to scale the database used by the application. If the database is associated with a cloud service, you can change the version and size of the SQL database in the management portal.



The auto scaling engine uses five-minute intervals, and each interval checks the CPU load for the last hour. Therefore, the engine can initiate an auto-scaling process every five minutes.

But you can also schedule automatic scaling of the application by setting schedules for different periods.



It is also possible to install additional software, called WASABi, for autoscaling without the involvement of the Azure management portal, using the REST API.

Azure Tools for Microsoft Visual Studio


The Azure Toolkit for Visual Studio is useful for developers to create, manage, run, and deploy web applications in Azure.

The package contains project templates (Web roles, Worker roles, etc.), remote debugging and virtual machine creation capabilities , Emulator Express, Visual Studio interface extensions, Storage Explorer and Server Explorer extensions, integrated deployment using Web Deploy to the cloud, IntelliTrace and more .

The latest release of Azure Tools is supported by the following versions of Visual Studio:



Microsoft Azure SDK


To provide the functionality that the developer uses locally, the Azure SDK is required. The Azure SDK is not included in the .NET Framework by default and is installed separately .

The core components of the Azure SDK are the compute and storage emulator needed to run, debug, and test Cloud Services on a local computer, which is very convenient in the absence of an Internet connection.

The compute emulator provides a graphical interface for performing basic tasks of managing and viewing diagnostic logs of a working Cloud Service solution.



Some of the differences between a solution running in the emulator and running in the cloud are listed below, which means that some parts of the solution need to be tested in the cloud:


The full list of differences is available at the following link .

The storage emulator provides a local environment for modeling the three Azure storage services on the local computer - blobs, tables, and queues. The main mechanism of the local storage emulator is SQL Server.

Currently, the emulator's graphical tool is considered obsolete and will be excluded from the SDK in the future. Access to emulator functions is now provided by the command line.

Antivirus for Cloud Services


Not so long ago, Microsoft introduced an antivirus for Azure cloud services , providing real-time or scheduled protection, as well as providing information on your account attacks through Azure Diagnostics.

Antivirus in Azure is built on the same platform as Microsoft Security Essentials [MSE], Microsoft Forefront Endpoint Protection, Microsoft System Center Endpoint Protection, Windows Intune, and Windows Defender for Windows 8.0 and higher. And designed to work in the background.

The developer can customize the antivirus based on the needs of his solution, choose a real-time protection job or schedule a scan, run an update of the protections or collect information about malicious incidents.

Anti-Virus is installed by default on every instance of Cloud Services.
You can enable the protection service using the basic configuration or customize it as you wish. The default security service settings are already optimized to work in the Microsoft Azure environment. But you can also customize them according to the specifics of your particular solution.

Below is a general scheme to ensure the operation of the Microsoft Azure Antivirus tool for cloud services and virtual machines:



useful links


Source: https://habr.com/ru/post/242543/

More articles:


All Articles