Overview

Azure Cloud Services is an example of a PaaS.
- In the same way that App Service is hosted on virtual machines (VMs), so too is Azure Cloud Services.
- However, you have more control over the VMs.
With Azure Cloud Services, you don't create virtual machines.
- Instead, you provide a configuration file that tells Azure how many of each you'd like, such as "three web role instances" and "two worker role instances."
You can install your own software on VMs that use Azure Cloud Services, and you can access them remotely.
- More control also means less ease of use.

Azure Cloud Services Roles

Web Role: Automatically deploys and hosts apps through IIS.
- A simple application might use just a single web role, serving a website.
Worker Role: Runs the app standalone.
- A more complex application might use a web role to handle incoming requests from users, and then pass those requests on to a worker role for processing.
  - This communication might use Azure Service Bus or Azure Queue storage.
All the VMs in a single application run in the same cloud service.
Users access the application through a single public IP address.
- Requests are automatically load balanced across the application's VMs.

Cloud service is created from three components, the service definition (.csdef), the service config (.cscfg), and a service package (.cspkg).
Both the ServiceDefinition.csdef and ServiceConfig.cscfg files are XML-based and describe the structure of the cloud service; collectively called the model.
The ServicePackage.cspkg is a zip file that is generated from the ServiceDefinition.csdef and among other things, contains all the required binary-based dependencies.
Azure creates a cloud service from both the ServicePackage.cspkg and the ServiceConfig.cscfg.
Once the cloud service is running in Azure, you can reconfigure it through the ServiceConfig.cscfg file, but you cannot alter the definition.

This file specifies the settings that are used by Azure to configure a cloud service.
Endpoints fall into two categories:

Input Endpoints: are exposed externally.
- Input endpoints can specify both a port and local port
- This will map traffic from the external port to a different port local to that instance.
- Input endpoints can also be specified at the individual role level, in which case they are called an instance input endpoint.
- Web roles require at least one input endpoint using http.
- Standard input endpoints can use http, https, udp, or tcp protocols.
- Instance input endpoints only operate on tcp and udp protocols.
Internal Endpoints: communicate only to other Azure roles.
- The port is optional; when omitted the port is assigned dynamically (from a range if one is provided).
- Internal endpoints can communicate over http, tcp, or udp protocols, and there is a limit of five per role.

In addition to creating the endpoints in the configuration file, you can specify network rules that will restrict which roles can talk to each other.
The configuration of the endpoints is pretty trivial, requiring just a name, protocol, and a port.
**csdef Template**