Deploying Service Bus for Windows Azure Pack

Many organizations worldwide has implemented many Azure Pack solutions over the last months.

Especially the VM Cloud has been a highly appreciated resource provider in this solution, but we are also seeing more and more adoption of the PaaS offerings, such as Web Site Clouds and SQL Server Clouds.

Recently, I’ve been implementing the Service Bus Cloud too, which is very relevant for the other PaaS I just mentioned.

Eh, Service Bus? What’s that?

My first meeting with Service Bus was back in 2008 when Windows Azure was new.

In a nutshell, Service Bus provides messaging capabilities that enables you to build, test and run loosely-coupled message-driven applications.

This was something we first saw in Azure, where the developers could take advantage of this scalable service.

Later, we got Service Bus for Windows Server which provides similar capabilities as the ones we find in Azure (one consistent platform), which gives flexibility in developing and deploying applications. It is built on the same architecture as the Service Bus cloud service and provides scale and resiliency capabilities.

What about Azure Pack in this context?

Again, we will return to the Cloud OS vision with the one consistent platform. A developer can now easily develop, test and tune their applications using Azure Pack on-premise. In this case, perhaps they do not have a 24/7 environment where the IT organizations are watching things closely, or do not provide the required support outside of business hours.

Now, the developer and its organization can turn to a service provider who offers the same Azure technologies delivered through Windows Azure Pack. In this case, the service provider will be responsible for the entire Azure Pack environment where these services are living and provide support and ensure business continuity.

Therefore, as a result of having the same platform, this customer can easily deploy the same applications to the service provider cloud using the same experience as on-premises, once they move to production.

The next step is of course to leverage the hyper-scale cloud of Microsoft Azure, which again, has the same capabilities as delivered through Azure Pack.

To summarize, we have a very flexible deployment options now using the Cloud OS where each tenant are able to take advantage of the most appropriate cloud option for their applications.

Great, now I understand a bit more, but what kind of features do we have for Service Bus using Azure Pack?

As stated earlier, the Service Bus on-premise supports the same brokered messaging feature set as Microsoft Azure Service Bus. Service Bus queues offer reliable message storage and retrieval with a choice of protocols and APIs.

First of all, we have the Service Bus Queues which provide load leveling by allowing the message receiver to process messages at its own pace. Service Bus provide load balancing by having multiple competing receivers that accept messages from the same queue.

Next, we have Service Bus Topics which provide rich publish-subscribe capabilities that enable multiple, concurrent subscribers to independently retrieve filtered or unfiltered views of the published message stream.

.

Deployment of Service Bus for Windows Azure Pack

You should at least start with a new virtual machine running Windows Server 2012 R2.

Next, download and install Web Platform Installer so that you can get your hands on the “Windows Azure Pack: Service Bus 1.1” component. Yes, this one is also provided in the same way as every extension, site and API for the Azure Pack.

After the installation, you will find the “Service Bus Configuration” located under Apps.

This will prompt you with a wizard that need some inputs so that you can configure the service bus service.

The options you have is to either create a new farm using the default settings, custom settings, or add to an existing farm.

In this case we will create a new farm using the default settings.

The Service Bus requires a SQL in the backend, and we will use an already existing SQL Cluster to ensure HA for our services. Specify name, username and password and test the connection before you proceed.

Service Bus also requires a service account. Once created in AD, assign the name and the password.

Under Certificate Generation Key, you must specify this and re-enter it in the box below. Please keep a record of this key for future use as you have to provide it every time you add a computer to this farm.

The configuration cmdlets use this key for generating certificates.

The option for “Enable firewall rules on this computer” should be enabled so that the configuration wizard creates required firewall rules. Only uncheck this box if Service Bus clients (applications) will run on the same server as Service Bus.

The last section of the configuration page is where you will enable the Service Bus to be managed by the Service Management API in Azure Pack.

Set the usernames and passwords which are used to secure API calls between the portal and the Service Bus farm.

In the end, you will get a summary that shows your configuration and click finish to proceed.

Adding the Service Bus Cloud to Windows Azure Pack

Logon to the admin portal as an administrator and navigate to the Service Bus Cloud.

Click on “Connect to an existing Service Bus cloud” to register with the endpoint.

Fill in the required information that connects you to the API. Once completed, you will have you new Service Bus Cloud added to WAP.

In order to expose the capabilities to your tenants, you need to present this offering through a Hosting Plan. Either create a new Plan meeting your requirements, or simply add to an existing Hosting Plan to extend your service offerings. In our case, we are adding the Service Bus cloud to an existing Plan.

Heading over to the tenant portal, we can see that the Service Bus offering is made available and that I have already created my first Namespace.

Next, I can go ahead and work with queues, topics and use this as part of my applications.

Happy developing!