November 7, 2014 at 12:27

A detailed description of development opportunities 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 work roles (web role, worker role) for distributed processing of requests or data.

    So, the introductory definition: Cloud services Microsoft Azure is the ability to create multi-component applications, somewhat rethought in the direction of the role model and flexible scaling.

    For example, when the load increases, you can scale only the server-side handler, but leave the number of web frontend instances.

    Note:
    General points and the main differences between Cloud Services and Web Sites, how each of the services implements a particular function or scenario 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).
    • Presentation (Web user interface);
    • Controller (Business Logic Layer);
    • The data source access layer.



    Access to the application is carried out by the endpoint access point (HTTP or HTTPS).

    • The view changes its name to a Web role ;
    • Controller - on the Worker role ;
    • The data source access layer can be implemented inside a separate Worker role.


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

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

    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) will mean that the entire system is inoperative and the data will be lost, the developer can use Middleware in Brokered Messaging mode.

    This means that the web roleit simply puts messages in the Middleware service (in the queue), where they are stored until the garbage collector deals with them, or until they are processed by the Worker role instances.

    At the same time, the Web role does not have a clue about how many handlers 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 specifically provided for).

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

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

    This means that by clicking on the link to the Web site, the user can get to the first instance of the Web role, as well as to any other one located in the rotation of the load balancer .

    The types of roles and their main characteristics are described in detail below:



    • Web role . The web role contains a set of server instances with virtual machines on which IIS 7 / 7.5 is installed and by default several standard HTTP access ports are open. Web role security is ensured by a certificate bound to any HTTPS entry point.
    • Worker role. A worker role contains a set of server instances with virtual machines that run business logic, usually retrieving data for their work from a web role.
      By default, incoming connections to a virtual machine on an instance of a Worker role are denied.
      Worker role projects use the following software model — inheriting from RoleEntryPoint, a class that implements the business logic of the Worker role implements three methods:
      1. OnStart () - called when the role starts, returns the “Busy” status to the load balancer until otherwise indicated;
      2. Run () - runs continuously, contains the main logic;
      3. OnStop () - performed when the role is disconnected, 30 seconds and can be used to close connections, delete objects, etc.



    To ensure the continuous operation of the service during the upgrade, as well as to meet the requirements of the service level, you must define at least two instances of each role.

    Cloud Service Configuration


    To describe the configuration, by Cloud Services we mean the project, i.e. A collection of files that describes a cloud service. This project can be used in Visual Studio.

    So, the configuration consists of two XML files:

    • Service definition file (Service Definition file, with the extension .csdef). Specifies the settings that Microsoft Azure uses to configure the cloud service (roles, entry points, and configuration settings without predefined values).
    • Service configuration file (Service Configuration file, with the extension .cscfg). Contains immediate values ​​for various parameters, for example, the number of server instances that will serve a specific role.

    Microsoft Azure configuration files also have the ability to set two parameters that indicate the version of the operating system that will serve the deployed service. The first parameter is the "family" of the operating system, the osFamily attribute, the second osVersion is the "version" of the operating system.

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

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

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

    Environment


    Each instance of Cloud Services provides the developer with two locations for the deployed solution - Production and Staging , which are used for the version that works 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 in the 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 , for Staging, a temporary DNS name of the following type is createdhttp: // [guid] .cloudapp.net .

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

    Thus, without any transfers and migrations, in a few minutes, the solution from the Staging cell goes 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, incidentally, is not available to the end user.



    Cloud Service Scaling


    For Microsoft Azure Cloud Services, it is possible to automatically scale based on the 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 you about the need to perform scaling for the cloud service.

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



    Scaling based on the number of messages in the queue in the queue is conveniently used 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 or excluded from the availability group.

    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 beneficial to scale the database used by the application as well. 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 in the last hour. Therefore, the engine can initiate the 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 participation of the Azure management portal using the REST API.

    Azure Tools for Microsoft Visual Studio


    The Azure Visual Studio Toolkit 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 creating virtual machines , 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:

    • Visual studio 2012
    • Visual studio 2013
    • Visual Studio Express 2012 for Web
    • Visual Studio Express 2013 for Web


    Microsoft Azure SDK


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

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

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



    The following are some differences between a solution running in the emulator and running in the cloud, which means that it is necessary to test some parts of the solution in the cloud:

    • The emulator supports a limited number of roles and instances. The maximum number of deployment roles is 50.
    • The emulator provides administrative solutions for running solutions, while a solution running in Azure does not have administrator rights by default.
    • The emulator does not fully simulate load balancing.
    • The emulator uses IIS Express, and in Azure, IIS.
    • In a calculation emulator, all roles are performed on the local computer, while in Azure, roles are performed on separate virtual machines.

    A complete list of differences is available at the following link .

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

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

    Antivirus for Cloud Services


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

    Azure antivirus 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 configure the antivirus based on the needs of his solution, choose the protection in real time or scheduled scans, start updating protection tools or collect information about malicious incidents.

    Anti-virus is installed by default on each instance of Cloud Services.
    You can enable the protection service using the basic configuration or configure it as you wish. The default security service settings are already optimized for use in the Microsoft Azure environment. But you can also customize them in accordance with the specifics of your solution.

    The following is a general outline of how the Microsoft Azure antivirus tool works for cloud services and virtual machines:



    useful links


    Tags:

    Also popular now: