6 Using Peripheral Features with Windows Azure Web Sites

There's a certain sort of allure to staying in a hotel. Hotels are like little homes you get to stay in when you can't be in your own, and you don't get into too much trouble if you leave the bathroom messy in the morning. You always come back to a made bed, even if you didn't make it before you stepped out. There's unlimited ice down the hall and you don't have to make the ice cubes. Brilliant.

Not everything you do in your project will deal exclusively with your website. Often you'll have other Windows Azure assets associated with your project and it would be nice to have these easily accessible through the portal. Very few projects lack some kind of database connectivity, and when you have a database involved, you want to be able to get to your data.

So, what do hotels have to do with Windows Azure Web Sites? Maybe more than you think, so stick with me to the end to see where this goes, and don't forget to tip the concierge.

SHARING ADMINISTRATIVE RESPONSIBILITIES

When you check into a hotel you get a key to your room that enables you to come and go as you please. The only other people who can get into your room are people with implied trust — folks that make up part of the cleaning team, or a bellhop that brings your bags to the room for you. If you are expecting a parcel, you can talk to the front desk and arrange to have it brought to your room in your absence by a member of that trusted group.

You also have control over explicit trust. When you want to let someone you trust into your room, you can request a second key to allow them entry and exit privileges as they please, knowing full well that when you are not there, they have the run of the room. They might watch movies, order room service, or even sneak treats from the in-room snack bar. You would be responsible for any charges they incur.

Co-administration in Windows Azure works much the same way. Many hands make light work, and the duties of creating, publishing, monitoring, and maintaining Web Sites certainly qualify as work. It's reasonable to assume that administrators will come across scenarios in which having another set of hands — or several — makes sense for their environment.

Administrators are associated with a subscription and are granted permissions at one of two levels:

• Co-Administrator — Has permissions to create, modify, and manage Azure assets as well as manage other co-administrators on the subscription; and can create support requests through the Windows Azure support portal that relate to the subscription.
• Service Administrator — Has the same rights as a co-administrator, but can also view or modify billing information. This is the owner of the subscription and can't be removed by a co-administrator.

There's not much you need to do to allow someone else to jump in and help you with the duties, as shown in Figure 6-1. Adding someone else to your account is as easy as typing that person's e-mail address into the UI, which you can access by following these steps:

1. Open the Settings workspace in the portal.
2. Navigate to the Administrators tab.
3. Click the Add button in the command bar and fill in the details.

The portal contains basic controls for editing related accounts and administrators. Note that anyone who adds you as a co-administrator will appear in your list of administrators, but they are not granted any permissions to your subscriptions by default.

When you have access to more than one subscription in either role, you'll notice subtle changes throughout the Windows Azure portal. When you create a new asset of any kind, when you create support tickets, or when you're managing co-administrators on a subscription or subscriptions to which you've been granted access, you'll see a dropdown list from which you can select the account to which the item is to be associated. In other areas you'll see the subscription noted to help you differentiate which assets belong to which subscription. You'll also see a change in the main menu, as shown in Figure 6-2, enabling you to filter items in any of the lists in the portal by subscription.

The filter also allows you to search your active subscriptions, quite handy if you want to build a business around managing cloud infrastructure for others. If your organization's cloud strategy includes several active subscriptions, this is also a great feature to isolate augmented services or overage charges for billing purposes.

Understanding the Scope of Trust in Co-Administration

Be aware that trust is extended to you only while you exist as an administrator on the other person's account. This is, of course, reciprocal, but there are implications on your end. Returning to the hotel analogy, if you've been given someone else's room key and you put all your stuff in their room, you are accepting the fact that if they tell the front desk to revoke your key you're not getting your belongings back that easily.

The same principle applies to items you create and contribute to in Windows Azure:

• Sites created under someone else's subscription become their property. It doesn't matter if you create all the assets, architect the data design, write every single line of code, and are the only person who has ever published to the site; if you create a website under their account, it belongs to them as far as Windows Azure is concerned.
• There is no way to move a site from one subscription to another. I call this the “Vegas” clause, because a website created on a subscription stays on a subscription. You can't port an asset from one subscription to another without opening a support ticket. Beyond the scope of shared administration, this is true even if you own both subscriptions.
• Access to sensitive data is shared between administrators on the account. There is currently no way to grant someone publishing and scaling permissions but restrict them from other aspects of the administrative portal. If you have permission to access the dashboard of a Windows Azure Web Site, you can see the database connection strings and linked resources, reset publishing credentials, or view log files.
• You have permission to affect permissions. Pay attention to the permissions you are administering and be aware that if you remove your own permissions you won't be able to add yourself back. Be cognizant of the changes you are making so that you don't inadvertently grant undue access to others’ subscriptions.

While these are good cautions to keep in mind, they are not inherently bad things nor reasons to avoid co-administrative duties. You have other ways to provide and restrict access and you don't have to share your subscription information with others if and when it's not appropriate.

Avoiding Shared Administration

There are two scenarios in which you'll likely need a way to restrict access to either your subscription or a particular site. Administration is an on/off switch with no middle ground and yet in some situations you'll want to have someone help with a site (monitoring, scaling, database, or other linked resource management) or publish to that site. Said another way, you have to decide whether you want to give someone a room key or just have them leave your package at the front desk. You have two solid options to isolate the site itself or restrict the developer to administering only a specific site:

• You manage several Windows Azure projects, sites and assets, but want to share administrative duties on one of them. This scenario can be managed by creating multiple subscriptions. Fees on Azure are accrued based on usage and overages tied to specific properties. There are no costs to holding multiple subscriptions, and by creating a subscription for a single project you can easily add and remove other administrators without granting them access to all the items in your account. In the hotel analogy this is the same as giving a trusted person a key to only the room that you want to let them into.
• You want to maintain administrative control of the site but grant publishing access to other project contributors. This is actually something that can be handled outside of Windows Azure Web Sites. Configure your site for automated deployments from source control as demonstrated in Chapter 3, and then grant access to your repositories as required. Working in distributed source control systems such as TFS, GitHub, or Mercurial, you can further restrict access by using a fork/pull request model, which I have found to be a great solution for open-source projects. Your source control system becomes the bellhop, only granting access to the bits that you approve of through a trusted source.

The model you choose will obviously be based on the level of trust that you have in working with the team or individual with whom you are sharing the responsibilities; and remember that you can always start with the bellhop and upgrade to the room key if it makes sense in your context, keeping in mind the implications of sharing your subscription with other administrators noted earlier.

MANAGING YOUR LINKED RESOURCES

Many hotels offer a great option for traveling families: two side-by-side rooms — one for the parents, one for the kids — with a door that connects them. If the children are up late misbehaving, you don't have to skirt out into the hallway to settle them back down. Both rooms are fully functional in their own right, and the door between the two isn't always needed. You can, in fact, enter either room from the hallway even if the in-room passage is locked or not there at all.

Linked resources in Windows Azure are much the same. No technological changes are made to either of the assets when you create a link, and deleting one item or removing a link between them doesn't change the function of the other. The assets you have associated will appear under the Linked Resources tab on your website dashboard, as shown in Figure 6-3. When you create a link you're simply making it easier for yourself to navigate between them or to more easily scale and monitor the resources that are being used.

If, for example, you are going to use Windows Azure SQL Database with your website, you can create a link to the database that enables you to easily navigate to the database dashboard from the website. The connection string for the database, which you'll still need to wire into your project, appears on the website's dashboard. While Windows Azure SQL Database instances are managed in a separate yet similar interface, you can effortlessly traverse the cloud and into the Database workspace simply by clicking the name of the database from the linked resources list.

Note in Figure 6-3 that not all links can be used for navigation. Azure properties, such as Windows Azure Storage accounts and Windows Azure SQL Databases, have connected or integrated interfaces into the Windows Azure Management portal, and an HTML link allows you to click through to those interfaces. A MySQL database hosted with a third-party provider does not share the same facilities. In this case, you create a separate login for the external resource and administer it through the provider's own interface (for MySQL the default provider is ClearDB).

There are currently three ways you can create linked resources for your website in the Windows Azure portal:

• When you create your website — Creating a new “custom site” or choosing to create a new Web Site through one of the templates in the gallery may link one or more resources to your site. The most common will be a database.
• Through the Linked Resources listing on your Web Site dashboard — From the dashboard you can choose to add links to new databases and storage accounts, or you can create links to existing Windows Azure assets.
• From the Windows Azure Add-on store — Some services can be added first through the store, then later added as a linked resource to your site. For those that can't be linked, you can still manage the add-on from the Add-ons workspace in the portal.

Don't spend too much time worrying about a particular service, storage account, or add-on not being available as a linkable resource. Although links can be convenient, they only serve as a convenience in the portal and don't automatically integrate the resource into your project; you still need to do the heavy lifting.

WORKING WITH WINDOWS AZURE SQL DATABASES REMOTELY

You're not always going to be in the portal; and quite frankly, the portal interface won't always be the best tool for the job. Databases are a critical part of today's website development process, and developers on the .NET stack are likely going to favor some flavor of MS SQL. When you're building your application with the goal of targeting cloud deployment, Windows Azure SQL Database will probably be part of your development strategy, and working locally affords more features than the portal version can provide.

You will have to make some compromises to adopt the Azure version of SQL, but compromises can be positive things too. What you give up is mostly related to physical management, such as file groups, initial provisioning, and limitations to the backup/restore process. The gains, on the other hand, can be quite significant when you consider the high-availability model of cloud infrastructure, simplified management, and scalability, which enables growth as your business grows.

Ultimately, the goal here is to make a connection from Microsoft SQL Server Management Studio (SSMS), and you will need to use version 2008 R2 or greater to do so. These tools can be downloaded free from Microsoft at www.microsoft.com/en-us/sqlserver/default.aspx and follow the links for the Express Edition if you don't already have the tools installed.

Opening the Firewall

There is a high-security model in Windows Azure that allows connectivity only between other Windows Azure assets in your account, and this model extends to Windows Azure SQL Database. You'll need to poke a hole in the firewall and allow your IP address or a range of IP addresses if you want to access the database remotely.

Granting access to your IP address is typically a simple 19-step process requiring approvals from fewer than a dozen folks in your organization — except not on Windows Azure! The process is actually quite straightforward, and you have a couple of options to execute, the first being through the Windows Azure Management portal itself:

1. Navigate to the dashboard of the database in question. The easiest way to do this is through the linked resources of your website, but you can also find it in the database workspace.
2. Click “Manage allowed IP addresses.” You can find the link under the Quick Glance section on the database dashboard.
3. Confirm the current address to add to the list of allowed IP addresses. Your current public IP will be displayed in a textbox near the top of the page. Click the confirmation arrow to add your IP to the list, or modify the range of IP addresses (if you're in a dynamically assigned pool of IPs).
4. Save the updates to the configuration of your database. The save icon appears in the command bar after making any changes to this screen.

With the firewall rule in place, you are ready to make your remote connection.

Establishing Remote Connections

The process to connect to a Windows Azure SQL Database is largely the same as that for a traditional SQL instance; you'll need to know the server name and have SQL credentials to log in (Windows Azure SQL Database does not support Windows Authentication). Everything you need can be gained from opening the View Connection Strings link in the Quick Glance section of your website's dashboard, as shown in Figure 6-4. The information is equally available through the dashboard of the database itself.

With this information in hand you can complete your connection. Again, you can use SSMS for SQL Server 2008 R2 or greater. Though the UI style is updated in 2012, the field names and required fields are the same in both editions. Use the connection information that you gathered from your website dashboard to fill in the Connect to Server dialog displayed in Figure 6-5.

One of the things that I've run into when moving quickly is specifying a database name instead of the server name, or not following the correct convention for the username when specifying the credentials. For this reason, I've included both the connection string information in Figure 6-4 and the dialog in SSMS in Figure 6-5 so you can see these details as they translate from one to the other.

After you have entered these details, click the Connect button to get your session set up. You'll then be able to use the following features of SSMS with your Windows Azure SQL Database:

• Create new databases on the server to which you're connected.
• Create queries against any of your existing tables.
• Modify the schema of existing objects.
• View, manage, or create logins for the server.
• Create, manage, and deploy data-tier applications using DACPAC files to define schema and help create migrations.
• Create local backups of your SQL Azure Database and restore them on your own instance of SQL Server through the use of BACPAC files.

There's so much more you can do with Windows Azure SQL Database, including creating and restoring backups through storage accounts, migrating SQL Server Database Engine data out to the cloud through UI or programmatically using BACPAC files, scaling and monitoring, and more. If you will be working with Windows Azure SQL Database on your project, consider reading Windows Azure Data Storage, 978-1-118-70883-5 (Wrox, 2013) in this cloud series.

SUMMARY

Sometimes the most important aspects of a project are the ones that live in the wings, the ones that you don't need to touch very often but are critical when you do. At those times, it's important to be able to access them freely and easily, and to call in help when needed.

Windows Azure provides numerous ways to access and manage the assets related to your websites. You can leverage assistance from trusted administrators, share administrative duties, or restrict access as required to help deploy and maintain your website. If the need arises, you can drill into your database using local tools to query, create backups, or modify schema using tools you're likely already aware of as a web developer.

With these administrative tools in your belt, it's time to check out of this chapter and into the next — a world of configuration, transformation, and scale.