Part 15 : Understanding Windows Azure Accounts and Subscriptions

In this tutorial we will look into the details of Azure account and subscriptions and see what exactly they mean. We will also see how to set the administrative roles to the users who need access to Azure to manage services.

Before going into the subject it is important to understand the user account to access Windows Azure, which is as usual an combination of email and password, used to authenticate users. Now user account, specifically User ID, comes in two forms : Microsoft accounts and organizational accounts.

• Microsoft accounts take the form <user>@outlook.com <user>@hotmail.com or <user>@live.com. It is good for single person but not for the organization.
• Organizational accounts take the form judy@contoso.onmicrosoft.com or judy@contoso.com, for    example. “Contoso” can be any domain name. Good for middle and large enterprise.

Organizational accounts are different from Microsoft accounts because they are sourced from Azure Active Directory. Because organizational accounts are created from within Azure Active Directory, you have more options for managing them. For example, Organizational accounts can be supplemented with multi-factor authentication, which requires the user to enter additional information to verify their identity.
So, as a general rule, use Organizational accounts whenever you need to assign administrative access to Azure. Every Azure subscription has a default directory that you can use to create organizational accounts.

In this tutorial I've used the microsoft account.

Windows Azure Account
Windows Azure Account is a shell to provide usage and billing reporting of the services. He is also the Account Administrator of that account.

Subscription
A Windows Azure subscription grants you access to Windows Azure services and to the Windows Azure Platform Management Portal. In order to deploy services and data to Windows Azure, you need a Windows Azure subscription. hey also help you control how resource usage is reported, billed, and paid for. Each subscription can have a different billing and payment setup, so you can have different subscriptions and different plans by department, project, regional office, and so on. Every cloud service belongs to a subscription, and the subscription ID may be required for programmatic operations.

Account Administrator
The Account Administrator for a subscription is the only person with access to the Account Center. (https://account.windowsazure.com/Home/Index)

They can create subscriptions, cancel subscriptions for their account, update the service administrator and co-administrator for an individual subscription. He is the person responsible for paying the subscription bill. Normally, the Account Administrator has financial responsibilities in your company. This person is also the default Service Administrator for the subscription.

The Account Administrator does not have any other access to services in that subscription; they need to also be the Service Administrator or a co-administrator for that. For security reasons, the Account Administrator for a subscription can only be changed with a call to Azure support. The Account Administrator can easily reassign the Service Administrator for a subscription at the Account Center at any time.

Service Administrator
Service Administrator are authorized to access Azure Management Portal for all subscriptions in the account.Normally, the Service Administrator is a developer, system administrator, or other IT person responsible for IT services in your company. By default, it is same as the Account Administrator when a subscription is created but can be changed later. The Service Administrator is the first co-administrator for a subscription. Like other co-administrators, the Service Administrator has management access to cloud resources using the Azure Management Portal, as well as tools like Visual Studio, other SDKs, and command line tools like PowerShell. The Service Administrator can also add and remove other co-administrators.

Co-Administrators
Imagine the scenario of large enterprise. There can be a big numbers of servers and application to manage and obviously a single person cannot handle it. This is the reason the service administrator can create Co-Administrators to help manage Windows Azure operations.

Co-administrators are identified by Windows Live ID.  Therefore, a person that you want to be a co-administrator of your subscription must have his or her own Windows Live ID.  If they do not have a Windows Live ID, they can create one at login.live.com.  Co-administrators have complete access to the subscription services.  They can even add or delete other co-administrators.  However, they cannot remove the Service Owner (the Service Administrator).  Also, co-administrators do not have access to payment/billing information (things managed by the Account Administrator).


Let's see an example of all of these terms.  I've sign up for free Azure trial account. I'll be the account owner (with my windows live ID username/pwd) of this account. I'm the Account Administrator for this account and by default I'm also the Service Administrator of this account.
Open Windows Azure Management Portal and scroll all the way down to "Settings" on the left side. After clicking on "Settings", go to the Administartor tab and you can see all the administrator listed for that subscription as shown in the image below.

 As I told you before by default, Service Administrator is same as the Account Administrator when a subscription is created. We can change the Service Administrator, but not from here. I'll show in a moment how to do that. You can see that the Service Administrator is the first co-administrator for a subscription.

To add a Co-Administrator , while still in Administrator tab under Settings, click on the add button at the bottom. A pop windows will get opened to add co-administrator.

Enter the email address of the co-administrator. Choose the subscription, here I only have the free subscription. The co-administrator must be either a Microsoft Account or a user account within the Default Directory directory. Click the OK button and the co-administrator will be created. You can add upto 200 co-administrator per subscription (in addition to Service Administrator).

- Co-administrators with an organizational account sign in to the portal using a password that they receive in email or that is provided by the system administrator.
-  Co-administrators with a Microsoft account sign in to the portal using the password for that account.

Crucial differences between the service administrator and co-administrators:

• Co-administrators can’t delete the Service Administrator from the Azure Management Portal. Only the Account Administrator can change this assignment at the Account Center.

• The Service Administrator is the only user authorized to change a subscription’s association with a directory in the Azure Management Portal.

To see all the subscriptions under your account, go to Account Center (https://account.windowsazure.com/Subscriptions) , or while still in Azure portal click on the account name on top right side and then click on "View my bill" , this will open Account center. Click on subscription tab and you can see all the subscriptions under your account. You can even add a new subscription from here.

Once you clicked on any subscription, you can see the details related to billing, usage, accounts related to that subscription. You can also edit some of the details related to account like Change Payment Method, Edit Subscription Details, Change Address, Cancel Subscription from here.

Let's see how you can change the Service Administrator. While still on the Subscription Summary page, go to the very end of the page, and there on the right hand side you can see a link to "Edit subscription details".
You can also see the account details in that section.

Click on that link and new pop-up windows will open that let you to change the Service Administrator.

Some best practices you should follow while creating subscriptions and administrators.

Part 14 : Windows Azure Web Sites - Scaling

In this tutorial we will see how you scale your website up or down depending on the needs.

Scalability is the ability of a system to handle a growing amount of work in a capable manner or its ability to be enlarged to accommodate that growth

When you start developing a new web application, or when you want to test your web application, or try out the Azure WAWS, you might want to start free and small. All web sites can deploy in a free hosting mode. Then as the traffic to your website increases and as the expectations for performance and availability increases, you can scale out to meet the needs of your business.

Also if your website is already in production and you have some period of time where you expect the hits go high, for example gift shopping website during the Christmas season, you can scale up for that period of time and then scale down again later.  Consider the situation where you have your own servers in datacenter, you have to provisions the servers for the peak load and most of the times the servers will be lying ideally but incurs cost to you. With cloud, this is great feature to scale up and down depending on your needs and can save lots of money.

By adding and removing role instances to your Windows Azure application while it is running, you can balance the performance of the application against its running costs. You can add new instances when demand is high, and remove instances when you no longer need them in order to reduce running costs.

For increased performance and throughput for your websites on Microsoft Azure, you can use the Azure Management Portal to scale your Web Hosting Plan mode from Free to Shared, Basic, or Standard.

Scaling up on Azure Websites involves two related actions: changing your Web Hosting Plan mode to a higher level of service, and configuring certain settings after you have switched to the higher level of service.

Each scale operation happens quickly – typically within seconds – and does not require changes to your site’s code, nor a redeployment of your site. Scale operation have no impact on existing user sessions.
You can also scale up or down programmatically by using the Windows Azure Management API.

Before moving forward let's see what exactly is meaning of scale up and scale out.

Scale Up
Also know as scale "vertically". You can scale up by increasing the processing power by adding more processors and RAM or buying a bigger, multi-core robust server.
Pros : Less licensing cost, less power consumption than running multiple servers, less challenging to implement.
Cons : If single server fails, it brings down the whole application, price.

Scale up operations can be performed on any site without worrying about the implications of multi-instances data consistency.
Windows Azure offer servers for web sites in multiple instance sizes of small, medium and large. Scaling up in Windows azure for web sites can be achieved by changing the instance size of the server, e.g. from small to medium.

Scale Out
Also known as scale "horizontally". You can scale out by adding more servers and adding a load-balancer to distribute the demand between them.
Pros : cheaper than scaling vertically, easier to run fault tolerance
Cons : More licensing fees, higher utility cost, complex to implement.

To scale out your site in windows azure, you need to just increase the instance count for that web site. This is very easy and we see it in practical shortly.  The big advantage with Windows Azure is that when you scale out a web site in Windows Azure Web Sites there is no need to configure load balancing separately since this is already provided by the platform.

To benefit from scale OUT operations your site must be designed for concurrency. You should plan for the shared state so that request from particular user can be handled by any server under the load-balancer. Or use sticky session. Sticky session means that when a request comes into a site from a client all further requests go to the same server initial client request accessed. Load balancer will usually handle this.

One thing to understand regarding scale out is that even they can increase the total amount of traffic capacity that your site can handle, it does not always improve performance in the way that scaling up does.

Scale up and scale out operations can be combined for a website to provide hybrid scaling. The same contentions about multi-instance sites would apply to this scenario.

Let's start with a free website and we will scale it using Windows Azure Management Portal.

Scaling of Free website to Shared or Basic mode
1. Open Management portal and create a website in free mode (if not already created). Assume that your      website is currently in development mode and this is the reason we choose free mode.

 2. In the website listing page, click on the site and then go to "Scale" tab.

 3. Currently the website mode is free. Now our website goes into a test phase where business users and stakeholders are going to test the website. So we are going to scale it to Shared mode. The Web Hosting Plan Sites section shows a short list of sites in the current plan. All sites in the current plan will be changed to the Web Hosting Plan Mode that you select. Click on the Shared mode. Under capacity let the instance count be 1 instance and click on save. Note that in free mode you cannot change the instance count.

So now effectively we have scaled up the website to shared mode. 

4. Now testing is done and accepted by business users. We want to roll out the pilot site for several hundred users and we want  the website to available for most of the time. What we can do is to let the site remain in shared mode but increase the instance count. Again go to website and then scale tab and then in the instance count make it 3. You can scale out to maximum of 6 instances. Windows azure will automatically configure load balancer for you. Notice that in shared mode you can increase the instance count but not the instance size, because it is fixed in shared mode. So you can scale out but not scale up.  Also note that while changing the web hosting plan mode will change all the website under that plan , changing instance count will not affect the instance count of other sites in the same web hosting plan mode. 

Still confused :) try it out yourself and you will understand.

 5. Now our pilot phase is well received by audience and we want to go into production. But we don't want to go into production in shared mode. So we want to change it to Basic mode so that we will have dedicated servers serving only our website. Go to the scale tab again and this time choose the web hosting plan mode as Basic. You notice that there will be one more configuration item available "instance size". Now since we have our own reserved server, we can also choose the right fit size that we want. Since I just launched my website I want to start with medium size server and two of them to support availability. This is the example of hybrid scaling where we both scale up and scale out. 

Also notice that changing the instance count or size will change for all the sites in web hosting plan, which is little different that shared mode as described above.

6. Now suddenly the management decided that there are some serious business flaws in the current website and they want to fix it but at the same time they don't want to incur cost during that time. Easy, just go to scale tab again and choose the web hosting plan mode as "free" and start your development.

So we have seen how easy it is to scale up or down as required in Windows Azure and these changes take only seconds to apply.

Scaling Website to Standard Mode

Before going into this topic lets discuss Auto-scaling briefly. One of the key benefits that the Windows Azure technology platform delivers is the ability to rapidly scale your application in the cloud in response to changes in demand. If you rely on manual interventions to scale your application, you may not always achieve the optimal balance between costs and performance; an operator may respond late, or underestimate the number of role instances that you need to maintain throughput. An autoscaling solution reduces the amount of manual work involved in dynamically scaling an application. It can do this in two different ways: either preemptively by setting constraints on the number of role instances based on a timetable, or reactively by adjusting the number of role instances in response to some counter(s) or measurement(s) that you can collect from your application or from the Windows Azure environment. We will see the autoscaling feature in this topic.

NOTE: Before switching a Web Hosting Plan to Standard mode, you should remove spending caps in place for your Microsoft Azure Websites subscription. Otherwise, you risk your site becoming unavailable if you reach your caps before the billing period ends. 

1. To scale to Standard, follow the same initial steps as when scaling to Shared or Basic, and then choose Standard for Web Hosting Plan Mode. As before, the Web Hosting Plan Sites section shows a short list of sites in the current plan. In this case, all sites in the current plan will be changed to Standard mode.

2. Selecting Standard expands the Capacity section to reveal the Instance Size and Instance Count options, which are also available in Basic mode. The Edit Scale Settings for Schedule and Scale by Metric options are available only in Standard mode.

3.  Configure the Instance Size and instance count as we have seen before.

4.  If you want to automatically scale (autoscale) resources based on daytime versus nighttime, weekday versus weekend, and/or specific dates and times, choose Set up schedule times in the Edit Scale Settings for Schedule option.

5. A new dialog box called "Set up schedule times" will open.  The Set up schedule times dialog provides a number of useful configuration choices. These options let you define different scale settings during weekdays or weekends.

First checkbox is "Different scale settings for day and night". This creates two schedules. The first schedule runs from the start of the day to the end of the day. The second schedule runs from the end of one day to the start of the next day, and uses the options below to define times and the time zone.

Second checkbox is "Different scale settings for weekdays and weekends". This creates a separate profile that starts on Friday evening and ends on Monday morning. Use the options below to define start times, end times, days, and time zone.

Under Recurring Schedules, select Differing scale between Day and Night and/or Differing Scale between Weekday and Weekend to scale resources based on separate daytime and nighttime schedules and/or separate weekday and weekend schedules. For the purposes of this feature, the weekend starts at the end of day Friday (8:00 PM by default), and ends at the beginning of the day on Monday (8:00 AM by default). The weekend profile uses the same day start and end that you will define in the Time setting. 

Under Time, choose a start and end time for the day in half-hour increments, and a time zone. By default, the day starts at 8:00 AM and ends at 8:00 PM. Daylight Savings Time is respected for the time zone that you select.

Under Specific Dates, you can create one or more named time frames for which you want to scale resources. For example, you may want to provide additional resources for a sales or launch event during which you might have large peaks in web traffic. Please note that this will override your other scale settings.

After you have made your choices, click OK to close the Schedule Times dialog box.

6. The Edit Scale Settings for Schedule box now displays configurable schedules or events based on the changes you made. Select one of the recurring schedules or specific dates to configure it.

You can now use the Scale by Metric and the Instance Count features to fine tune the scaling of resources for each schedule that you choose.

7.  To dynamically adjust the number of instances that your website uses if its load changes, enable the Scale by Metric option by choosing CPU.

The graph shows the number of instances that have been used over the past week. You can use the graph to monitor scaling activity.

8. Scale by Metric modifies the Instance Count feature so that you can set the minimum and maximum number of virtual machines to be used for automatic scaling. Azure will never go above or below the limits that you set. This enable you to proactively set the number of role instances that your application can use; the minimum number of role instances helps you to meet your service level agreement (SLA) commitments, the maximum number of role instances helps you to control the running costs of your Windows Azure application.

9. Scale by Metric also enables the Target CPU option so that you can specify a target range for CPU usage. This range represents average CPU usage for your website. Windows Azure will add or remove Standard instances to keep your website in this range.

Note: When Scale by Metric is enabled, Microsoft Azure checks the CPU of your website once every five minutes and adds instances as needed at that point in time. If CPU usage is low, Microsoft Azure will remove instances once every two hours to ensure that your website remains performant.

Part 13 : Windows Azure Web Sites - Basics 2 - Web Hosting Plan mode

Windows Azure Region
We have seen in the previous tutorial that we have to select the region while creating a website in Windows Azure Management portal. Windows Azure uses the idea of regions to manage the physical distribution of your applications and data. A region represents a Microsoft data center where you can deploy your application. There are many regions available in Windows Azure like Asia, Europe, North America and it keeps on increasing.


Choosing a region will have direct impact on Network Latency. You want to deploy your application to the data-center that is closest to your user base. Also you want to replicate your data across multiple regions so that if one region or data center is offline, your application still be available. Windows Azure have options to deal with this (Traffic Manager, CDN) and we will learn  that in later tutorial.


Web Hosting Plan Mode
Web Hosting Plans can be shared across multiple web sites. Each plan has a mode associated with it. Different modes expose different sets of features and capabilities. Currently Azure Web sites is offered in four modes for hosting your websites : Free, Shared, Basic and Standard.

Shared mode is in preview feature as time of writing.  Plans in the Free and Shared modes run on a shared infrastructure with sites managed by other customers. These sites will have strict quotas for resource utilization. Plans in the Basic and Standard modes run on resources that are dedicated to your sites and have fewer restrictions.

Free
Free is the default scale for any website that is newly created in Windows Azure Websites.You can run upto 10 free websites in this mode. In Free mode your website is hosted on the same Virtual Machines as other sites (also known as multi-tenant hosting environment) and you cannot scale a single website on multiple web servers.  So the same server where your website is hosted can  be shared by many different websites. Shared means each website is taking up some amount of memory and utilizing some portion of the CPU.

Using this free mode, you can start your development and testing of websites at no cost at all. Obviously "free" comes with some limitations. In this case you can run websites that can serve 165MB of outbound traffic per day(5GB/month) , 60 minutes of CPU per day, per region. Storage is limited to 1GB.

Also with free mode, you cannot assign custom domain to the site. With free mode the site name will always be <sitename>.azurewebsites.net.

And yes one more thing, free site does not have any SLA.

Free mode is generally used by developers and testers during development.

Shared (Preview Mode)
Hosting website in this mode reduce some of the restrictive quotas associated with Free Mode, but computing resources are still shared.  Your website will still be hosted on the same Virtual Machine as other sites. In the Shared mode your CPU usage quota is 4 hours per day with storage limited to 1GB. The first 5 GB/month of bandwidth you serve with a shared web-site is free, and then you pay the standard “pay as you go” Windows Azure outbound bandwidth rate for outbound bandwidth above 5 GB.

You can scale out your website to maximum of 6 shared instances. Windows Azure will automatically configure load balancing for it.  In shared mode, you can set up multiple custom domain for your website rather than stuck up with .azurewebsites.

The price for the Shared tier during preview is $0.013 per hour (~$10/month). This price reflects a 33% preview discount.

Shared website also don't have any SLA.

Shared mode is good for personal sites or for the sites that doesn't have large amount of traffic and can withstand some duration of down time in case of crossing the quota.

I would like to point out here that it is very essential to have put quota on Free and Shared mode, so that one website should not eat up all the memory or dominate the CPU. And when I said CPU usage quota is 1 hour per day, that doesn't means that your website can be up only for 1 hour per day. That actually means is that your website can use 1 hour of CPU time in 24 hours. Your website needs CPU cycles only when it is serving some page requests, provided it's not coming from cache. Each request uses only seconds of CPU time. So it may be possible that your website is up for hours if traffic is low or use the quota in minutes if traffic is very high.

Remember that both in Free and Shared mode, once you cross the quota, any request to your website will be redirected to a page that tells that this site has exceeded the quotas. If this is your mission critical website or any website that generates revenue, you don't want this to happen. In this case you need to go for either Basic or Standard mode.

Basic
In Basic mode, you websites are guaranteed to run in a seperate VM which is dedicated for your website.
This option removes any need for the memory and CPU quotas since you are the only tenant on the machine.
You can choose the size of the VM Small, Medium or Large VM and you can run any number of web-sites within a VM. The storage is increased to 10GB for all your websites. You can also set up multiple custom domain for your website

Note that with this option all your website in that region or datacenter are hosted by the same reserved instance. There is no per site cost  in this mode. You pay only for the reserved instance you use and you can run any number of websites in that instance. You can choose between the small, medium or large instance.
So lets say you have very high traffic websites that require 2 large VM instance and another site with very low traffic, both will enjoy the benefit of 2 instance if they are in the same data-center(region).
So basically even though you are paying more, you can save by deploying multiple websites on an instance that is dedicated to you.


You can run sites on a single reserved VM instance or scale up to have multiple instance all running your websites. You can scale upto 3 dedicated VM instances. You can also scale up a single instance by increasing the size of your VM instance (small to medium or large). Windows Azure will automatically configure load balancing for it.

Standard
Everything we say about Basic mode is applicable to standard with more quota and features. In standard mode also, your websites run in a separate VM without any quota for CPU and memory. You can run any number of sites in that reserved instance. The storage is increased to 50 GB and Custom domains are supported.

You can choose between small, medium or large instance. You can scale up to 10 dedicated instances. You can also scale up a single instance by increasing the size of your VM instance. Windows Azure will automatically configure load balancing for it.

One of the biggest feature of Standard mode is Auto Scale. In other modes, you have to manually monitor the traffic and scale up or down based on the traffic (we can scale up or down through Windows Azure Management Portal, i'll show this in just a moment). Auto Scale allows you to dynamically adjust the capacity based on the load your websites is experiencing. You can set rules to trigger the scaling of your instances. For example, you can set a trigger that if CPU becomes overloaded , add one more instance, or you can also schedule it, on weekends increased the number of instance to 4. You can auto scale up or down your instances.

Also note that if you choose an option of reserved instance, all your websites under your subscription will be moved to the reserved instance. You don't have an option to run some websites in shared mode and other in reserved mode. If you wish to do that, you have to divide the websites in different subscriptions.


In the next tutorial we will see how we can scale websites up and down depending on our needs.