Ian Hardenburgh explains why developers of Azure applications can more easily manage their own applications without having to pass it off to system or network administrators.
When compared with your more traditional on-premise Windows setting, often managed by a well-rounded and diversified IT staff, many find it hard to believe that Windows Azure can prove to be just as, if not more, sustainable as a hosted solution. Furthermore, for many developers, building distributed Windows applications can appear as an entirely separate endeavor than supporting the hosted environment for an application deployment. However, the truth of the matter is that Azure strives to afford developers the capacity to manage their applications on their own — a job function once exclusively occupied by private data center networker and system engineer personnel. This kind of manageability is coupled with Azure's high availability, as Microsoft administrates failover management without much intervention needed on the developer's part. By understanding a few key components to Windows Azure, any developer can venture to not only position applications under this enterprise-ready service, but also maintain and fine-tune with enterprise-level performance.
One doesn't need to do much to get started with what is known as a role. A role can be viewed similarly to an IIS arranged deployment, where virtual servers are being designated by HTTP ports that redirect Internet client requests to a virtual directory containing application files. DNS customization can then be assigned, so users can refer to your public URL, including use of subdomains for any given published application (see this site for more details).
Configuring your role instances to the desired scale and operability is done through the creation and configuration of what are known as the service definition and configuration files. Both of these XML files can be managed through an intuitive web-based interface called the Windows Azure Management Portal. Under the service definition file, one declares the desired size of each instance in respect to CPU, RAM, disk space and network I/O. Of course the higher you scale your instances, the more it costs (see my "Windows Azure pricing demystified" post, or the Windows Azure Pricing page, to get a sense for how Azure pricing works). Outside of specifying VM size, the service definition file is also used to set protocol and connectivity attributes, as well as startup tasks. The service configuration file is simply used to define the OS version of a role instance that you wish your code to run on top of, as well as for the creation of connection strings, in order to connect to SQL Azure and Windows Azure Storage.
In order to understand and appropriately distribute incoming traffic to one's hosted instances; the Windows Azure Traffic Manager can be utilized. More pointedly, a developer could implement different load balancing policies to enhance performance by reducing network latency, route or distribute traffic evenly across your instances, and select a backup instance in the case where the a primary instance goes offline.
In the past, Windows OS and web server administration could have proved to have been too tedious, or even somewhat esoteric, to your average developer. The underlying strategy Microsoft has largely embarked upon with their Azure hosted solution is to simplify management of application deployments, by limiting configuration as much as possible, without limiting scalability. Furthermore, they understand the needs of their community, which is predominately made up of developers, as exemplified by the abundance of online resources (a great place to start is here). Developers can now feel confident to expand their roles beyond just development, by choosing Azure as their hosted environment.