ADMIN

Many Machine Learning solutions have the same steps in common. For example, you will need to retrieve data from one or more sources; you will want to split your data into training and testing subsets; and you will want to clean up your source data. I refer to these as "plumbing tasks” because they are common to so many projects; and spending time coding these tasks takes time away from working on your data and your solution.

Azure Machine Learning Studio can help.

Azure Machine Learning Studio or "ML Studio" is a graphical design tool for building machine learning solutions. It includes a design surface and a set of shapes to perform specific tasks.

To work with ML Studio, drag a shape onto the design surface, set some properties, and connect the inputs and/or outputs to other shapes to build the workflow of your solution. For example, you can drag an "Import Data" shape onto a form and set information about the data source and data type. This is "plumbing" code that you do not have to write.

If a shape for a desired task does not exist, there are shapes that allow you to write custom code. Supported languages are Python and R.

When you finish building and testing your solution, buttons at the bottom allow you to configure and deploy a web service, so that your model is accessible via a simple API. There is even a test page, allowing you to call this API from within your browser.

There are limits to the free version. You cannot configure the size and number of instances on which it will run, and you are limited to 10 GB storage. If you cannot work within these restrictions, you can sign up for an Azure account and pay for the resources you use. Current pricing is available at this link.

If you are looking for a quick and simple way to build a machine learning solution, Azure Machine Learning Studio may be the tool for you.

Azure provides several ways of managing resources through scripting users. You can write scripts in either PowerShell (a popular Windows tool for managing servers and IAT resources) or CLI (a Bash-like scripting language that runs on Windows, Linux, and MacOS).

To use these tools, you need to have them installed locally, along with any support tools, such as the Azure PowerShell commandlets.

Until now.

Recently, Microsoft released the Azure Cloud Shell - a browser-based command-line interface built into the Azure portal. By opening a Cloud Shell from the Azure Portal, you can execute PowerShell or CLI scripts from within your browser, without installing anything.

To open Cloud Shell, navigate to the Azure portal and click the [Cloud Shell] button (Fig. 1) on the top tool bar.

Fig. 1

It may take a minute to retrieve and connect to a Cloud Shell environment (Fig. 2), but soon you will see a window with a command prompt, as Shown in Fig. 3.

Fig. 2

Fig. 3

The Cloud Shell in the image is configured to run CLI scripts. You can tell this by the dropdown in the window's top left corner. You can also run PowerShell scripts in a Cloud Shell window. To change the script types, click the top left dropdown and select your desired scripting language, as shown in Fig. 4.

Fig. 4

Fig. 5 shows the Cloud Shell with PowerShell selected.

Fig. 5

You don't need to log into the Cloud Shell environment. It will assume the account from which it was launched.

But you can view, create, and manage Azure resources. For example, from the Bash shell, type

az group list -o table

To see a list of all Resource Groups

or

az group create -l southeastus -n myrg

to create a new resource group named "myrg" in the Southeast US region.

You can even do other bash commands, such as ssh into an Azure Linux VM.

Cloud Shell automatically creates a container within an Azure VM to host your session. Although this container is destroyed shortly after you disconnect, Cloud Shell also creates a storage account to persist files or settings you use when using this interface, so they will be there when you return.

Azure Cloud Shell provides an environment for you to execute automation scripts and other administrative functions.

Managing Big Data takes a lot of process power. Data often needs to be captured, scrubbed, merged, and queried and each of these things can take many hours of compute time. But often they can be performed in parallel - reducing the amount of time, but increasing the number of computers required.

You could buy a bunch of computers, cluster them, and process your data on this process. But this is expensive and these computers are likely to sit idle most of the time.

Cloud Computing tends to be an ideals solution for most Big Data processing because you can rent the servers you need and only pay for them while they are running.

Microsoft Azure offers a full suite of Big Data tools. These tools are based on the popular Hadoop open source project and are collectively known as "HD Insight".

HBase

HBase is a NoSQL data store that is optimized for big data. Unlike SQL Server and other relational databases, the database does not enforce referential integrity, pre-defined schemas, or auto-generated keys. The developer must code these features into the client application. Because the database doesn't need to worry about these things, inputting data tends to be much faster than in a relational database.

HBase also can be scaled to store petabytes of data.

Storm

Apache Storm is a framework that allows you to build workflow engines against real-time data. This is ideal for scenarios like collecting IoT data. The Storm topology consists of a Stream, which is a container that holds a Spout and one or more Bolts. A Spout is a component that accepts data into the Stream and hands it off to Bolts. Each Bolt takes in data; preforms some discrete actions, such as cleaning up the data or looking up values from IDs; and passes data onto one or more other Bolts. Data is passed as "Tuples", which are sets of name-value pairs formatted as JSON. You can write your code in C#, Java, or Python and a Visual Studio template helps you create these components.

Hive

Hive is a data warehouse. With it, you can query NoSQL data (such as Hive) and relational data (such as SQL Server). Hive ships with a query language - HiveQL - that is similar to SQL. Where HiveQL falls short, you can even write user-defined functions to perform more complex calculations.

Spark

Spark is a visualization tool. In Spark, you can write code in R, Python, or Scala. Jupyter notebooks are a popular interactive tools that allow you to create templates consisting of text and code, so that you can generate real-time reports. Jupyter notebooks support both Python and Scala. Spark also ships with a number of libraries that make it easier to connect to data, create graphs, and perform a number of other tasks.

Clusters

Each of the services described above supports running in clusters of servers. In a cluster, these servers process in parallel, greatly reducing the amount of time required to process the data. You can easily create a cluster in the portal or you can write a script in PowerShell or CLI.

The ease of creating clusters is a big advantage of running HD Insight over deploying your own Hadoop servers and clustering them yourself. Of course, the other advantage is that you do not have to purchase and maintain servers that are only being used occasionally, which can be a big cost saving.

Warning

One word of caution about using these services. You pay for each server in a cluster by the minute. This can quickly add up. Typically, you don't need to have your cluster running for very long in order to complete tasks, so it is a good idea to shut them down when they are finished. Because of this, it's a good idea to script the creation and deletion of your cluster to make it easy to perform these tasks.

On April 7 in Arlington Heights, IL, Michael Blumenthal and the PSC Group organized a day-long event, titled “Azure and the Modern Data Center”. The event featured a single track of speakers presenting on topics related to managing Azure from an IT Infrastructure perspective.

My colleague Brian Lewis delivered the keynote at this event and I gave a presentation on Virtualization Containers. Other topics included Compute & Storage Infrastructure, Networking Infrastructure, and Disaster Recovery.

Here is an interview I conducted recently with Victor Cintron of DimDrop – a startup that uses location-based services to improve communication. They are deploying a number of open source technologies to Microsoft Azure.

The idea for the Global Azure Boot Camp began in 2013. Community developers from all over the world would hold a workshop in different cities on the same day. In fact, I organized and delivered a Boot Camp in the Detroit area that year, before I joined Microsoft.

On Saturday April 18, the 4th annual Global Azure Boot Camp took place in 161 cities around the world. While some cities focused on presentations and others on hands-on labs, all events provided education on Microsoft’s cloud computing platform.

Microsoft Regional Director Eric Boyd and Responsive X organized an event in Addison, IL – just outside of Chicago. Based on feedback, he received from attendees last year, Eric decided to reduce the length of the event to a half day, instead of a full day. The event was free to the public.

Eric kicked off the morning with an overview of Azure.

Next, a representative from Baracuda Networks gave a presentation on Azure security.

The only downside to the Saturday event was the number of people who registered and did not attend – over 50%. This was almost certainly due to the fact that the Chicago weather that morning was the nicest it had been in a long time. Still, over 60 people showed up to learn about Azure and cloud computing.

Response from the audience was overwhelmingly positive. Many people stayed after to ask questions about Azure and about BizSpark.

The nice thing about Fundamentals of Azure: Microsoft Azure Essential by Michael Collier and Robin Shahan is that it assumes no prior knowledge of Azure or cloud computing. Each chapter describes the technology and walks the user through how to implement that technology using Microsoft Azure.

The step-by-step instructions are very explicit, even including screenshots of each step. Collier and Shahan take you through the process of the most common Azure tasks, including creating Web Apps; setting up Virtual Machines and Virtual Networks;

Of course, the Azure team is adding new features very quickly; so occasionally, you will run into instructions that do not exactly match the portal. But Collier and Shahan do a good job of explaining the concepts, so the user can often find their way through any inconsistencies.

If you are new to Azure and want an overview of the platform or if you want help with specific features, Fundamentals of Azure will help.

Last month, I interviewed Pixel Squad CEO Will Malouk. Pixel Squad uses Azure to enhance their popular Crime Coast game. He discusses the technical challenges of developing this game and his reasons for moving from AWS to Azure.

In the left menu, click the "STORAGE" icon (Fig 1). This will list any storage accounts you currently have for this subscription.

Fig 1

To create a new Storage Account, click the [NEW] button (Fig 2) at the bottom left of the portal and select DATA SERVICES | STORAGE | QUICK CREATE from the popup menu (Fig 3).

Fig 2

Fig 3

The QUICK CREATE dialog displays, as shown in Fig 4.

Fig 4

At the URL field, enter a name for your storage account. This name must be a combination of only numbers and lowercase letters and it must be unique among storage accounts because it will be accessible publicly with a name like https://accountname.core.windows.net

where accounttname is the name you assign to the storage account. The portal will let you know if you enter a name this is not allowed or that is already taken.

At the LOCATION/AFFINITY GROUP field, select a region in which to create your storage account. (Affinity groups are no longer necessary and have been deprecated.)

At the REPLICATION field, select the type of replication you would like for your storage account. Azure always makes extra copies of your storage accounts, but you control how much redundancy and where that redundancy is stored. Options are:

zure storage includes built-in redundancy by default. In this screencast, I explain the Replication options that allow you to configure how many copies of your data are created, where they are created, and how they can be accessed.

Earlier this week, dozens of technologists from the Microsoft DX Team met in San Diego for a team hackathon.

Some brought projects they started back home; some brought hardware with them to control via Bluetooth or USB cable or through the Internet; some brought an idea for a software project; some for a hardware project.

I came with a desire to learn more about Azure Machine Learning. I was inspired by the work that my teammate Jennifer Marsman was doing analyzing EEG data with AML. (link)

Then I tried it myself. AML provides some sample data sources, so I imported the xxx data. I cleaned the data and applied a Category algorithm.

Machine Learning seems complex and the AML tools are not all intuitive when you first begin working with them; but they are not difficult to master. And the graphical interface of ML Studio lowers the learning curve considerably.

I'll provide more details and instructions about this project in a future blog post.

For now, my message is that building something yourself is the best way to learn any technology. Pick a project, set aside some time, and build it. I know that not every company invests in a day of hacking like mine did, so many of you will need to invest your own time in order to get this benefit. But it’s worth it.

My project wasn't nearly as sexy as some created by my colleagues. But my knowledge of Machine Learning is an order of magnitude greater than it was a week ago.

A few weeks ago, Seth Juarez of Channel 9 invited me to be his guest for an interview. We talked about Microsoft's support for open source software and Azure's support of non-Microsoft technologies. You can view this interview below.

At That Conference last month, Jason and Carl of the MS Dev Show set up a small recording studio in the middle of a hallway and interviewed speakers, organizers, and interesting people. I was fortunate to be included in this list. The show is below and my part is at the end

Azure storage includes built-in redundancy by default. In this screencast, I explain the Replication options that allow you to configure how many copies of your data are created, where they are created, and how they can be accessed.

Locally Redundant

Three copies of your storage data are created - all within the same region. No two copies will reside in the same Fault Domain and no two copies will reside in the same Upgrade domain.

This provides fault tolerance in case of the failure of one of the machines on which a copy of the storage account is stored. If the entire data center goes down, no copies of your data will be available.

This is the cheapest of the available redundancy options.

Geo-Redundant

As with Locally Redundant storage, Geo-Redundant storage also creates 3 copies of your data on separate fault domains and update domains in the same data center. But it also creates 3 more copies of your data in another region - typically the region nearest the primary region for this account. For example, if you select North Central US as your storage account's primary region, the account data will be replicated in the South Central US Region.

Once this cross-region replication occurs, you are protected from data loss, even if an entire Azure region fails.

Read-Access Geo-Redundant

Read-Access Geo-Redundant storage is identical to Geo-Redundant storage, but it also provides read access to data stored in the secondary region,

Zone Redundant

Three copies of your storage data are created and stored in at least 2 geographically disparate data centers. These data centers may or may not be in the same Region. This provides fault tolerance, even if an entire data center fails.

Zone Redundant Storage Accounts only support Block Blog storage, so selecting this option will limit the uses of your Storage account.

Considerations

Data within a region or data center is always distributed across multiple update domains and fault domains to protect against most hardware failures or planned maintenance downtime.

Replication within a data center is an atomic operation. In other words, success is not reported to the client until all 3 copies have been successfully written.

Replication to a secondary data center is done asynchronously and typically completes after success has been reported to the client. The good news about this is that clients don't experience any latency when writing to one of a Geo-Redundant storage account. A potential downside is that there is that data in the secondary data center is eventually consistent. If the primary data center fails, it is possible that not all data was written yet to the secondary data center.

Geo-Redundant and Read-Access Geo-Redundant are very similar - both create 6 copies of your data spread across two regions. The difference is that in a Geo-Redundant scenario, the data in the secondary region is only accessible in the event of a failure in the primary region. If all 3 copies of the data in the primary region are unavailable, Azure will fail over to a copy of the data in the secondary region. This also holds true with Read-Access Geo-Redundant, but you get one more benefit: users can access a read-only copy of the data in the secondary region, even if there is no failure in the first region. This can make for greater availability and access speed for users. This also explains why Read-Access Geo-Redundant is the most expensive option. It's the only option that allows users to read copies of the data.

Which Should I choose?

For maximum performance and reliability, Read-Access Geo-Redundant storage is your best option. But this is also the most expensive option. If you are very cost-conscious or if the government requires you to keep data within specific geographic boundaries, you should consider Zone Replication. Geo-Redundant storage is a good compromise between these two options for most scenarios.

Want to learn how to use Powershell to manage your Azure IAAS assets, such as Virtual Machines and Virtual Networks?

Brian Lewis and I are recording a series of videos that walk you through a set of Hands-On Labs. These are the same labs I used to learn how to automate Azure with Powershell and Brian is the man who taught me.

Last night, I was the guest on the Azure podcast. The show is hosted by Cale Teeter, Evan Basalik and Sujit D'Mello and they have been recording since October 2013 – coincidentally, the same week that I joined Microsoft.

We talked about a number of topics, including education, startups, and Azure’s support for open source software. It was my first time on this podcast and I really enjoyed it.

At IT Camp in Romania last month, I delivered a session on Azure Mobile Services and I sat on panel titled “Cloud for Business”. The conference recorded each of these sessions and made them available online. You can view them below:

There is a myth that Microsoft Azure is only of use to people work primarily with Microsoft technologies. One can understand how this confusion occurs – the product has the word “Microsoft” in its name, after all. But this simply is not true.

Microsoft Azure is a cloud computing platform built by Microsoft. As you would expect, you can host in Azure Windows Virtual Machines, ASP.NET applications, back-end services written in C#. These are all Microsoft technologies, so it's not surprising that Microsoft Azure is built to handle them.

But what if you are not a Microsoft technologist? What if you work with Linux or write in Java or Python or PHP? What if you build applications that run on an iPhone, iPad or an Android device? Is Microsoft Azure relevant to you? are non-Microsoft operating systems, languages, and platforms supported on Microsoft Azure? You may be surprised that the answer is a definite "Yes".

Here is a list of some of the non-Microsoft technologies supported in Azure.

Virtual Machines

You can install any operating system or software you like onto an Azure Virtual Machine (provided you have the proper licensing, of course). There is a Gallery of images with pre-installed software that you can uses as a template for quickly creating a new Virtual Machine. Of course, you'd expect to find images with Microsoft Windows pre-installed (Fig 1).

Fig 1

but you may be surprised to see a number of flavours of Linux (e.g., Ubuntu, Suse, and Oracle) represented in this gallery (Fig 2, 3).

Fig 2

Fig 3

Web Apps

Web Apps (formerly known as "Azure Web Sites") are a simple way to build a web site or application on Azure. These applications typically run on Windows and on IIS, but IIS is a flexible web host capable of supporting many different languages and platforms. As a result, you can write your server-side code in Java, Python, PHP, or JavaScript (using node.js) and it will work on an Azure Web App. There are even pre-built templates in the Web App Gallery built on top of non-Microsoft technologies. With a few clicks, you can create a new site built on WordPress, Drupal, or Joomla (Fig 4, 5), even though these content management systems are built with PHP, Python, and MySQL.

Fig 4

Fig 5

Web Apps also support automated deployment from a variety of source control systems. Click the Set up deployment from source control link on your web app's dashboard and select from GitHub, a local Git repository, BitBucket, or even Dropbox to configure automated deployments from your source control repository, as shown in Fig 6.

Fig 6

Mobile Services

Azure Mobile Services provide a simple way to create a back-end data service for your mobile application. Reading and Writing capability to this data store is exposed via a REST interface, which is exposed through HTTP and JSON. Because HTTP and JSON are web standards, these services can be called by virtually any client. Mobile Services will even generate sample code to access a Mobile Service so you can use it as a starting point in your mobile application. Select the generated code for Windows (in C# or JavaScript); for iOS (in Objective-C or Swift); for Android (in Java); for a single-page application (in JavaScript); or for a Xamarin or PhoneGap application, as shown in Fig 7.

Fig 7

Mobile Services also supports single-sign-on through a variety of Authentication Providers. Most of the work is done through configuration, meaning you don't need to write much code. Google, Facebook, and Twitter are among the authentication providers supported out of the box (Fig 8).

Fig 8

Cross-Platform Command-Line Tools

If you do a lot of work with Azure, you will find yourself wanting to automate some of tasks, such as creating and deploying virtual machines, configuring storage accounts, and setting security on services. For years, the best ways to do this were via a REST API or a set of Powershell commandlets that call those APIs. Now, a set of cross-platform command line tools allow you to write bash scripts on Mac or Linux to perform these same automation tasks.

Management Tools

Azure supports a number of management tools that are popular in the Linux world. Among these are Chef, Puppet, and Docker. VM Images and add-ins make it easier to use these tools.

Caching

A caching service was one of the first services built for Azure. But now that service has been deprecated in favor of the popular Open Source Redis Caching Service. Marketplace

Azure supports a number of third-party offerings in the Azure Marketplace. Here, you can find tool, such as Mongo and Raven as a service; or data feeds, such as address or phone number verification services. Items listed in the Marketplace are offered by third party companies, so some are free; some cost money; and some offer a free version that you can upgrade to a paid version. This list is growing every month.

Finally…

Azure might or might not be the perfect solution for your application or data. But, if you are considering a cloud platform, do not exclude Azure simply because you aren't using any Microsoft technologies. Azure is flexible enough to support a wide range of technologies - even those that compete directly with Microsoft.

Manual Backup

To Manually backup your Web App, do the following

1. Select an account from the STORAGE ACCOUNT dropdown list, as shown in Figure 2.

Figure 2

2. If your Web App has one or more linked databases and you would also like to back up those databases, expand the INCLUDED DATABASES dropdown and check all the databases you would like to backup. An example is shown in Figure 3.

Figure 3

3. Click the BACKUP NOW icon at the bottom of the screen (Figure 4).

Figure 4

Azure will back up all the files (and optionally any associated databases) of your Web App at the time specified and afterwards at the frequency specified. The files in your Web App will be zipped and stored into a Blob Storage account of the selected Storage Account.

Automated Backup

Manual backups are great if you want to backup your app right now; but, chances are that you will want to back it up on a regular basis so you don't have to worry about it. Use the same BACKUPS tab to schedule a backup at regular intervals. To do this, you will perform the 3 steps above in addition to a few others.

2. Select an account from the STORAGE ACCOUNT dropdown list, as shown in Figure 6.

Figure 6

3. At the FREQUENCY field, enter the number of days between each scheduled backup, as shown in Figure 7.

Figure 7

4. At the START DATE fields, select the date and time to perform the first backup, as shown in Figure 8.

Figure 8

5. If your Web App has one or more linked databases and you would also like to back up those databases, expand the INCLUDED DATABASES dropdown and check all the databases you would like to backup (Figure 9).

Figure 9

6. Click the SAVE icon at the bottom of the screen (Figure 10).

Figure 10

Azure will back up all the files (and optionally any associated databases) of your Web App at the time specified and afterwards at the frequency specified.

Azure Storage consists of Tables, Queues, and Blobs. To use any of these features, you must first create a Storage Account. This article describes how to use the Azure Portal to create an Azure Storage Account.

At the URL field, enter a name for your new storage account. This name must consist only of numbers and lowercase letters and it must be unique among storage accounts.

At the LOCATION/AFFINITY GROUP, select a region in which to store this account. Generally, in order to minimize latency, you should create your storage account close to whatever clients will be accessing data from this account.

At the REPLICATION field, select a replication option. You can select Locally Redundant, Geo-Redundant, Read-Access Geo-Redundant (the default), or Zone Redundant. A description of each option is below.

Locally Redundant

Select this option to create 3 copies of your data within a single data center. External users will only access one copy of the data.

Geo-Redundant

Select this option to create 6 copies of your data – 3 within a data center in the region you selected and 3 within a different data center in another region. External users will only access one copy of the data.

Read-Access Geo-Redundant

This option is identical to the Geo-Redundant option, except that external users can access in read-only mode the data stored in the secondary region.

Zone Redundant

Select this option to create 3 copies of your data within multiple data centers. External users will only access one copy of the data.

A Note on Pricing

The cost of each option is reflective of the durability and availability of your data, so Read-Access Geo-Redundant is more expensive than Geo-Redundant, which is more expensive than Zone Redundant, which is more expensive than Locally Redundant. You can view the current pricing at http://azure.microsoft.com/en-us/pricing/details/storage/.

There are three ways to create a new web site from the Azure portal: Quick Create; Custom Create; and From Gallery. To launch any of them, navigate to the Azure management portal and select "Web Sites" from the list of services along the left side of the portal [Fig 1].

Fig 1

Then click the "New" button at the bottom left (Fig 2). Fig 2

This displays the New Website menu(Fig 3)

Fig 3

Because we were in the "Web Sites" section when we clicked the "New" button, the categories: "COMPUTE" and "WEBSITE" are selected for us. We need to select from the three ways to create a web site within the Portal. They are: "QUICK CREATE", "CUSTOM CREATE", and "FROM GALLERY". Let’s go through each scenario.

QUICK CREATE

The simplest way to create a web site is with the QUICK CREATE option. With the NEW WEBSITE menu expanded, select QUICK CREATE (Fig 4).

Fig 4

The QUICK CREATE dialogue displays, as shown in Fig 5.

Fig 5

At the URL textbox, enter the name of your site. The full URL to access this new site will be http://sitename.azurewebsites.netwhere sitename is the name you typed into this field.

At the WEB HOSTING plan dropdown, you can either select an existing plan or select "Create new web hosting plan", in which case you will need to select a region in which to create the plan. The Web Hosting plan allows you to configure, manage, and scale a group of sites together.

Click the CREATE WEBSITE check button () to create the site. Typically it takes Azure less than a minute to create the site.

Once the site is created, you can navigate to the site's URL and you will see a default page (hostingstart.html) displayed in your browser, as shown in Fig 6.

Fig 6

This is the only file deployed to your site. You will need to use FTP, set up source control deployment or deploy your site content in some other way in order to get your web application into this web site.

CUSTOM CREATE

The CUSTOM CREATE option is similar to the QUICK CREATE, but it adds a few options on site creation. With the CUSTOM CREATE option, it is possible to associate a database with your site and set up Source Control publishing at the time you create your site.

With the NEW WEBSITE menu expanded, select CUSTOM CREATE. The CUSTOM CREATE dialogue displays, as shown in Fig 7.

Fig 7

At the URL textbox, enter the name of your site. The full URL to access this new site will be http://<sitename>.azurewebsites.net where <sitename> is the name you typed into this field.

At the WEB HOSTING plan, you can either select an existing plan or select "Create new web hosting plan", in which case you will need to select a region in which to create the plan.

Select or create a database to associate with this site. Enter a connection string name and credentials of the SQL Server account used by the web site to connect with the database. This database will appear under the LINKED RESOURCES tab of your website. Linking a database to a website makes it easier to manage them together, such as when you are backing up both your site and the database.

If you want to set up publishing from a source control repository, you can do so during site creation by clicking the "Publish from source control" checkbox (It is possible to skip this step and set up source control publishing later). Checking this checkbox adds a second page to the dialogue. Click the right arrow button () to advance to the second page (Fig 8), where you can select the type of source control you are using. For some repositories, you will be prompted for more information.

Fig 8

When you are finished configuring everything, click the right arrow to create your new site.

As with the QUICK CREATE option, only one file (hostingstart.html) is deployed to your site. You can navigate to the site URL to view this file in your browser.

FROM GALLERY

Unlike the QUICK CREATE and CUSTOM CREATE options, the FROM GALLERY option provides more than just a single page in your website. This option tends to be the fastest way to get a fully-functional web site up and running. It is also an excellent option for those without coding or HTML experience.

With the NEW WEBSITE menu expanded, select FROM GALLERY.

The ADD WEB APP dialogue displays, as shown in Fig 9.

Fig 9

This list displays a list of templates, frameworks, and web site engines from which to choose. Notice that you can filter this list by selecting a category on the left, such as BLOGS, or CMS (Fig 10).

Fig 10

Notice also that many of the options are based on non-Microsoft technologies. WordPress, for example, is written in PHP and stores data in a MySQL database. Select the template, framework, or web site engine on which you want to base your site and click the Right Arrow button. A configuration dialogue displays that is appropriate for the option you selected. At a minimum, you will need to provide a name for your web site, which will take the default form http://<sitename>.azurewebsites.net; but there may be other required information, such as selecting or creating an associated database. The dialogue for Orchard CMS is shown in Fig 11.

Click the Check button () to create your site. This generally takes longer than creating a site with either the QUICK CREATE or CUSTOM CREATE options because Azure will build an entire site for you. For many of the Blog and CMS templates, you will be prompted for some more information, such as a site name and an admin account the first time you navigate to the site. The "Get Started" page launched the first time you connect to a new Orchard CMS site is shown in Fig 11.

Fig 11

CONCLUSION

In this article, we showed the three ways to create a Web Site using the Azure Management Portal and walked you through the steps to create a web site with each method.

I didn't know what to expect when I was invited to the Hack10 Hackathon in Miami last week. I heard we would be working with Windows 10, so I installed the preview. I heard we would be working with Visual Studio 2015, so I installed that preview. I heard we would be using Azure, which was good because I love Azure and I wanted to learn more. I heard we would be doing something with the "Internet of Things" (IoT) and I wondered what was meant by that. I heard we would be using Git, so I did a bit of reading because I am very much a Git noobie.

But I didn't know what we would be working on or what the format would be.

As it turned out, we were asked to split into teams of 4 or less and come up with an idea involving IoT, Azure, Windows 10 and Git. Many people arrived with ideas and teams already formed. I did not. I looked around and saw a team of 3 with an idea and I asked if I could join them team. It was Dave Voyles, David Crook and Jennifer Marsman and they were kind enough to let me in. I had worked with Jennifer in the past and I knew Dave and David by reputation, so I believed we had a very strong technical team.

David Crook had come to the Hackathon an idea - a hardware device to monitor temperature, pressure, light, and wind flow and report that data (along with time and location information) to a database in Azure that could be queried and displayed in a portal. The hardware device would simulate the readings inside an oil pipeline because this was a real-world problem that Crook had studied before coming to the hackathon. We called our project "Pipe Dreams".

Jennifer worked to program 2 hardware devices - one to monitor the environment and one to send collected data to Azure; Dave Voyles created a portal to displayed the data on a map, updating each collection point and popping up a message if data fell outside an acceptable range. He completed a web front-end and started a Windows 10 client; David Crook wrote most of the business logic and analysis, including some fairly complex formulas that he acquired from his research of the oil and gas industry. and I created an Azure SQL database and a mobile service to write and query the data.

We shared our code in a Git repository, integrated with Visual Studio Online.

When it was done, we had data flowing end-to-end, measuring the environment and collecting data via an IoT device; stored and analyzed in Azure; and reported via a web portal.

We presented our findings to the group. I opened with a video showing a pipeline explosion (of course) and promised that our solution would solve this problem. The other team members showed off the technical aspects of the solution.

It was a competition among the dozen or so teams and first place went to... Pipe Dreams! That's right, we won!

We also had a chance to see what the other teams built, which was a lot of fun. One of the more clever (and sadistic) ideas was a device allowed audience members to rate a speaker during a presentation and give the speaker a shock if his ratings fell too low.

Two other teams placed in this competition: A team from Brazil created a game that became more difficult as more players connected over the Internet and played against you; and Paul DeCarlo, Jared Bienz, and Sertac Ozercan created a device to play music that could be controlled via a range of other devices, including Windows 8, Windows Phone, XBOX One and the Microsoft Band.

Overall, it was an excellent weekend. I learned a lot about the technologies we worked with and I was able to partner with some really bright technologists. Microsoft had invested quite a bit into the event to help keep us Evangelists up to speed on the technical side of our jobs - we stayed in a nice hotel, ate excellent food, and there were a number of experts on hand to answer questions or help us when we got stuck.

I hope these types of events continue and I hope that I can be a part of one in the future.

In my last article, I described how to use Visual Studio to create and deploy an Azure Mobile Service with server-side code written in a .NET language. I chose C# for that example. In this article, we will walk through the boilerplate C# code generated when you create a new Azure Mobile Services project.

TodoItem.cs

Next, we'll look at the TodoItem class (Listing 4), which can be found in DataObjects folder. This is the data model and will. It has 2 explicit properties - Text: the text of a Task that we need to complete; and Complete: a flag indicated whether or not we have completed this task. This object will will map to columns in the TodoItem table.
We don't need to explicitly provide an ID property because the class inherits this property from the EntityData class.

publicclass TodoItem : EntityData

{

publicstring Text { get; set; }

publicbool Complete { get; set; }

}

Listing 4

MobileServiceContext.cs

This is a Context used to manage database updates and retrievals via Entity Framework. It knows where to connect to the database and what model to send to the database. The Controller class will instantiate this to interact with the database table.

TodoItemController.cs

TodoItemController is the main controller class that maps HTTP Verbs (POST, PATCH, GET, and DELETE) to specific actions. It inherits from the TableController class, which has an IDomainManager named DomainManager that is used to retrieve and update data using Entity Framework. All the controller methods need to do is to call TableController methods, such as Lookup, UpdateAsync, InsertAsync, and DeleteAsync.

For example, if a client sends a request to our mobile service’s HTTP endpoint with the POST verb, the routing engine will run the PostTodItem method in TodoItemController (Listing 5).

public async Task<IHttpActionResult> PostTodoItem(TodoItem item)

{

TodoItem current = await InsertAsync(item);

return CreatedAtRoute("Tables", new { id = current.Id }, current);

}

To add business logic to your service, you will add code to the Controller methods (GetAllTodoItems, GetTodoItem, PatchTodoItem, PostTodoItem, and DeleteTodoItem.)

In this article, we covered the code that is automatically generated in a C# Azure Mobile Service.

In a previous article, I described how to create an Azure Mobile Service built on top of node.js - with all the server-side code written in JavaScript. You can also create a Mobile Service with server-side code written in C# or Visual Basic. You will probably prefer this method if you are more proficient in .NET than in JavaScript.

This article will walk you through the creation of an Azure Mobile Service, written in C#.

Launch Visual Studio 2013 and select File | New | Project from the menu. The New Project dialog displays, as shown in Figure 1.

Figure 1

Under the Templates list at the left of the dialog, expand either Visual Basic or C#; then, select the Cloud template category. Select "Azure Mobile Service" from the Cloud templates listed at the center of the dialog. Give the project a Name and Location and click the [OK] button.

The New ASP.NET Project dialog displays, as shown in Figure 2.

Figure 2

The Azure Mobile Service template should be selected and the "Web API" checkbox should be checked. Leave these selected and check and check the Host in the cloud checkbox; then, click the [OK] button.

Because you elected to host this service in the cloud, the Create Mobile Service dialog displays next, as shown in Figure 3.

Figure 3

Select an Azure subscription to deploy the Mobile Service; enter a name for your Mobile Service (it must be unique); select a Region; select a database; and enter login credentials for that database. Then click the [Create] button. This should create a project on your local machine and an empty Mobile Service in your Azure subscription.

The Mobile Service project is shown in Figure 4.

Figure 4

To publish your Mobile Service, right-click the project in the Solution Explorer and select Publish from the context menu. The "Publish Web" wizard displays with the "Profile" page activated as shown in Figure 5.

From the dropdown, select the Azure Mobile Service you created above and click the [Next] button.

The Profile page of the "Publish Web" wizard displays as shown in Figure 7.

Figure 7

Verify the information on the Profile page is correct and click the [Next] button.

The "Settings" page of the "Publish Web" wizard displays as shown in Figure 8.

Figure 8

Select "Release" from the Configuration dropdown and click the [Next] button.

The "Preview" page of the "Publish Web" wizard displays as shown in Figure 9.

Figure 9

Click the [Publish] button to publish the Mobile Service to your Azure subscription.

Now, you should be able to log onto the portal and view your new mobile service (Figure 10). Its status may be listed as “Creating…” if you go to the portal too quickly; but, within a couple minutes, you will be able to manage the service from the Azure portal.

Figure 10

You can manage this service almost exactly the same way that you managed a JavaScript mobile service. The difference is that the .NET mobile service does not contain a DATA tab. Data configuration in a .NET service is done in the Visual Studio project.

In this article, we showed the steps to create and publish a new Azure Mobile Service with server-side code in a .NET language.

Azure Mobile Services provides a simple way to expose server-side data to clients. In previous articles, we exposed data via a REST service and we created a client application that called that service to retrieve or update data.

But what if we want our service to push data down from the server to a client device without that device making a call each time? For example, you may want to tell send a message telling your app to change the text displayed on its tile, displaying the total number of orders entered in your e-commerce app; or you may want a "toast" popup notification to display on the app's device whenever someone scores in the Top 10 on a game you wrote.

We can use Push Notifications to do these things.

Each mobile vendor has its own service to manage Push Notifications and each service exposes an API to manage those notifications. Apple offers a Push Notification service to send data to registered iPhones and iPads; Google offers a Push Notification service to send data to registered Android phones and tablets; and Microsoft offers two Push Notification services - one to send data to registered Windows Pones and another to send data to registered Windows 8 or 8.1 devices.

Each of these services has an API and we can call each one explicitly for every device that will receive a notification. But this requires passing the address of each device, which is tedious and error-prone. Plus, it requires our server-side application to maintain a list of every device to which we want to push messages.

We can simplify the process by configuring Push Notifications through Azure Mobile Services. Azure Mobile Services Push Notifications automatically works with Azure Notification hubs to manage these messages.

In this article, we will focus on sending a Toast Notification to Windows 8.1 clients, but the process is similar for all Push Notifications.

The steps for setting up Push Notifications to a Windows 8.1 client using Azure Mobile Services are:

1. Create an Azure Mobile Service 2. Create a Windows 8.1 Client App and modify it as follows a. Associate app with store b. Get Package SID and Client ID from Live Services. Copy these to Mobile Service. c. Register notifications channel in OnLaunched (App.xaml.cs) d. Enable Toast notifications (Package.appxmanifest) 3. Update the Mobile Service service to send Push Notifications.

1. Create an Azure Mobile Service

2. Create a Windows 8.1 Client App and modify it as follows

For this example, we'll use the Windows 8.1 project in the Universal App generated for us in a previous article.

2a. Associate app with store

You will need a Windows Store account to complete this step. You can register at http://dev.windows.com/. It cost $19 to register for both the Windows Store and the Windows Phone Store and there is no annual renewal fee. Register your app with the store by opening the Visual Studio Solution; right-clicking on the Windows 8.1 project; and selecting Store | Associate App with the Store from the context menu. The "Associate App with the Windows Store" dialog (Figure 1) displays. Click the [Next] button.

Figure 1

If prompted, sign into the Windows Store (Figure 2)

Figure 2

You may be prompted for your email address (Figure 3). If so, enter it and click [Next]; then check your email account for a Security Code that was sent from the Microsoft Account Team.

Figure 3

Copy this code and paste it into Sign-In Wizard (Figure 4) and click the [Submit] button.

Figure 4

The "Select an app name" dialog (Figure 5) displays.

Figure 5

Enter a name for your app and click the [Reserve] button; then, click the [Next] button to display the final step in the wizard (Figure 6). Click the [Associate] button.

Figure 6

2b. Get Package SID and Client ID from Live Services. Copy these to Mobile Service.

Connect to the store portal (http://dev.windows.com for Windows Store apps and http://dev.windowsphone.com for Windows Phone apps) and click Dashboard. You should see your app listed with "In Progress" below its listing. Figure 7 shows the listing for an app in the Windows Store dashboard

Click the Live Services site link in the second paragraph to navigate to the Live Services page (Figure 10). You may be prompted to sign in again.

Figure 10

Note the Package SID and Client ID on the Live Services page. Copy each of these in turn and paste them into the appropriate fields of the "Windows Store" section of the "Push" page in the Azure Mobile Services page of the Azure portal. This is demonstrated in Figure 11.

Figure 11

Click the [Save] icon to save these values to your Mobile Service.

Your service is now capable of sending notifications to Windows store client apps.

2c. Register notifications channel in OnLaunched (App.xaml.cs)

Return to your .NET client application and open App.xaml.cs from the Shared project. Add the following 2 lines (Listing 1) to the top of this file:

1:using Windows.Networking.PushNotifications;

2:using Windows.UI.Popups;

Listing 1

Add the InitNotificationsAsync method to the bottom of the class (Listing 2)

2d. Enable Toast notifications (Package.appxmanifest)

In this example, the service will send a Toast notification, which will tell the client to popup a "Toast" message. A Toast message appears at the top-right of the Windows 8 screen and may contain 1 or more lines of text and an image.

To enable your application to accept Toast notifications, open the Package.appxmanifest file and select the "Application" tab. Under the Notifications section, select the "Toast capable" dropdown and set it to "Yes". (Figure 11)

Figure 12

Your client application is now listening for push notifications and capable of creating a Toast popup when it receives a notification.

3. Update the Mobile Service service to send Push Notifications.

The final step is to actually send Push Notifications from your Mobile Service. In this example, we will use the node.js mobile service we created in this article (link) and we'll send a Toast Notification to all Windows Store clients whenever a user enters a new ToDoItem.

In the Azure portal, open your Mobile Service and navigate to the todoitem table's SCRIPT page (Figure 12).

Figure 11

Select INSERT from the dropdown and replace the script with the code in Listing 3.

1: request.execute({

2: success: function() {

3:// If the insert succeeds, send a notification.

4: push.wns.send(null, payload, 'wns/toast', {

5: success: function(pushResponse) {

6: console.log("Sent push:", pushResponse);

7: request.respond();

8: },

9: error: function (pushResponse) {

10: console.log("Error Sending push:", pushResponse);

11: request.respond(500, { error: pushResponse });

12: }

13: });

14: }

15: });

16:

17: }

Listing 3

Test It Out

Your app is now ready to accept Push Notifications and your Mobile Service is configured to send them each time a new "ToDoItem" is inserted.

To see it in action, launch the application and insert a new ToDo item. Within a few seconds, you should see a "Toast" popup in the top right of your screen, indicating that you entered this item. If other users were also using this same app, they would see the same message.

In this article, we discussed Azure Mobile Services Push Notifications and walked through an example of adding them to a JavaScript Push Notification service and a Windows 8.1 application.

In a previous article, I showed how to create a sample .NET client application to connect to your Azure Mobile Service. In this article, I will show you how to add authentication to this sample application.

Azure Mobile Services supports a number of different methods of authentication. A couple of them you would expect from a Microsoft platform - User can be authenticated against Active Directory or they can be directed to log in with a Microsoft account (formerly known as a "Live" account.) You would expect Mobile Services to support these authentication methods because they are created and/or maintained by Microsoft. However, Mobile Services is designed to accept authentication tokens that adhere to the OAuth standard and it is built to support Facebook, Twitter, and Google authentication - all of which conform to oAuth.

In order to use an Authentication Provider, you must enable support for that provider. You can enable support for one provider and instruct all clients to use that provider; or you can enable support for multiple oAuth providers and clients will be able to offer a choice to users, allowing them to log in with their favourite service.

Setting up each of these oAuth providers is pretty similar, so the best way to show you how is to walk through an example. I'll enable Twitter authentication but the process is not much different for other providers.

Creating An App on Twitter

In order to allow users to log into your app via Twitter, you need to create an app in Twitter. You can do so by navigating to http://dev.twitter.com and signing in with your Twitter credentials (you may need to create a Twitter account first. If so, you may be the last person on Earth to do so.) At the bottom of the page is a "Tools" section. Click the "Manage Your Apps" link in this section, as shown in Figure 1.

Figure 1

On the "Twitter Apps" page, click the [Create New App] button (Figure 2).

Figure 2

The "Create an application" page (Figure 3) displays. The first 3 fields are required.

Figure 3

At the "Name" field, enter a name for your application. I usually use the same name I gave my Azure Mobile Service.

At the "Description" field, enter a brief description of your app.

At the "Website" field, enter your Mobile Service URL. You can find this URL in the Azure portal on the DASHBOARD tab of your Mobile Service (Figure 4)

Figure 4

Scroll down the "Create an Application" page (Figure 5), read the Developer agreement completely (in this case, you are likely the first person ever to do this), check the "Yes I agree" checkbox, and click the [Create your Twitter application] button to create the app.

Figure 5

A page displays for your newly-created app with a tab menu across the top as shown in Figure 6.

Figure 6

Click the "Keys and Access Tokens" tab to display the Application Settings as shown in Figure 7.

Figure 7

You will need the Consumer Key (API Key) and the Consumer Secret (API Secret) so keep this web page open and open a new browser or browser tab and navigate to the Azure Portal.

In the Azure Portal, select your mobile service and click the IDENTITY menu option as shown in Figure 8.

Figure 8

On the IDENTITY page, scroll down to the "twitter settings" section. From the Twitter "Application Settings" page, copy the API Key and the API Secret and paste these values into the corresponding fields on the Azure Mobile Services IDENTITY page, as shown in Figure 9.

jFigure 9

Click the SAVE icon (Figure 10) at the bottom of the page to save these changes.

Figure 10

Your Mobile Service now supports Twitter authentication.

Force clients to login before accessing your service by setting permissions on the service actions. This is done at the Mobile Service table's PERMISSIONS page. (To access the PERMISSIONS page, select your Mobile Service in the Azure Portal; click the DATA tab; select the table you want to secure; and click the PERMISSIONS tab.)

Change the permission of each action to "Only Authenticated Users" by selecting "Only Authenticated Users" from the dropdown next to each action, as shown in Figure 11. Click the SAVE icon to commit these changes.

Figure 11

Now any client app that calls your service has no choice but to force users to log in with Twitter in order to use your app.

CLIENT APP

Open the client app that we created in an earlier article and open MainPage.cs in the Shared project.

Add the following code to the class.

1: MobileServiceUser user = null;

2:private async System.Threading.Tasks.Task AuthenticateAsync()

3: {

4:while (user == null)

5: {

6: user = await App.MobileService

7: .LoginAsync(MobileServiceAuthenticationProvider.Twitter);

8: }

9:

Listing 1

Then call this method by adding the following line at the top of the OnNavigatedTo method

1: await AuthenticateAsync();

Listing 2

When the user navigates to the MainPage, she will be redirected to the Twitter login page where she must successfully login before proceeding. The MobileService will remember the user and pass this information in a token with each request to the REST service. If you configure another authentication provider, such as Google or Microsoft, you can direct the user to that provider's login page by changing the MobileServiceAuthenticationProvider enum, which is passed as a parameter to the MobileService.LoginAsync method.

In this article, we saw how to configure single sign-on for our Azure Mobile Service.

By default, the service allows anyone with the Application Key to access this Mobile Service. This Application Key is generated automatically when the service is created. You can view the key by clicking to the "Manage Keys" icon (Figure 1) at the bottom of the Mobile Service Dashboard to display the "Manage Access Keys" dialog (Figure 2).

Figure 1

Figure 2

In the generated sample application, this access code is automatically passed to the constructor of the MobileServiceClient object that is instantiated in App.xaml.cs (Listing 1)

If you have created a table for your Mobile Service, you can click on the service's Data tab and manage the Permissions of that table by selecting the table and clicking the Permissions tab.

Here, you will see 4 dropdowns (Figure 3) - one for each operation you can perform on the table (INSERT, UPDATE, DELETE, and READ). For each of these operations, you can set one of the following permissions:

Everyone

Anybody with the Application Key

Only Authenticated Users

Only Scripts and Admins

Figure 3

Below is an explanation of each Permission option

Everyone

The service is not secured. Anyone who knows the URI can access the service operation. Set this on the READ PERMISSION and you will be able to open a browser, navigate to the table's URI and view the data in the table.

Anybody with the Application Key

This is the default permission. Any request must contain the Application Key in the HTTP Header of the request. The format is

X-ZUMO-APPLICATION:key

where keyis the Application Key of this Mobile Service.

As described above, the .NET MobileServiceClient class handles this automatically if we pass the Application Key into its constructor.

Only Authenticated Users

An authentication token from a trusted authentication provider must accompany the HTTP request to this REST service. In a future article, I will show you how to set up single sign-on with trusted authentication providers so that this token is added to each request.

Only Scripts and Admins

This allows an operation to be performed only by Administrators logged onto the Azure portal or by PowerShell scripts running directly on the Virtual Machine on which the Mobile Service is running.

You are free to set different permissions for each operation. For example, you could allow anyone to read data in your table; require the Application Key for updates; authenticated sign on for inserts; and only allow Admins and server scripts to delete data from the table.

In reality, you will likely pick a single security mechanism for the table and set all operations to this. You can then write server-side code to handle any differences between the services (allowing a user to only delete his own records, for example).

Conclusion

The permissions are for a given combination of endpoint (which, in this case, points to a table) and action (INSERT, UPDATE, DELETE, and READ). If you like, you could set a different permission for each action on this endpoint. For example, you could declare that anyone can read data; only those with the Application Key can update data; only Authenticated users can Insert a row; and Deleting data is reserved for scripts and Admins. To me, it makes more sense to keep the same permission for each action, unless you have a specific reason for changing it for a given action.

In this article, we showed how to set permissions on each action for a given Azure Mobile Services endpoint.

In my last article, I described how to use the Azure Mobile Services wizard to create a sample client application. In this article, we will look at the code created by this wizard.

I'll focus on the C#/XAML version of the sample app but all the principles apply for the HTML5/WinJS version as well.

Figure 1 shows the solution, which includes a Windows 8.1 project, a Windows Phone 8.1 project, and a project with files that are shared by the other two projects.

Figure 1

I always compile this app before running it, because that ensures that all NuGet packages are updated.

Because this is a Universal app, it contains both a Windows 8.1 and a Windows Phone 8.1 project. The two projects do pretty much the same thing but each has a user interface appropriate to its own platform.

A screen shot of each running app is shown in Figure 2 (Windows 8.1) and Figure 3 (Windows Phone 8.1). As you can see, this app keeps track of a user's To Do List. The list of "To Do Items" is stored in an Azure SQL Database, which is exposed via Azure Mobile Services.

Figure 2

Figure 3

Most of the interesting stuff happens in the Shared project.

TodoItem.cs

Let's look first at the Model. It is in the Shared project because both apps use the same model. You can find it in the TodoItem.cs file in the DataModel folder (Listing 1).

1:publicclass TodoItem

2: {

3:publicstring Id { get; set; }

4:

5: [JsonProperty(PropertyName = "text")]

6:publicstring Text { get; set; }

7:

8: [JsonProperty(PropertyName = "complete")]

9:publicbool Complete { get; set; }

10: }

Listing 1

The three properties (Id, Text, and Complete) will map to columns in the SQL Server table. Text and Complete are decorated with the JsonProperty attribute, which is found in the Newtonsoft.Json library and tells .NET how to name these properties when an object is transformed into the JSON format. Strictly speaking, this is unnecessary, but JSON objects tend to follow the
JavaScript convention of Camel casing.

App.xaml.cs

The shared App.xaml.cs takes care of some basic processing when an app starts up, suspends, or has a problem.

As far as Azure Mobile Services is concerned, the important line is the MobileService field declaration (Listing 2)

The second parameter of the constructor is the application key generated by your Mobile Service. Passing the Application Key to the constructor of our MobileServiceClient is necessary if we set permissions to only allow calls to the mobile service by clients that provide the Application Key. Whenever we call the REST service with this object, the Application Key will be passed in the header of HTTP calls to the mobile services endpoints.

This static class is available throughout the application and contains methods to communicate with your mobile service. Its main use is to create an IMobileServiceTable by calling the static object's GetTable() method, which is done in the MainPage.

MainPage.cs

Notice that all three projects contain the MainPage class, which derives from the Page object. In both the Windows project and in the Windows Phone project, this class is in the MainPage.xaml.cs file, while the class is in the MainPage.cs file in the shared project. Notice also that these are all "partial" classes and that each is in the same namespace. At compile time, both the Windows and Windows Phone projects will pull in the class from the Shared Project and use its code.

At the top of the MainPage class is the creation of two sets of our model (Listing 3).

MobileServiceCollection items is simply a collection on the client that is used to bind to a ListView control in our XAML named ListItems.

The IMobileServiceTable interface has methods to interact with the REST API specified when the MobileService was created (which is our Azure Mobile Service API). So, the todoTable object has implementations of these methods specific to our service.

For example, the InsertTodoItem method makes a call to todoTable.InsertAsync() and passes an instance of the TodoItem. This calls our Azure Mobile Service REST endpoint (in this case, that endpoint is https://giard.azure-mobile.net/Tables/todoitem), using the POST Verb and passing

We can use Lync extension methods of todoTable to retrieve specific data into the todoTable object as in Listing 4 (from the RefreshTodoItems() method), which retrieves only todoItems for which the Boolean field Complete is false.

1: items = await todoTable

2: .Where(todoItem => todoItem.Complete == false)

3: .ToCollectionAsync();

Listing 4

The shared code takes advantage of the fact that the events fired in Windows and in Windows Phone are very similar and that the similar objects with similar names and events are created in the MainPage.xaml of each project. Because of this, the shared project can even contain event handlers that are appropriate for either project. For example, Listing 5 is the event handler when you click a checkbox next to an item on either the phone or your Windows PC/Tablet to mark that item as "Complete".

Conclusion

Notice how much of the application logic was moved into the Shared project. This isn't surprising because both the Phone app and the Windows app do the same thing - but with different user interfaces. It should be your goal to push as much of our app as you can into the Shared project.

When you build your own app, you will almost certainly use a different model and a different user interface. However, the samples code in this generated application should provide you a template for how to do basic operations on your mobile service, such as Read, Write, Update, and Delete. Make sure you understand the sample; then copy the appropriate code into your application and modify it to fit your model.

In the last article, I showed how to create a new Azure Mobile Service in the portal. In this article, I will show you how to use the wizard to create an application, consisting of a new table, an HTTP endpoint to access that table, and a sample client application to access the data through that endpoint.

Log onto the Azure Portal and select the MOBILE SERVICES icon in the left menu. Figure 1 shows the Mobile Service we created last time.

Figure 1

Click the arrow next to the service name to display details about the service (Figure 2).

Figure 2

Notice the choices you have next to "CHOOSE A PLATFORM". The Platforms listed are the various client platforms explicitly supported by Mobile Services. Remember that Mobile Services exposes data via standard interfaces such as HTTP and JSON which can be used by a wide variety of platforms and languages. For this demo, click the "Windows" button; then expand the "CREATE A NEW WINDOWS APP" link. This will reveal the 3 steps to get you started building an application around Azure Mobile Services (Figure 3).

Figure 3

Get the tools (Figure 4) allows you to download a free version of Visual Studio. If you already have any version of Visual Studio 2013 installed, you can skip this step.

Figure 4

The "Create a table" step (Figure 5) allows you to create a sample SQL Server table. Click the green button to create a new table named "TodoItem" in your database with columns to keep track if the tasks you need to do today and whether you have completed each task.

Figure 5

The “Download and run your app” step (Figure 6) will generate client code that will connect to your application.

Figure 6

Select a language (C# or JavaScript) and click the Download button to download a ZIP file containing a Universal App that includes a Windows 8.1 project, a Windows Phone 8.1 project, and a Shared Code project. Depending on your language selection, these projects will either contain a user interface written in XAML and C# code-behind or an HTML5 front-end with a WinJS code-behind. Figure 7 shows the results of C#/XAML project generated by Azure Mobile Services.

Figure 7

Compile and run this app to see it in action. Figure 8 shows a screen shot of the Windows 8 app. You can enter a new task in the textbox and click Save to send data to the mobile service telling it to insert a row in the todoitem table. A list on the right displays all tasks that are not yet completed. Click the checkbox next to an item to send data to the mobile service telling it to update the todoitem table, setting the Complete column to FALSE.

Figure 8

Figure 9 shows the Windows Phone project running.

Figure 9

You can see that the apps look similar because they have the same functionality. The differences are related to the size, layout, and other considerations of the specific platform on which they run. Play with each app and you will see that they function about the same, thanks to the large percentage of shared code.

In this article, we saw how to run the Azure Mobile Services wizard to generate a sample table and client application.

With Azure Mobile Services, developers can quickly create a REST interface to read and write their backend database.

The Azure portal provides a wizard for creating a sample solution built around mobile services in just a few minutes. In this article, I will walk you through the steps to create a new Azure Mobile Service.

Log onto the Azure Portal and select the MOBILE SERVICES icon (Figure 1) in the left menu.

Figure 1

Click the NEW button at the bottom of the screen (Figure 2).

Figure 2

This exposes a menu (Figure 3).

Figure 3

With COMPUTE and MOBILE SERVICES selected (which should already be the case) click the CREATE button.

The "Create a Mobile Service" dialog (Figure 4) displays.

Figure 4

Give a name for the service. The full name will be whatever you type in the URL textbox, followed by ".azure-mobile.net" and it must be unique. The portal will let you know if someone else has chosen the same name. Select an existing database or create a new one; then select the Region where the Mobile Service will live. It makes sense to create the service in the same region where the database resides.

Finally, select the language in which to build the backend service. If you select JavaScript, the server-side solution will be hosted in Node.js. If you select .NET, you can create a solution in Visual Studio and deploy it to Azure, where it will be hosted in IIS.

Click the arrow (Figure 5) at the bottom right of the dialog to advance to the next page, where you can specify database information.

Figure 5

Figure 6 show the page if you elect to connect to an existing database. Select the database connection string; then enter the login name and password with which you will connect to this database.

Figure 6

Click the check button to create the Mobile Service. After a few seconds, the service will show up in the portal as in Figure 7.

Figure 7

In this article, we saw how to create a new Azure Mobile Service. In the next article, we will add a table and allow clients to retrieve and update data in that table, using this service.

Storing data in the cloud allows your application to remember information between launches and to share data among other users, applications, and devices.

Exposing that data via a REST interface makes this data accessible to applications running on a variety of platforms and written in a variety of languages. REST is an architectural pattern for allowing clients to read and update server data through a consistent API. The current implementations of REST uses an HTTP endpoint (a URL) to expose functionality and the features of HTTP (verbs, response codes, and header data) to exchange data between the client and the server.

Azure Mobile Services (ZuMo) makes it easier to expose your data as a REST endpoint by handling the "plumbing" code for you so that you can focus on your data model and your business logic.

With just a few clicks, you can create a service and map it to a database table. ZuMo will create an HTTP endpoint; map HTTP verbs to Create, Read, Update, and Delete methods; create those methods for you; and handle the transformation from JSON data into objects that map to rows in your database table. This isn't impossible code for you to write, but it can be a lot of code. And wouldn't your time be better spent writing the code that makes your application unique?

Azure Mobile Services will even generate a client application to call your new REST service and pass data to and from it. You can use this application as a starting point or you can copy and paste code from this app into your own client app. ZuMo is capable of generating a sample client application for Windows 8, Windows Phone, HTML and JavaScript, Xamarin, PhoneGap, Android, or iOS.

Azure Mobile Services is a true cross-platform solution that is simple to implement because it handles much of the plumbing code for you.

What is Demand Elasticity, how does it affect my apps, why should I care, and how does Azure address this?

Demand Elasticity is an issue because almost no app has a constant demand over time: Some apps are used primarily during business hours and very little during the night; some apps have abnormally high demand during specific events, such as the launch of a new product or while NFL games are broadcasting; some businesses have peak seasons when they do nearly all their business (I once worked for an electronics retail store that earned over 80% of their revenue between Thanksgiving and New Years Day.)

Each of the above examples describes demand variability that you can plan for. An even more difficult problem is unexpected changes in demand. Imagine if a popular TV show recommends your online service. Demand would likely skyrocket. Could your services handle this extra, unexpected load?

Because of this change in demand, you need to decide how much hardware to deploy for your application. If you deploy too much hardware, you are wasting your money, but if you deploy too little, you will miss out on potential users and revenue. And in the fact that hardware is not easy or quick to deploy - It may take your organization weeks or months to respond to a sudden, unexpected increase in demand. And what do you do with that extra hardware when demand falls? For most organizations, it's not practical to buy and sell hardware as demand goes up and down.

Ideally, as demand increases and places higher load on your servers, you would increase the amount of hardware to which your application is deployed. Then, you would remove that hardware (and stop paying for it) as demand and workload decrease. If you are managing and deploying the hardware yourself, this is not really practical. There is no quick market to buy and sell servers and most organizations take days – if not weeks – to provision a new server.

But Azure allows you to deploy more servers to your application and it automatically deploys them for you in a matter of minutes. Most services in Azure have a setting that allows you to change the number of running instances. This can be the number of web sites, web roles, mobile service, virtual machines, or dozens of other service instances available.

Below is the setting for configuring the number of instances of an Azure Web Site. figure 1

Some services even allow you to automate this process. For example, you can configure Azure to monitor the CPU used by your web sites and automatically deploy a new instance of your site when CPU rises above a certain percent and remove an instance when it falls below a given percent. You can set a minimum and maximum to keep the number of instances within this range.

For Azure Web Sites, this Auto-scaling feature is available if we select the "Standard" hosting plan. Below are the controls that allows you to set these configuration.

Figure 2

Scaling up helps your service deal with extra usage (planned or unplanned), while scaling down helps you save money. The quicker you can do both, the more agile you will be.

Azure allows you the flexibility to scale up and down to meet changing demand.

Starting a software company involves a lot of risk, including (but not limited to) financial risk, technology risk, market risk, and timing risk. Microsoft is actively trying to remove at least some of the risk for startup companies who are developing a software product or service. Because the first few years of a company tend to have the highest risk, Microsoft is offering the BizSpark program to mitigate that extra risk until a company stabilizes. The BizSpark program is designed to provide free software, free cloud computing hour, and free access to technical resources to qualified startups.

Specific benefits of the BizSpark program are:

Free Microsoft software, including Windows, Visual Studio, SQL Server, Office, and many more. BizSpark members can download many thousands of dollars worth of software for free for 3 years

$150 a month of Microsoft Azure cloud computing hours. If you are not familiar with Azure, check out http://azure.microsoft.com/en-us/ to see all the services that are available. There are too many Azure services to describe here, but startups often find Web Sites, Virtual Machines, and Azure Mobile Services useful in promoting or integrating with their products. If your demand increases, beyond this, there is even a chance to increase this to $5000 per month for one year.

Free access to technical resources, such as Microsoft Technical Evangelists. Your local evangelist likely has regular office hours and can help you troubleshoot some of your technical issues.

There is absolutely no obligation or cost to joining the BizSpark program. At the end of the 3 years, you keep the software you have installed. There is no fee for the program and obligation to buy more software or Azure hours (although, we certainly hope that you do.)

In the past, a startup was required to apply to the BizSpark program and wait for a response from Microsoft (sometimes for over a week). Now, however, I can provide a code to eligible startups that registers them in the BizSpark program immediately.

If you meet the above criteria and you would like to take advantage of the program, reach out to to your local Technical Evangelist (If you are in Wisconsin, Illinois, or Indiana, that is me) and describe your startup’s product.

Like Day 1, there were a number of big announcements from Microsoft during the Day 2 keynote at the Build conference. The most exciting parts were the new features of Windows Azure (now “Microsoft Azure”), as that team continues to push out new features at an impressive rate.

My notes from the Day 2 Keynote are below. Just like yesterday, these are just my raw notes and it’s possible I missed or misheard or mistyped something. So back off, ok? ;)

Azure In Action by Brian Prince and Chris Hay has something for everyone. It provides a good overview of the use cases for Windows Azure and a high-level overview of the Azure architecture, which is useful for those new to the platform. It also provides many in-depth examples of Azure features, such as web roles, worker roles, and storage options.

The book also benefits from the light-hearted style of Prince and Ray, who are as entertaining in print as they are in person.

The only downside is that newer Azure features are not covered in this book and Microsoft is adding new features at a startling rate. As far as I know, no updated edition is in the works to cover these new features.

Still, the book remains relevant because of its focus on the uses of cloud computing and on the still-relevant core features.

Cloud computing has been a hot topic in the software industry for the past couple years. Many of us hear about cloud technologies such as Windows Azure, but don't know how to get started.

I wanted to make it easy to find that information, so I'm organizing a 1-day conference to teach people about Windows Azure.

The Detroit Day of Azure will take place Saturday March 24 from 8AM to 6PM at the Microsoft office in Southfield, MI.

14 speakers from 8 different states have agreed to deliver 19 presentations at this event. The speakers (listed below) are among the foremost Azure experts in the region. The list includes MVPs, Microsoft insiders, book authors, and people delivering real Azure solutions for their customers.

Azure MVP and Sogeti National Cloud Computing Lead Brent Stineman will deliver the keynote; then we will split into 3 rooms for the rest of the day, where you can choose from several great topics and speakers. Our plans are to record at least some of the conference on video. We may even live stream some of it, but that is still in the planning phase.

We will designate one room for programmers to build Azure applications. Attendees can bring a laptop and either work on their own project or work through the Azure labs, which we will provide for you. Many smart people will be around if you get stuck. Remember to download and install the Azure SDK and sign up for a free Azure Trial before you arrive!

If you have been attending the Great Lakes Area .NET User Group (where I was president the last two years), you won't be surprised to learn that we are serving some excellent food at this event. Included in the $20 admission cost is a continental breakfast and a buffet lunch from Lockhart’s barbeque in Royal Oak. We will also have some door prizes to give away at the end of the day.