Scott Hanselman

Announcing PowerApps with Azure App Service

November 30, '15 Comments [8] Posted in Azure
Sponsored By

Introducing PowerAppsMicrosoft announced Azure App Service in March of this year on ScottGu's blog. Azure App Service includes all this stuff for one price. In fact, if you are already using Web Apps/Sites, have many of these features but may not know it:

  • Web Apps - This is the Azure Web Sites that you use today. .NET, node.js, Python, Java, PHP, and more.
  • Mobile Apps - libraries and runtimes for iOS/Windows/Android/Mac, plus offline sync support, notifications, and more
  • Logic Apps - Workflow in the cloud (like IIFTTT but hosted and controlled by you) that can orchestrate business processes within your App Service
  • API Apps - RESTful web services, connections to lots of SaaS systems like Dropbox, Office365, etc, plus security and automatic versioning.

In April the Azure team added isolated App Service Environments. An App Service Environment provides a isolated and fully dedicated environment for securely running all of your apps including Web Apps, Mobile Apps, API Apps and Logic Apps. Your apps run on virtual machines that only run your apps. You aren't on a pool of shared machines like much of the cloud. These dedicated App Service Environments can also scale much larger than the standard App Service. App Service Environments always run in their own private virtual network that you control.

Today at the Convergence Conference in Spain, Bill Staples announced PowerApps. The team I work on doesn't just make ASP.NET, we also make tools and services for Azure App Service and for the last year the team has been building PowerApps. PowerApps makes it easy to quickly create new business apps, connect systems and then share those apps with anyone on your team.

You should go check out to learn about the creation process for business users (like, folks who use Office but don't program), but I decided to focus more on how a professional developer would use Azure App Service and PowerApps, so I made a video to demonstrate a real example.

PowerApps for developers

bricksA Real Scenario

I wrote an app something like 13 years ago for Pioneer Courthouse Square here in Portland. The square is the Center of the City and it's covered with bricks that have the name of the people who donated to have the square built. There's tens of thousands of bricks and they are hard to find. There was an Access Database and a paper map but that was lame, so I put together an ASP app and a SQL database to generate a printable map that gets visitors within ten or so feet of their brick.

This is a real legacy app that has been running - happily and unchanged - for over a decade. We don't like to admit apps like this exist but the world is full of them. This apps was created before the iPhone, before ubiquitous connectivity, before web services, and before federated security. I thought it would be cool to make this legacy data available as a JSON-based web service, secure it's admin access with Azure Active Directory, build a CRUD mobile admin app with PowerApps for iOS, Android, and Windows, and then, just for fun, also create a native Android app with Xamarin 4 and the Azure Mobile Apps libraries so that volunteers can manage requests for photographs of bricks.

What does this all mean? What's changed?

PowerApps is the business application creation side. Think of it as a new member of the Office Family. It's not a Visual Studio thing. Apps made with PowerApps are sharable with in your organization as easy as sharing documents and they run on Windows, Android, and iOS. A business user could build a new workflow app and share it with everyone. They can auth that new app against APIs like Office 365, Microsoft Dynamics, Salesforce, Dropbox, Twitter, Google Drive, and OneDrive. For example, my example app takes photos of the bricks and puts the result in Azure Storage, but I could just as easily drop them in Google Drive or OneDrive.

However, for Visual Studio developers, or any developer, you still use the language of your choice (C#, F#, node.js, PHP, etc) and write Web APIs and Apps and host them in Azure App Service as you always have. But, if you want, those APIs can live in a new gallery that is specific to your organization so that anyone in your org (developer or business user alike) can use in their applications. My legacy BrickFinder is now an authenticated API living in an Azure App Service Environment. The API is being used by a website, an Android app written with Xamarin, and also an application created with PowerApps, running everywhere.

One other interesting point to note is that PowerApps pricing isn't consumption based, it's user-based pricing. Pay by the head, rather than prices fluctuating by consumption. For companies with public facing apps like my startup, I like pricing that changes with the popularity and usage of my app. For enterprise and large companies, simple pricing that's per-user makes more sense and is easier to budget for.

Check out the launch videos. PowerApps is in private preview now (go sign up at if you like), but you'll be hearing more about it in the months to come. 

Sponsor: Big thanks to Infragistics for sponsoring the feed this week. Responsive web design on any browser, any platform and any device with Infragistics jQuery/HTML5 Controls.  Get super-charged performance with the world’s fastest HTML5 Grid - Download for free now!

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web

Using Redis as a Service in Azure to speed up ASP.NET applications

November 6, '15 Comments [18] Posted in ASP.NET MVC | Azure
Sponsored By

Microsoft Azure has a Redis Cache as a Service. There's two tiers. Basic is a single cache node, and Standard is as a complete replicated Cache (two nodes, with automatic failover). Microsoft manages automatic replication between the two nodes, and offers a high-availability SLA. The Premium tier can use up to a half-terabyte of RAM and tens of thousands of client connections and be clustered and scaled out to even bigger units. Sure, I could manage your own Redis in my own VM if I wanted to, but this is SAAS (Software as a Service) that I don't have to think about - I just use it and the rest is handled.

I blogged about Redis on Azure last year but wanted to try it in a new scenario now, using it as a cache for ASP.NET web apps. There's also an interesting open source Redis Desktop Manager I wanted to try out. Another great GUI for Redis is Redsmin.

For small apps and sites I can make a Basic Redis Cache and get 250 megs. I made a Redis instance in Azure. It takes a minute or two to create. It's SSL by default. I can talk to it programmatically with something like StackExchange.Redis or ServiceStack.Redis or any of a LOT of other great client libraries.

However, there's now great support for caching and Redis in ASP.NET. There's a library called Microsoft.Web.RedisSessionStateProvider that I can get from NuGet:

Install-Package Microsoft.Web.RedisSessionStateProvider 

It uses the StackExchange library under the covers, but it enables ASP.NET to use the Session object and store the results in Redis, rather than in memory on the web server. Add this to your web.config:

<sessionState mode="Custom" customProvider="FooFoo">
<add name="MySessionStateStore"
port="1234" />

Here's a string from ASP.NET Session stored in Redis as viewed in the Redis Desktop Manager. It's nice to use the provider as you don't need to change ANY code.

ASP.NET Session stored in a Redis Cache

You can turn off SSL and connect to Azure Redis Cache over the open internet but you really should use SSL. There's instructions for using Redis Desktop Manager with SSL and Azure Redis. Note the part where you need a .pem file which is the Azure Redis Cache SSL public key. You can get that SSL key here as of this writing.

Not only can you use Redis for Session State, but you can also use it for a lightning fast Output Cache. That means caching full HTTP responses. Setting it up in ASP.NET 4.x is very similar to the Session State Provider:

Install-Package Microsoft.Web.RedisOutputCacheProvider 

Now when you use [OutputCache] attributes in MVC Controllers or OutputCache directives in Web Forms like <%@ OutputCache Duration="60" VaryByParam="*" %> the responses will be handled by Redis. With a little thought about how your query strings and URLs work, you can quickly take an app like a Product Catalog, for example, and make it 4x or 10x faster with caching. It's LOW effort and HIGH upside. I am consistently surprised even in 2015 how often I see folks going to the database on EVERY HTTP request when the app's data freshness needs just doesn't require the perf hit.

You can work with Redis directly in code, of course. There's docs for .NET, Node.js, Java and Python on Azure. It's a pretty amazing project and having it be fully managed as a service is nice. From the Azure Redis site:

Perhaps you're interested in Redis but you don't want to run it on Azure, or perhaps even on Linux. You can run Redis via MSOpenTech's Redis on Windows fork. You can install it from NuGet, Chocolatey or download it directly from the project github repository. If you do get Redis for Windows (super easy with Chocolatey), you can use the redis-cli.exe at the command line to talk to the Azure Redis Cache as well (of course!).

It's easy to run a local Redis server with redis-server.exe, test it out in development, then change your app's Redis connection string when you deploy to Azure. Check it out. Within 30 min you may be able to configure your app to use a cache (Redis or otherwise) and see some really significant speed-up.

Sponsor: Big thanks to my friends at Octopus Deploy for sponsoring the feed this week. Build servers are great at compiling code and running tests, but not so great at deployment. When you find yourself knee-deep in custom scripts trying to make your build server do something it wasn't meant to, give Octopus Deploy a try.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web

Penny Pinching in the Cloud: Your web app doesn't need 64-bit

October 6, '15 Comments [21] Posted in Azure
Sponsored By

Often times I hear folks say that they need (or want) 64-bit support when they deploy to the cloud. They'll deploy their modest application to Azure, for example, as a Web Application, then immediately go to the settings and set it to 64-bit. So many years later and it's "do I need 64-bit" is still confusing to a lot of people.

Change your Azure bitness settings here

I made basic Hello World ASP.NET app and deployed it. Now, I go to that Web Apps "blade" in the Azure Portal, click Tools, then Process Explorer (after exercising the app a little.) I'm running 32-bit here. The K is the Kudu "sidecar" deployment site (for things like Git deploy and diagnostics), and the other icon is the production site.

30 meg working set for IIS in 32 bit mode

Now, I'll swap it to 64-bit and exercise the web app again. Remember, this app is just a super basic app.

102 meg working set in IIS in 64-bit mode

See how the working set (memory) jump? It's a little extreme in a hello world example, but it's always going to be bigger than 32-bit. Always. 64-bit'll do that. Does your site need to address more than 4 gigabytes of memory from any single process? No? Then your web app probably doesn't need to be 64-bit. Don't believe me? Test it for yourself.

I'll go even further. Most web apps don't need 64-bit, but here's the real reason. If you stay 32-bit when putting your Web Application in the cloud you can fit more applications into a limited space. Maybe your Medium App Service Plan can actually be a Small and save you money.

Until 64-bit only is the default in things like Nano Server, today you can fit more Web Apps into limited memory if you stick with 32-bit.

I personally have 18 web apps in a Standard Small App Service in my personal Microsoft Azure account. They are sites like my podcast Hanselminutes and they get decent traffic. But most never get over 300-600 megs of memory and there's literally no reason for them to be 64-bit today. As such, I can fit more in the Small App Service Plan I've chosen.

18 web apps in a single app service plan

Remember that the Azure Pricing Calculator isn't totally obvious when it comes to Web Applications. It's not ~$55 per Basic Web Site. There's a Virtual Machine under there, they call the whole thing an "App Service Plan" and your Web Apps sit on top of that plan/VM. It's really $55 for a plan that supports as many web applications you can comfortably fit in there.

The cloud is a great deal when you're smart about the resources you've been given. If you're using Azure and you're not using most of the the resources in your service plan, you're possibly wasting money.

What Penny Pinching in the Cloud tips do you have? Disagree with this advice? Sound off in the comments.

Related Links

Sponsor: Thanks to my friends at Accusoft for sponsoring the feed this week. Just a few lines of code lets you add HTML5 document viewing, redaction, annotation, and more to your apps and websites. Download a free trial now!

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web

A/B Testing and Testing In Production with Azure Web Apps

July 17, '15 Comments [6] Posted in Azure
Sponsored By

I've got a lot of production web sites running in Azure right now. Some are for small side projects and some are larger like the sites for the Hanselminutes Podcast and This Developer's Life. I like Web Apps/Sites (which is Platform as a Service) rather than Virtual Machines (Infrastructure as a Service) because I don't like thinking about the underlying operating system if I can avoid it. I like to be able to scale the site up (faster, bigger) or out (more machines in the farm) with a slider bar.

In fact, there's some other more advanced and useful features that Azure Web Apps have that keep me using Web Apps almost exclusively.

I'll use a little site I made called that tells you how many keystrokes are left in your hands before you die. Think of it as a productivity awareness tool.

First, I'll add a Deployment Slot to my existing Git-deployed Web App. The source for KeysLeft lives in GitHub here. When I check-in a change it's automatically deployed. But what if I wanted to have a staging branch and automatically deploy to a first? If it works out, then move it to production by swapping sites. That'd be sweet.

Staging Slots for Azure Web Apps

You can see here my main KeysLeft web app has a Staging "side car" app that is totally separate but logically related/adjacent to production. Notice the "swap" button in the toolbar. Love it.

Adding Deployment Slots to an Azure Web App

This Web App has its configuration copied from the main one, and I can setup Continuous Deployment to pull from a different branch, like "staging" for example. The name of the deployment slot becomes a suffix, so unless you set up a custom CNAME like You can have up to 4 deployment slots in addition to production (so dev, test, staging, whatever, production) on Standard Web Apps.

A/B Testing for Azure Web Apps

Once I've got a slot or two set up and running a version of my app, I can do A/B testing if I'd like. I can set up a feature that was called "Testing in Production" and is now "Traffic Routing" and tell Azure what percentage of traffic goes to prod and what goes to staging. Of course, you have to be sure to write your application so such that authentication and session is managed however is appropriate, especially if you'd like the user to have a seamless experience.

Here I've got 10% of the traffic going to staging, seamlessly, and the other 90% is going to production. I can make a small change (background color for example) and then hit the main site over and over and see the occasional (10% of course) request being routed to the staging slot. You can configure this static routing however you'd like.

10% Traffic to Staging

Then I could hook up Application Insights or New Relic or some other event/diagnostics system and measure the difference in user reaction between features that changed.

Advanced Testing in Production

Made it this far? Then you're in for a treat. Static routing is cool, to be clear, but scripting a more dynamic experience is even more interesting. Galin Iliev, one of the developers of this feature, gave me this Powershell script to show off more powerful stuff.

First, you can use PowerShell to manage this stuff. You can change routing values and ramp up or ramp down. For example, here we start at 10% and change it by 5 every 10 minutes.

# Select-AzureSubscription YOURSGOESHERE

$siteName = "keysleft"
$rule1 = New-Object Microsoft.WindowsAzure.Commands.Utilities.Websites.Services.WebEntities.RampUpRule
$rule1.ActionHostName = ""
$rule1.ReroutePercentage = 10;
$rule1.Name = "staging"

$rule1.ChangeIntervalInMinutes = 10;
$rule1.ChangeStep = 5;
$rule1.MinReroutePercentage = 1;
$rule1.MaxReroutePercentage = 80;

Set-AzureWebsite $siteName -Slot Production -RoutingRules $rule1

But! What if you could write code to actually make the decision to continue or fall back dynamically? You can add a callback URL and a Site Extension called the "TiP Callback Extension."

$rule1.ChangeDecisionCallbackUrl =

The Site Extension (and all Site Extensions for that matter) is just a little sidecar Web API. This callback gets a small POST when it's time to make a decision, and you decide what to do based on HTTP-related context that was passed in and then return a ChangeDirectionResult object as JSON. You can adjust traffic dynamically, you can adjust traffic when doing a deployment, do a slow, measured roll out, or back off if you detect issues.

NOTE: The ChangeDescisionCallbackUrl and this code below is totally optional (so don't stress) but it's super powerful. You can just do static routing, you can do basic scripted dynamic traffic routing, or you can have make a decision callback URL. So the choice is yours.

You can check out the code by visiting after installing the TiP callback site extension and look at the Site Extensions folder. That said, here is the general idea.

using System.Web.Http;
using TipCallback.Models;

namespace TipCallback.Controllers
public class RoutingController : ApiController
public ChangeDirectionResult GetRoutingDirection([FromBody] RerouteChangeRequest metrics)
// Use either Step or RoutingPercentage. If both returned RoutingPercentage takes precedence
return new ChangeDirectionResult
Step = (int)metrics.Metrics["self"].Requests,
RoutingPercentage = 10

Here's the object you return. It's just a class with two ints, but this is super-annotated.

/// <summary>
/// Return information how to change TiP ramp up percentage.
/// Use either Step or RoutingPercentage. If both returned RoutingPercentage takes precedence
/// Either way MinRoutingPercentage and MaxRoutingPercentage set in API rule are in force
/// </summary>
public class ChangeDirectionResult
/// <summary>
/// Step to change the Routing percentage. Positive number will increase it routing.
/// Negative will decrease it.
/// </summary>
[DataMember(Name = "step")]
public int? Step { get; set; }

/// <summary>
/// Hard routing percentage to set regardless of step.
/// </summary>
[DataMember(Name = "routingPercentage")]
public int? RoutingPercentage { get; set; }

All this stuff is included in Standard Azure Web Apps so if you're using Standard apps (I have 19 websites running in my one Standard plan) then you already have this feature and it's included in the price. Pretty cool.

Related Links

Sponsor: Big thanks to Infragistics for sponsoring the feed this week. Responsive web design on any browser, any platform and any device with Infragistics jQuery/HTML5 Controls.  Get super-charged performance with the world’s fastest HTML5 Grid - Download for free now!

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web

Git-deployable F# based Web Applications in the Azure Cloud with WebSharper

May 19, '15 Comments [7] Posted in Azure | Open Source
Sponsored By

Web Apps with WebSharper and F#Last month after I wrote a small prototype to get the F# web framework running on Azure Web Apps (a git deployed managed Platform as a Service) I started looking for more F# Azure resources.

Here's a list of some other existing F# programming technologies that are great with Azure. Did I miss any? I surely did. There's a huge list up at for resources running F# on any cloud.

  • Fog (an F# Azure data scripting API)
  • MBrace (a scalable distributed programming model for F#)
  • FSharp.Data (a set of F# type providers for common cloud data manipulation scenarios)
  • Suave (a simple web development F# library for lightweight microservices including route flow and task composition)
  • FSharp.CloudAgent - a simple framework to easily distribute workloads over the cloud using standard F# Agents as the processing mechanism. Support exists for both simple and reliable messaging via Azure Service Bus, and for both workers and actors.
  • AzureStorageTypeProvider - An F# Azure Type Provider which can be used to explore Blob, Table and Queue Azure Storage assets and easily apply CRUD operations on them
  • Try F# - A web programming console for F# that can be reoriented towards Azure programmability
  • HadoopFs - A lightweight F# implementation of the Hadoop Streaming API
  • FSharp.Azure - A wrapper over WindowsAzure.Store using idiomatic F#

There's also the WebSharper web framework. WebSharper isn't ASP.NET with F#, it's its own idiomatic thing. What's that really mean, "idiomatic?"

You know how when you Google Translate a sentence it doesn't quite work? I mean, it works, but it doesn't feel right. It doesn't feel right because the translator understands the words, and some phrases, but not the idioms - the underlying thoughts that are unique to that language. There was a time a few years back when folks were constantly looking for C# to VB convertors. This is something that's quite possible, almost line for line. However, changing an imperative language into a functional one is not like turning American English into British English. ;) Let functional languages be functional.

F# people like to do things their way and the language has very different goals and ideas than C# so it makes sense there would be a opinionated web framework for F#. I like it.

(Although I'm sure there will be a way to use ASP.NET 5 and MVC with F# in the future, this post isn't about that.)

WebSharper has a VS Extension so you can File New new projects, and here's a hello world ToDo List app (minus the HTML view, which you can see here)

namespace UINextApplication1

open WebSharper
open WebSharper.JavaScript
open WebSharper.JQuery
open WebSharper.UI.Next
open WebSharper.UI.Next.Notation

module Client =
type IndexTemplate = Templating.Template<"index.html">

let Tasks = ListModel.FromSeq ["Have breakfast"]

let Main =

let newName = Var.Create ""

ListContainer =
(ListModel.View Tasks |> Doc.Convert (fun name ->
Task = View.Const name,
Done = (fun e -> Tasks.Remove name)))
Task = newName,
Add = (fun e ->
Var.Set newName "")
|> Doc.RunById "tasks"

More interesting is the recent blog post by Adam Granicz where he expands on my "Suave to Azure via GitHub" prototype and shows how to deploy a real F# WebSharper app to Azure Websites via GitHub.

One of the main improvements is that my solution used FAKE and I found myself wanting a binary version of the FSharp compiler as  NuGet. An issue was open and closed within days, simplifying the deployment. Additionally their WebSharper solution creates an ASP.NET app that runs in the context of ASP.NET and IIS, while my Suave solution needed a separate process. WebSharper 3.1 was recently released, and you can see their sample running live in Azure here:

And of course, you can deploy it to Azure right from here using the Deploy to Azure button!

Deploy to Azure

Do you dabble in F#, are you doing F# professionally? What do you think about F#-based web applications?

Sponsor: Big thanks to Atalasoft for sponsoring the blog and feed this week! If your company works with documents, definitely check out Atalasoft's developer tools for web & mobile viewing, capture, and transformation. They've got free trials and a remarkable support team, too.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web
Page 1 of 8 in the Azure category Next Page

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.