Skip to main content

Azure Container Instances and Azure Service Fabric - what to use when?

1 min read

Azure Service Fabric

Service Fabric is Microsoft’s orchestration platform powering many Tier-1 Microsoft services such as Azure SQL Database, Azure Document DB, Cortana, Windows Intune, and Skype for Business. 

Service fabric is an E2E PaaS platform, integrating many critical capabilities (e.g. container orchestration, service discovery, etc.) that allows you to develop, deploy and operate your applications (containerized or not). Service Fabric is a Windows environment with Linux and container support being added. Service Fabric is an ideal solution for Windows customers who may have some Linux workloads.

Azure Container Service

Azure Container Service is focused on deploying, scaling and managing Linux containers first, with Windows Server Containers being added. Customers using Linux container technologies should consider Azure Container Service.  ACS is an ideal solution for Linux customers who may have some Windows workloads.  

 

Go Go Azure Functions!

11 min read

 

 Azure Functions are cool.  Functions are conceptually similar to WebJobs in that they are event-driven (triggered) and can be easily integrated with other Azure resources.  Functions are a lightweight alternative to rapidly building and deploying event-driven microservices (several jump start templates are available - see the list at the bottom of this post).  Like most microservices, Functions should be stateless and idempotent.

 With Azure Functions, your applications scale based on demand and you pay only for the resources you consume (e.g. "serverless"). It’s important to note here that the Consumption Pricing Tier (which is the default) imposes a 5 minute time limit on your Functions. If your Function needs more than 5 min to execute you’ll need to host your Function on an App Service VM (although you probably shouldn’t be using Functions if your process needs more than 5 minutes to execute - check out Functions Best Practices).  

 Azure Functions can be implemented in multiple programming lanugages and all the code is available on GitHub:

 To learn more about Azure Functions, see the Azure Functions Overview.

 Function Proxies

 Azure Function Proxies were announced as a preview last week.  Function Proxies enable you to define a single API across multiple Functions. You can learn more about Azure Function Proxies here.

Function Proxies vs. API Management - What to Use When?

I've had a few people express confusion about what to use when: Azure Proxies vs. Azure API Management (APIM).  Azure Function Proxies and APIM can both be used to map a single API to one or more endpoints. Function Proxies make it easier to manage and expose multiple Functions through a simple API while APIM is a full service gateway for documenting, securing, logging and governing the use of your APIs.

 

 

A List of all Function Templates

These templates are available in the Azure Functions Portal.

Core Templates:

BlobTrigger-CSharp - A C# function that will be run whenever a blob is added to a specified container

BlobTrigger-FSharp - An F# function that will be run whenever a blob is added to a specified container

BlobTrigger-JavaScript - A JavaScript function that will be run whenever a blob is added to a specified container

EventHubTrigger-CSharp - A C# function that will be run whenever an event hub receives a new event

EventHubTrigger-FSharp - An F# function that will be run whenever an event hub receives a new event

EventHubTrigger-JavaScript - A JavaScript function that will be run whenever an event hub receives a new event

GenericWebHook-CSharp - A C# function that will be run whenever it receives a webhook request

GenericWebHook-FSharp - An F# function that will be run whenever it receives a webhook request

GenericWebHook-JavaScript - A JavaScript function that will be run whenever it receives a webhook request

GitHubWebHook-CSharp - A C# function that will be run whenever it receives a GitHub webhook request

GitHubWebHook-FSharp - An F# function that will be run whenever it receives a GitHub webhook request

GitHubWebHook-JavaScript - A JavaScript function that will be run whenever it receives a GitHub webhook request

HttpTrigger-CSharp - A C# function that will be run whenever it receives an HTTP request

HttpTrigger-FSharp - An F# function that will be run whenever it receives an HTTP request

HttpTrigger-JavaScript - A JavaScript function that will be run whenever it receives an HTTP request

ManualTrigger-CSharp - A C# function that is triggered manually via the portal "Run" button

ManualTrigger-FSharp - An F# function that is triggered manually via the portal "Run" button

ManualTrigger-JavaScript - A JavaScript function that is triggered manually via the portal "Run" button

QueueTrigger-CSharp - A C# function that will be run whenever a message is added to a specified Azure Queue Storage

QueueTrigger-FSharp - An F# function that will be run whenever a message is added to a specified Azure Queue Storage

QueueTrigger-JavaScript - A JavaScript function that will be run whenever a message is added to a specified Azure Queue Storage

ServiceBusQueueTrigger-CSharp - A C# function that will be run whenever a message is added to a specified Service Bus queue

ServiceBusQueueTrigger-FSharp - An F# function that will be run whenever a message is added to a specified Service Bus queue

ServiceBusQueueTrigger-JavaScript - A JavaScript function that will be run whenever a message is added to a specified Service Bus queue

ServiceBusTopicTrigger-CSharp - A C# function that will be run whenever a message is added to the specified Service Bus topic

ServiceBusTopicTrigger-FSharp - An F# function that will be run whenever a message is added to the specified Service Bus topic

ServiceBusTopicTrigger-JavaScript - A JavaScript function that will be run whenever a message is added to the specified Service Bus topic

TimerTrigger-CSharp - A C# function that will be run on a specified schedule

TimerTrigger-FSharp - An F# function that will be run on a specified schedule

TimerTrigger-JavaScript - A JavaScript function that will be run on a specified schedule

API and Webhooks Templates:

GenericWebHook-CSharp - A C# function that will be run whenever it receives a webhook request

GenericWebHook-FSharp - An F# function that will be run whenever it receives a webhook request

GenericWebHook-JavaScript - A JavaScript function that will be run whenever it receives a webhook request

GitHubWebHook-CSharp - A C# function that will be run whenever it receives a GitHub webhook request

GitHubWebHook-FSharp - An F# function that will be run whenever it receives a GitHub webhook request

GitHubWebHook-JavaScript - A JavaScript function that will be run whenever it receives a GitHub webhook request

HttpTrigger-CSharp - A C# function that will be run whenever it receives an HTTP request

HttpTrigger-FSharp - An F# function that will be run whenever it receives an HTTP request

HttpTrigger-JavaScript - A JavaScript function that will be run whenever it receives an HTTP request

Data Processing Templates:

BlobTrigger-CSharp  - A C# function that will be run whenever a blob is added to a specified container

BlobTrigger-FSharp - An F# function that will be run whenever a blob is added to a specified container

BlobTrigger-JavaScript - A JavaScript function that will be run whenever a blob is added to a specified container

EventHubTrigger-CSharp - A C# function that will be run whenever an event hub receives a new event

EventHubTrigger-FSharp - An F# function that will be run whenever an event hub receives a new event

EventHubTrigger-JavaScript - A JavaScript function that will be run whenever an event hub receives a new event

QueueTrigger-CSharp - A C# function that will be run whenever a message is added to a specified Azure Queue Storage

QueueTrigger-FSharp - An F# function that will be run whenever a message is added to a specified Azure Queue Storage

QueueTrigger-JavaScript - A JavaScript function that will be run whenever a message is added to a specified Azure Queue Storage

SendGrid-CSharp - (Preview) A C# function that sends a confirmation e-mail when a new item is added to a particular queue

SendGrid-JavaScript - (Preview) A JavaScript function that sends a confirmation e-mail when a new item is added to a particular queue

ServiceBusQueueTrigger-CSharp - A C# function that will be run whenever a message is added to a specified Service Bus queue

ServiceBusQueueTrigger-FSharp - An F# function that will be run whenever a message is added to a specified Service Bus queue

ServiceBusQueueTrigger-JavaScript - A JavaScript function that will be run whenever a message is added to a specified Service Bus queue

ServiceBusTopicTrigger-CSharp - A C# function that will be run whenever a message is added to the specified Service Bus topic

ServiceBusTopicTrigger-FSharp - An F# function that will be run whenever a message is added to the specified Service Bus topic

ServiceBusTopicTrigger-JavaScript - A JavaScript function that will be run whenever a message is added to the specified Service Bus topic

TimerTrigger-CSharp - A C# function that will be run on a specified schedule

TimerTrigger-FSharp - An F# function that will be run on a specified schedule

TimerTrigger-JavaScript - A JavaScript function that will be run on a specified schedule

Sample Templates:

FaceLocator-CSharp - A C# function that processes images and outputs the bounding rectangle of faces

FaceLocator-FSharp - An F# function that processes images and outputs the bounding rectangle of faces

FaceLocator-JavaScript - A JavaScript function that processes images and outputs the bounding rectangle of faces

GitHubCommenter-CSharp - A C# function that will be run whenever it receives a GitHub webhook request

GitHubCommenter-FSharp - An F# function that will be run whenever it receives a GitHub webhook request

GitHubCommenter-JavaScript - A JavaScript function that will be run whenever it receives a GitHub webhook request

HttpGET(CRUD)-CSharp - A C# function that fetches entities from a Storage Table when it receives an HTTP request

HttpGET(CRUD)-FSharp - An F# function that fetches entities from a Storage Table when it receives an HTTP request

HttpGET(CRUD)-JavaScript - A JavaScript function that fetches entities from a Storage Table when it receives an HTTP request

HttpGET(CRUD)-PHP - (Experimental) A PHP function that fetches entities from a Storage Table when it receives an HTTP request

HttpPOST(CRUD)-CSharp - A C# function that adds entities to a Storage Table when it receives an HTTP request

HttpPOST(CRUD)-FSharp - An F# function that adds entities to a Storage Table when it receives an HTTP request

HttpPOST(CRUD)-JavaScript - A JavaScript function that adds entities to a Storage Table when it receives an HTTP request

HttpPUT(CRUD)-CSharp - A C# function that updates entity in a Storage Table when it receives an HTTP request

HttpPUT(CRUD)-FSharp - An F# function that updates entity in a Storage Table when it receives an HTTP request

ImageResizer-CSharp - A C# function that creates resized images whenever a blob is added to a specified container

ImageResizer-FSharp - An F# function that creates resized images whenever a blob is added to a specified container

SasToken-CSharp - A C# function that generates a SAS token for Azure Storage for a given container and blob name

SasToken-FSharp - An F# function that generates a SAS token for Azure Storage for a given container and blob name.

SasToken-JavaScript - (Preview) A JavaScript function that will be run whenever a file is added to a External File provider.

ScheduledMail-CSharp - (Preview) A C# function that will periodically send emails

SendGrid-CSharp - (Preview) A C# function that sends a confirmation e-mail when a new item is added to a particular queue

SendGrid-FSharp - (Preview) An F# function that sends a confirmation e-mail when a new item is added to a particular queue

SendGrid-JavaScript - (Preview) A JavaScript function that sends a confirmation e-mail when a new item is added to a particular queue

Experimental Templates:

BlobTrigger-Batch - (Experimental) A Batch function that will be run whenever a blob is added to a specified container

ExternalFileTrigger-Batch - (Experimental) A Batch function that will be run whenever a file is added to a External File provider.

ExternalFileTrigger-CSharp - (Preview) A C# function that will be run whenever a file is added to a External File provider.

ExternalFileTrigger-FSharp - (Preview) An F# function that will be run whenever a file is added to a External File provider.

ExternalFileTrigger-JavaScript - (Preview) A JavaScript function that will be run whenever a file is added to a External File provider.

ExternalTable-CSharp - (Experimental) A C# function that fetches entities from a External Table when it receives an HTTP request.

ExternalTable-FSharp - (Experimental) An F# function that fetches entities from a External Table when it receives an HTTP request.

HttpTrigger-Batch - (Experimental) A Batch function that will be run whenever it receives an HTTP request

HttpTrigger-Powershell - (Preview) A PowerShell function that will be run whenever it receives an HTTP request

QueueTrigger-Bash - (Experimental) A bash function that will be run whenever a message is added to a specified Azure Queue Storage

QueueTrigger-Batch - (Experimental) A Batch function that will be run whenever a message is added to a specified Azure Queue Storage

QueueTrigger-Php - (Experimental) A PHP function that will be run whenever a message is added to a specified Azure Queue Storage

QueueTrigger-Powershell - (Preview) A PowerShell function that will be run whenever a message is added to a specified Azure Queue Storage

QueueTrigger-Python - (Experimental) A Python function that will be run whenever a message is added to a specified Azure Queue Storage

TimerTrigger-Powershell - (Preview) A PowerShell function that will be run on a specified schedule

 

Drop Dead Simple ASP.NET WebHooks example

1 min read

ASP.NET Webhooks were RTM in late December of last year.  There are a ton of examples from the webhooks available on Github.  There are so many examples it can be somewhat overwhelming. 

I wanted to create the simplest possible demo showing how ASP.NET webhooks work and did so here.  The demo contains a number of comments explaining how to set up and use it.  I hope you find it helpful in learning more about ASP.NET webhooks.

 

 

 

 

A Quick Comparison of Hybrid Connections and Azure Relay Hybrid Connections

2 min read

Update: Azure Relay Hybrid Connections is now Generally Available.  The official docs are here.

Azure moves fast. Azure Relay Hybrid Connections was announced on November 1st and I'm just catching up with it now. 

Azure Relay Hybrid Connections does not depend upon BizTalk and does not replace Hybrid Connections

Differences between Hybrid Connections and Azure Relay Hybrid Connections:

  • Hybrid Connections
  • Relay Hybrid Connections
    • Only available in the new Azure portal (http://portal.azure.com)
    • Does not use BizTalk on the Azure side
    • Built on HTTPS and Websockets. The protocol is open and fully documented
    • No client-side "connections manager" required - use the API with an Azure relay namespace
    • Supports SAS keys
    • Support for multiple code bases and platforms (a node sample is also available)
    • Can be used in a production environment for simple point-to-point connectivity.

People adopting Relay Hybrid Connections should follow well-known best practices for working with web sockets (e.g. periodic pinging and aggressive reconnecting as necessary). 

 See here for a simple example of Azure Relay Hybrid Connections.

 

 

 

Using webhooks in Logic Apps

4 min read

Update: This post was originally written before Logic Apps Designer fully supported webhooks.  Logic Apps Deisgner now fully supports webhooks.

New to webhooks? There is a short intro to webhooks in this post on DZone.  It does a decent job explaining the concept but more interestingly discusses how webhooks are composable.  Wonderful idea.

It's election season here in the US and that means polling.  Polling is fine for voting but is usually not a great idea for services.

If I've got a long-running process (e.g. waiting for a user to login and approve a document) I shouldn't have to poll to see if that process has completed yet. 

Polling is like going on a long drive with a kid in the back seat constantly asking "are we there yet? are we there yet?". 

Adopting an event-driven approach is much more natural and loosely coupled - the long-running process can simply tell us when it's complete instead of periodically polling it.  Being event-driven with RESTful services can be accomplished in many ways but one of the easiest is with webhooks.  A webhook is a user-defined HTTP callback.  I register my callback with the long-running process and wait for it to be invoked by a POST.  No polling needed. 

Webhooks are now supported by Logic Apps.  You can think of an Azure Logic App as a workflow that you build and run in the cloud. With webhooks your workflow can wait for an event from a long-running process. 

Here is a simple Logic App that consists of two steps.  The first step POSTs a simple message to a RequestBin URL. Request Bin is a great, free service you can use to test and inspect HTTP messaging.  The second step is another HTTP action but it has a strange icon on it - it also doesn't render properly in the designer.  This is because webhooks aren’t yet supported in the Logic Apps Designer (this is coming soon).  Webhooks are supported in the code view so let’s look at some code. 

Here is (most of) the code view of our simple Logic App (Logic Apps use JSON under the covers). There are two steps in this workflow.  The first step is named "Http" (default name - I could have changed it but I didn't).  The second step is named "Http_2".  You'll see each step contains an optional set of conditions, inputs and a type identifier.  

Note the second step of the workflow ("Http_2") surrounded by the red box.   Looking at this code we can see some interesting things...

If you look at the inputs you'll see it contains a subscribe construct.  The @listCallbackUrl() enables us to retrieve the URL for firing the webhook (where the long running process can "publish" its event to).  The type has been changed from Http to HttpWebhook.  The URL being used here came from RequestBin.  These changes had to be made manually in code view because the designer doesn't yet support webhooks.  This "Http_2" step originally looked like the "Http" step right above it.

What happens when we run the workflow?  It stops and waits for the webhook we subscribed to:

If we go over to RequestBin we can copy the webhook URL (in red below) and use it to POST back using a tool like Postman or Fiddler (click to enlarge):

Now that the webhook has fired (was POSTed back) the workflow will wake up and continue running:

Learn more about the JSON and commands used by Logic Apps here.

Note: Old-timers like me might be surprised to see "Workflow Definition Language" making a comeback.  Despite the similar acronym this is not the same WIDL that was used by the now defunct webMethods product.  

  

 

Setting Up and Running Your Own River 5 Server on Azure (For Poets)

13 min read

Note: Click on thumbnails for a larger/readable image.

Dave Winer is brilliant guy who made RSS a standard,  "bootstrapped the blogging revolution" and invented a ton of incredibly elegant and useful tools.  If you're not reading his blog you're seriously missing out.

One of the many interesting ideas he developed was the "river of news". A "river of news" is different from standard news readers and provides a much better user experience (don't take my word for it, go read about it yourself).  Dave recently shipped River 5, the latest implementation of the "river of news". 

There are some very good instructions for installing River 5 on a client (Mac, Windows) but I haven't found any clear instructions for creating a River 5 server, hence this post.  (I'm also a big fan of Dave's "For Poets" series - this is my feeble attempt at creating such a post.)

OK - let's get started!

You'll Need A Server

Running a server obviously requires you to have a server, right?  Not necessarily - this is the age of the "cloud" and you can run your server "in the cloud" without having to buy it and maintain it.  The "cloud" is just a trendy term for using someone else's computers for your own stuff.  In this case someone else's computers will be Microsoft's Azure service and your own stuff will be River 5. 

Wait - Microsoft is evil and proprietary isn't it?.

This is not the same old Microsoft. Azure supports several operating systems (not just Windows) and open source tools. Many Microsoft products and frameworks are now open source and available on Git.

Step One: Get an Azure subscription

This is the easiest step.  Best of all it will enable you to explore the range of services and capabilities available in Azure once you're more comfortable with it.  Signing up is easy.  You'll even get $200 to spend so it won't cost you anything to set up your River5 server.  Now go get signed up and come back here when you're ready.

Step Two: Pick a server

Remember, the cloud is nothing more than someone else's set of computers that you can use for your own stuff. Here's where we pick what type of computer we'll be using for our River 5 server.

Now that you have an Azure subscription, log into the Azure Management Portal

When you first sign into Azure it may look a little intimidating because of all the stuff you can do.  Don't worry about all that stuff at the moment, you can explore later.  For now, click the + New and click Compute.  You'll see a wide range or servers you can start up and use.  As you can see it's not just Windows Servers.  These are pre-configured special purpose servers designed for databases, SharePoint and more. 

Click for a larger view

Your River 5 server will use the latest and greatest version of Windows Server: Windows Server 2016.  Don't pick the one you see in the menu though, that's a much beefier server than you'll need for River 5. We're going to pick something simpler to use for our River 5 server.  Click the See all blue text in the upper right corner.

Now click the Search box, type Windows Server 2016 and hit ENTER.  Now pick Windows Server 2016 Technical Preview 4. 

Click for a larger view

Another window will appear asking you about deployment model options.  Accept the default setting and click Create.

Click for a larger view

Step Three: Configure, start up and login to your server

Enter your server name and define a userid and password (make a note of these - you'll need them to login soon).  Select your Azure subscriptoin (created in the first step) and define a Resource Group. An Azure Resource Group is like a bucket containing all the information needed to manage the Azure service you're using. In our case the Resource Group will contain information about your server and it's networking capabilites.  Lastly, pick a location where your server will be hosted.  You should pick a location nearest you.

Once you've filled in this information click the OK button.

Click for a larger view

Now we need to select the size of our server.  There are many server sizes available in Azure - from simple and cheap to highly complex and expensive.  You'll initially be shown some recommended server sizes.  Ignore the recommendations and click the View all blue text in the upper right corner.

Click for a larger view

Server sizes are identified by a letter/number combination but you can also see each the specifications associated with each server size.  For this exercise we're going to pick the simplest server available: the A0.  Scroll down the list until you locate the A0 then click on it.  (Note: You'll see an estimated monthly cost for the server. You received a free $200 credit when you signed up so going through this exercise is free for you.)

Now click the Select button.

Click for a larger view

Back in the main menu again, pick the Public IP option, then pick Configuration.  Here's where we give your server a friendly name so you won't have to type in an IP address to reach it.  In this example I used "River5".   The address you'll enter into your browser will be the name you enter plus the additional text that appears below it.  In this example the address for my server will be http://river5.northcentralus.cloudapp.azure.com:1337  (:1337 is the port used by River5 - more about that in our next step).  Make a note of your URL - you're going to use it later to access your River of news.

Now click Save at the top of the screen.

 

Now we're going to open up the ports that your server will use to communicate with a browser like Chrome or Internet Explorer.  Click Network Security Group then click Inbound Security Rules. Add and save two inbound rules: one for port 80 and one for port 1337 as shown below.  Remember to click the Save button after entering each port!

   

We'll use the defaults for the rest of the options.  Now click the OK button and you'll see a summary of your server settings (on the far right): 

 

Click the OK button.  The setup will close and you'll land back on the Azure Management page. See that blue box?  That's Azure deploying and starting up your new server for you.  This may take a minute or so.

Click for a larger view

When your server is ready the blue box will change and look something like this:

Click for a larger view

Clicking on this box shows you information about your server.  Click Connect from the menu at the top.

Click for a larger view

This will download the configuration to remotely log into to your server.  Save this file to your desktop and double-click on it.  You'll see the following warning message because you've never connected to this server before. Click Yes to continue to the login prompt for your new server. 

Click for a larger view

Login with the userid and password you defined in step three above.  After a delay your new server's desktop should appear.  Congratulations!  You now have your very own server! 

Step Four: Server Housekeeping

We're almost ready to install River5. We need to clean up a few things to make your new server easier to use.  Servers are very different from desktops machines - they are typically locked down to be secure.  We're going to tweak some of these security settings to make your server easier for you to use.

If the Server Manager wizard appeared after you logged in, close it by clicking the "X" in the upper right corner.

Click to enlarge

First we're going to tweak a security setting that will enable you use the default browser known as Edge (servers are normally tightly locked down for security).  Click the Windows logo in the lower left corner, type RUN and hit enter.  This will pop up a command box.  Type SECPOL.MSC into the command box and hit enter.  The Local Security Policy Manager window will appear.

Click the Local Policies folder on the left and double-click Security Options on the right pane.  Now scroll down until you see the User Account Control: Admin Approval Mode for the Built-In... option (as highlighted in the picture below).  Double-click on it.

Click to enlarge

Click Enable then click OK to save.  Click the X in the upper right of the Local Security Policy Manager to close it.   

We're eventually going to have to restart your server to recognize the new security policy but not just yet.  Remember how we set up the ports in a previous step?  We're going to have to set up those ports in Windows Firewall to ensure they're working properly. 

Hold down the Windows key and press X.  Click on Control Panel in the pop-up menu.  In Control Panel change the View By option to Small Icons. Now click Windows Firewall and the firewall configuration window will appear.  Click Change Notification Settings on the left side of the window.  Click to be notified when Firewall blocks an app, as shown below:

Click to embiggen

Now we need to open the ports we set up in Azure.  Click the Advanced Settings from the left menu and click Inbound Rules.  We're going to set up two rules for the two ports we opened up in Azure.  Click New Rule from the menu on the right.  Click Port.

Click to enlarge

Leave all the defaults and enter 1337 for the specific port.  This is the port used by River5.  Click Next, select Allow the Connection and cick Next.

Click to enlarge

Leave the defaults and click Next

Click to enlarge

Assign the connection a name and click OK to save it.  You should also set up another Inbound rule for Port 80

Click to enlarge

Your server housekeeping is now done!  We just need to reboot the server because of the security policy change we made earlier.  To do this click the Windows button (lower left corner of the screen), click Power then click Restart. If you get prompted for a reason click Unplanned and continue for the restart to occur.  You'll lose your connection to the server when it restarts (the window will close).

Install and Set Up River 5 on Your New Server

Double-click on the configuration file you previously downloaded.  Log back into your server.  If the Server Manager wizard appeas click the "X" in the upper right corner to close it.

First we're going to download and install node.js.  Node.js is a server-based Javascript framework used by River5.  Start up the Edge web browser (blue "e" on the bottom left of the window) and download the installer for Windows.  After the installer finishes you can ensure node is working properly by:

  1. Hold down the Windows key and press R to pop up the Run prompt.  Type cmd and hit ENTER.  The Windows command line should appear.   
  2. Type node -v and hit enter.  Information about the version of node should appear.
  3. Type npm -version and hit enter.  Information about the version of the Node Package Manager should appear.

We're finally ready to install River5!  Using the Edge browser, download the River5 zip file

Right-click on the file and select Extract All.  You'll be prompted for the location you'd like to extract the files. I chose C:\Tools\River5 but you're welcome to choose whatever location you want. 

Hold down the Windows key and press R to open the Run prompt.  Type CMD and hit ENTER to open the command prompt again.

Navigate the folder where you extracted the River5 files.  If you extracted the River5 files to C:\Tools\River5 use the following commands:

  • cd \ and hit ENTER to go to the root of the C: drive
  • cd \Tools\River5 and hit ENTER

Once you're in this folder type npm install and hit ENTER.  This will install River5 on your server for you.

After the install completes running type the following command and hit ENTER to start River5: node river5.js.  You'll see some information scroll by about various news sites.

Open the Edge browser (on your server) and navigate to http://localhost:1337.  It may take a while for some news feeds to appear so be patient.  Eventually you will start seeing news feeds show up when you refresh the screen.

Set River5 to Start Automatically

You can set up River5 to automatically start in case your sever ever gets rebooted. This can be helpful in case of unexpected outages or restarts. First, create a simple batch file to run River5 by copying these commands and saving them into a file named run.cmd (note that you'll have to change the location of the River5 files if it differs from C:\tools\river5):

   @echo off
   cd \
   cd C:\tools\river5
   set NodePackagesPath=C:\tools\river5\node_modules 
   set Path=C:\tools\river5;C:\tools\river5\node_modules\.bin;%PATH%
   set Path=%NodePackagesPath%;%PATH%
   set NODE_PATH=%NodePackagesPath%\node_modules;%NODE_PATH%
   node.exe river5.js

Hold down the Windows key and press R to open the Run prompt.  Type regedit and press ENTER to open the Registry Editor.  The Registry is a special configuration that Windows uses to store information about the various programs you have installed.

Click to enlarge

On the left side click HKEY_CURRENT_USER, then click SOFTWARE and scroll down to MICROSOFT.

Scroll down to Windows and double-click it to open the tree structure underneath it.

Look underneath the Windows folder, locate the CurrentVersion folder and double-click it to reveal the tree structure beneath it.

Scroll down to Run and single-click it.

In the right side you'll see a few folders. Right-click in an empty area and click New.  Click String Value.  A new item should appear on the right side. Name it River5 and hit ENTER.

Double-click on the River5 entry you just created.  Type the full location of run.cmd into the Value box (e.g. C:\tools\river5\run.cmd).

You're finished.  Close the Registry Editor by clicking the X in the upper right corner.

You can also close the window for your server. It's ready to use!

Next Steps

You can now access your River from anywhere using the URL you noted previously (mine is at http://river5.northcentralus.cloudapp.azure.com:1337).

See Dave's post for directions on configuring your own specific news feeds and other options. Pretty much eveything is configurable.

 

   

 

 

 

Worker Roles vs. Web Jobs

1 min read

WebJobs are good for lightweight work items that don't need any customization of the environment they run in and don't consume very much resources. They are also really good for tasks that only need to be run periodically, scheduled, or triggered. They are cheap and easy to setup/run. They run in the context of your Website which means you get the same environment that your Website runs in, and any resources they use are resources that your Website can't use.

Worker Roles are good for more resource intensive workloads or if you need to modify the environment where they are running (ie. a particular .NET framework version or something installed into the OS). Worker Roles are more expensive and slightly more difficult to setup and run, but they offer significantly more power.

General rule of thumb: start with WebJobs and move to Worker Roles if you find that your workload requires more than WebJobs can offer.

 

Service Bus Refresher

12 min read

Re-post of an earlier blog entry, testing integration of my blog with Medium. Feedback/flames always welcome.

 

tldr;

Service Bus is a general term for an integration infrastructure that enables different systems or components to communicate through a shared interface, traditionally implemented as event-driven message queues.   Microsoft supports the service bus pattern across a number of products but this entry will only focus on two of them: Azure Service Bus and Service Bus for Windows Server.  These two products are sometimes simply referred to as "Service Bus" but it's important to realize their differences:

 

  • Azure Service Bus is a generic, cloud-based messaging system for connecting just about anything—applications, services, and devices—wherever they are. Connect apps running on Azure, on-premises—or both. You can even use Azure Service Bus to connect household appliances, sensors, and other devices like tablets or phones to a central application or to each other. 

 

  • Service Bus for Windows Server (SBWS) is a set of installable components that provides the messaging capabilities of Azure Service Bus on-premises. Service Bus for Windows Server enables you to build, test, and run loosely-coupled, message-driven applications in self-managed environments and on developer computers. 

 

Azure Service Bus and Service Bus for Windows Server are wire compatible via BrokeredMessages - this means messages generated by Azure Service Bus can be routed over Service Bus for Windows Server or Service Bus for Windows Server over Azure Service Bus.

 

Azure Service Bus and Service Bus for Windows Server share some common capabilities but also have fundamental differences.  See the sections below for more details on the differences and scenarios on which to use when.

 

Important Note: Service Bus for Windows Server lags behind the SDK support for Azure Service Bus due to the product team's "cloud first" approach. At the time this guidance was written Service Bus for Windows Server SDK was several releases behind the Azure SDK.  See the "Service Bus Releases" section of the Service Bus for Windows Release Notes for more information.  

 

Comparison of Azure Service Bus (ASB) and Service Bus for Windows Server (SBWS)

BrokeredMessages, Queues and Topics

  • ASB and SBWS both support BrokeredMessages.
  • ASB and SBWS both support a publish and subscribe pattern usingqueues andtopics.
    • With queues, each message sent to the queue is consumed by a single receiver.
    • With topics, messages are made available to each subscription registered with the topic. Each subscription logically maintains its own queue of messages. Subscriptions can also be configured with filter rules that restrict the set of messages passed to the subscription queue to those that match the filter.

Installation and support

  • ASB: Since ASB is a cloud-based service there is no software to install and support is provided by the Azure Team. OS and application patching and updating is also handled by the Azure Team. Storage is provided by and managed by the Azure Team. Backups and business continuity of ASB itself is managed by the Azure Team.
  • SBWS: SBWS runs on-premises and must be installed and configured on a Server 2013 or Server 2008 R2 machine (you can also install it on Win7 or Win8 for individual developer usage). SQL Server 2012 or 2008 is also required (Enterprise or Express versions). OS and application patching and updating must be handled by a local support team. Storage is provided by SQL Server and must be managed by a local support team. Backups and business continuity must be managed by a local support team.

Message Relays

  • ASB: ASB’s relay service supports direct one-way messaging, request/response messaging, and peer-to-peer messaging.  The Service Bus relay service enables you to build hybrid applications that run in both an Azure datacenter and your own on-premises enterprise environment.
  • SBWS: SBWS does not support relayed messaging.

Security

  • ASB: Shared Access Signature authentication (SAS) is the preferred way to implement authentication in Azure Service Bus.  SAS enables applications to authenticate to ASB using an access key configured on the namespace or the entity with which specific rights are associated. You can then use this key to generate a SAS token that clients use to authenticate to Service Bus.  See MSDN for more information on SAS tokens
  • SBWS: Solutions deployed on-premises using SBWS can use either Shared Access Signature authentication (SAS) or  Windows integrated security (Active Directory).  Applications can use SAS in scenarios in which they do not need to manage the notion of an authorized "user".  SBWS includes a Service Bus Security Token Service (SBSTS) which is fully integrated with the Windows security model. SBSTS can issue self-signed Simple Web Tokens (SWTs) using Windows identities. 

Quotas/runtime settings

  • ASB: Options regarding message and queue sizes are fixed due to the multi-tenant nature of ASB.  ASB Queue/Topic sizes can be up to 5 GB.  Messages can be up to 256K.  See here for specifics on ASB quotas.
  • SBWS: SBWS provides much greater freedom for configuring runtime settings and message and queue sizes.   SBWS Queue/Topic sizes can be up to 10 GB.  Messages can be up to 50MB.    See here for specifics on SBWS quotas.

Network latency

  • ASB: Network and security latencies may impact performance, especially when moving messages from on-premises to cloud or cloud to on-premises. Throughput could also be impacted by unexpected spikes in unrelated internet traffic.
  • SBWS: Administrators have much more control over their own network’s traffic and routing, thereby enabling more efficient bandwidth usage and throughput.

Addressing schemas

  • ASB: ASB Namespaces are fixed – all endpoints have a Service Bus postfix added to the URL to ensure uniqueness.
  • SBWS: SBWS uses fully qualified domain names (FQDN) or a mapped DNS entry to represent service namespaces.

Instances

  • ASB: In ASB there is only one "instance" of the service available and it is managed by Microsoft.
  • SBWS: With SBWS it is possible to have several on-premises SBWS servers via self-hosted servers or third-party providers.

Notification Hubs

  • ASB: Azure Notification Hubs provide an easy-to-use infrastructure that enables you to send mobile push notifications from any backend (in the cloud or on-premises) to any mobile platform.

 

  • SBWS: SBWS doesn't support Notification Hubs (although Notifications can be sent over SBWS).

Event Hubs

  • ASB: Event Hubs are highly scalable publish-subscribe event ingestors that can intake millions of events per second so that you can process and analyze the massive amounts of data produced by your connected devices and applications.
  • SBWS: SBWS doesn't support Event Hubs (although Events can be sent over SBWS).

 

What to Use When:

 

Use Azure Service Bus when:

  • Building cloud applications or services and requiring a scalable messaging system between components
  • Crossing cloud and on-premises boundary
  • Message transformation or service orchestration are not required
  • Support for B2B integration is not required (AS2, X12, EDIFACT, …)
  • Relaying small messages (256 KB or less), which may contain the payload itself or may be notifications for the availability of larger payloads to process from Azure Storage Blob (see http://msdn.microsoft.com/en-us/library/hh690942.aspx)
  • You need to support AQMP in a cloud or hybrid architecture
  • Distributed Transactions (DTC) is not required
  • You need to build hybrid applications that run in Azure datacenter and on-premises without having to open a firewall connection or require intrusive changes to a corporate network infrastructure. (See note below regarding Service Relay vs. Hybrid Connections)
  • You need to support mobile push notifications from any backend (in the cloud or on-premises) to any mobile platform.
  • You need to integrate with and analyze large volumes of events on a near real-time basis (e.g. IOT, RFID and similar scenarios)

 

Use Service Bus for Windows Server when:

  • Publishers and Subscribers are all on premises.
  • Message transformation or service orchestration are not required
  • Support for B2B integration is not required (AS2, X12, EDIFACT, …)
  • You need to support large Queues/Topics or (up to 50 MB) or Messages (up to 10 GB)
  • You need to support AQMP on-premises
  • Distributed Transactions (DTC) are not required

Use BizTalk (on-premises BizTalk Server or Azure BizTalk Services) when:

  • Brokered application-to-application message-based integration with data mapping and diverse communication mechanisms are required
  • You need to support service orchestration (on-premises) or workflows (cloud)
  • You need to support Content-Based Routing (CBR)
  • Dealing with long-running processes or configurable business rules
  • Implementing B2B standards (e.g. EDI, AS2, X12, EDIFACT others) for multiple trading partners
  • Integration with popular LOB systems (such as SAP) is required 
  • Visibility into integrated processes via BAM is required
  • You need simple, configurable business rules implemented by a broker

Use MSMQ when: 

  • You need to support simple asynchronous communications between on-premises Windows applications
  • Senders and receivers are not running at the same time
  • Message level logging is required
    • MSMQ makes a useful lightweight local transactional queue to support durable messaging when on-prem (especially if you’re using HTTP)
  • You aren't deploying into Azure (MSMQ isn't available in Azure)

 

A note on Service Bus Relays and Hybrid Connections

When connecting from Azure to on-premises Azure Service Bus Relays and Hybrid Connections initially seem to provide similar capabilities.  Service Bus Relay relies upon Service Bus and WCF while Hybrid Connections relies upon BizTalk Services. Here are some simple guidelines on when to use one over the other. 

 

Use Service Bus Relay when:   

  • You need to build hybrid applications that run both in Azure and on-premises
  • You need to enable a hybrid architecture at a lower cost than using BizTalk Services
  • You need to connect to a WCF service using WCF relay bindings
  • You need support for ACS security
  • You need to configure your own listening component or a WCF Service to use a relay binding
  • You need to avoid installing or using a special "agent" to configure and connect to on-premises web services
  • You can only support web service integrations via ACS
  • You need to consume web services from on-premises (not within Azure)

 

Use Hybrid Connections when:   

  • You need to consume on-premises resources (not just web services) from Azure, not from on-premises
  • You need to connect via any port
  • You need to connect to something other than a WCF service (e.g. an application or a database)
  • You need to support Shared Access Signatures
  • You need to integrate with non-.NET technologies in a hybrid architecture 
  • You need to connect to on-premises resources from Azure using BizTalk Services 

 

Scenarios

Service Bus for Windows Server

 

Azure Service Bus

Performance and Scaling

Azure Service Bus (ASB)

 

Service Bus for Windows Server (SBWS)

  • SBWS supports both scale out (add more compute nodes and databases) as well as scale up (add more memory and CPU to the existing nodes). These two main scenarios lead to different approaches: When a Service Bus farm is planned to support many topics and queues each with low\medium throughput, a scale out approach is recommended as you can keep adding databases and nodes. However, when high throughput of small numbers of topics and queues is expected, it is recommended to add more CPU and memory to your existing hosts and database servers.
  • For more details see MSDN for SBWS Performance Considerations

Business continuity   

Azure Service Bus (ASB)

 

 

Service Bus for Windows Server (SBWS)

 

Security

 

Manage

  • Deployment:
    • Azure Service Bus:
    • Service Bus for Windows Server:
      • SBWS runs on-premises and must be installed and configured on a Server 2013 or Server 2008 R2 machine (you can also install it on Win7 or Win8 for individual developer usage). SQL Server 2012 or 2008 is also required (Enterprise or Express versions). OS and application patching and updating must be handled by a local support team. Storage is provided by SQL Server and must be managed by a local support team. Backups and business continuity must be managed by a local support team.
      • See MSDN documentation on Planning and Configuring SBWS
      • See MSDN documentation on Managing Service Bus for Windows Server
      • See MSDN documentation on using Service Bus Explorer with Service Bus for Windows Server

 

 

 

Troubleshooting:

 

Tools and Scripts

 

References and Resources

 

"Modern Apps" - I Know It When I See It

1 min read

I really dislike using the term 'modern app' when describing architecture because it lacks a clear definition. If you ask three different architects what a "modern app" is you're likely to get three or more different perspectives on it.

Much like SOA or art, some people know it when they see it but have difficultly describing it clearly.

I took a shot at this quite a while ago here on my old MSDN blog.  

 

 

 

Quick look at hybrid architecture in Azure

1 min read

A quick look at some hybrid architecture options in Azure.