Cost comparison between Azure Service Bus Queues and RabbitMQ

This post is a follow up to the UK Azure User Group presentation I gave yesterday about running RabbitMQ in Azure.

When deciding on messaging system to use in your cloud solution, one of the consideration will be the cost. Azure offers Service Bus Queues and Topics as PaaS, but it also offers Virtual Machines (as IaaS) which you can use to host other messaging brokers, meaning you can host your own RabbitMQ cluster in Azure.

RabbitMQ

The cost of running a RabbitMQ cluster in Azure can be calculated as a monthly cost of Virtual Machines which consist the cluster. If you want to build a cluster with 3 large instance (4 vCPU, 7GB RAM) running Linux OS, then your monthly cost will be £340.91 or $535.68 (check Azure Calculator for other currencies).

With 3 node cluster you can replicate the same capabilities for you messaging broker as in Service bus: messages being replicate to 3 nodes and high cluster availability. It also gives you very decent performance of few thousand “reliable” messages per second, or tens of thousand “transient” messages a second.

Bear in mind that I haven’t included any cost related to maintaining Virtual Machines. In your calculations you will need to include that as well, but the cost depends much on the efficiency of a person maintaining Linux and RabbitMQ.

Visual Studio Debugger Tips and Tricks: Tracepoints

This time I want to present you Tracepoints in Visual Studio debugger. Tracepoints are special kind of break points which allows you to specify an action to execute when hit. The most common case for trace point is to print some tracing message. Let’s look at the example. Below is the code that generates all possible combinations of numbers in given range1 and performs some processing on those:


  1. This example is from the article “Association Rule Learning” by James McCaffrey published in MSDN Magazine 

Give life to parameter objects (part 3): DebuggerDisplayAttribute

Previous posts in the series:

In this post I want to show you how to enhance debugging experience. Last time we left with an object which was representing list of method parameters related to the person (for this post I renamed that object to Person). Now, when debugging an application the new object will be shown as a type name, and to see any values you need to expand it:

But there is an easy way to provide custom value which will be displayed in the debugger by default. Lets say for example that the key properties are fullname (the new property we added last time) and age. All you have to do is to add a DebuggerDisplayAttribute to the Person class with a string representing the value to show:

As you can see, the string is using property names wrapped in curly braces. Now the debugger will show nicely formatted text:

As you can see, the string is using property names wrapped in curly braces. Now the debugger will show nicely formatted text:

This will work everywhere: when you hover over the variable, in Locals, Autos or Watch debugger windows and Data Tips. Event in the Call Stack window assuming option Show Parameter Values is on (read more about it in this post).

You can show as many properties as you want in the debugger, but there are performance considerations. You can find more details in the Using DebuggerDisplay Attribute article on MSDN. You will also find there a suggested solution which is to create a private method and use it’s result in the DebuggerDisplay:

See other posts in the series:

Give life to parameter objects (part 2)

In the previous post I wrote about my usual second step in refactoring to Parameter Object – moving related validation code. This is really easy to do and greatly de-clutters the method. Now it is a time to scrutinise code more and move behaviour which belongs to our new parameter object.

The first suspects on my list are various conditional statement which operate on parameters, like in the below example:

public void myFunction(myMethodParams theParams)
{
   // ...
   if (age < 18)
   {
      // case for minors
   } else {
      // case for grown-ups
   }
}

The condition in line 5 is a perfect candidate for refactoring. We can move the logic into myMethodParams class and give it a nice, meaningful name:

public bool IsUnderage
{
   get { return age < 18; }
}

This works even nicer for conditions based on more than one boolean expression.

Another candidates are operations on data. For example, lets assume that at some point we need a full name. Instead of keeping the operation scattered in the code we should move it to a property of myMethodParams class:

public string FullName { get { return String.Concat(_name, " ", _surname); }

Summary

Moving behaviour to the object gives us a chance to pick nice meaningful name for it, make the code cleaner and easier to understand. Very often it also helps to remove code duplication. Step by step the parameter object transforms into a business object which describes Person. From the experience I noticed that applying those refactorings help people making the first step into OOP. It allows to understand that application doesn’t have to live in the main function. That domain objects have both – data and behaviour, and the application is an interaction of those objects.

See other posts in the series:

Give life to parameter objects.

In his article “Using Objects as Parameters in C#” Peter Shaw explains common problems with methods having large number of parameters and shows how to refactor those to use objects.

I would actually take that example further. Once you extract an object from parameters you may start moving behaviour, and one of the things I do first after Introducing Parameter Object is to move validation code to new object. For example, lets say that we have following business rules:

  • age has to be greater than 0
  • name and surname cannot be null neither empty