The other day I was at Juval’s presentation where the main message was WCF is a better .NET. In other words, if you use WCF on every one of your classes, you’ll benefit. I don’t know about you, but I’m quite wary of silver bullets – they tend to inflict quite a bit of pain when used indiscriminately. This post is my response to all the people who came up to me at the end of the presentation and wanted to know if I agreed with these far-reaching architectural statements.

First of all let me say that Juval is indeed a master presenter. The “looks like a class, walks like a class, quacks like a class” bit was excellent. I could tell that most people didn’t notice the speedy hands quickly deleting all attributes from the classes before the “looks like a class…” bit. At times, I got flashbacks from the Wizard of Oz – “pay no attention to the man behind the curtain”. If all attributes in WCF only went on the interfaces, then this might actually fly, but we all know that that’s not the case.

One of the interesting comparisons Juval made with WCF was the introduction of .NET. Few people in the audience seemed to remember (or maybe were just professionally younger than .NET’s 8 years), but when it came out .NET was marketed as being mainly about XML Web Services. Juval stated that this was done to play down the fact that .NET made the previous Windows programming technologies obsolete. He then drew the same conclusion about WCF – that it’s as much .NET 3.0 as .NET was the next version of MFC; besides being written in a language that resembles the previous technology, it’s really all different. I don’t think that anyone would argue the difference, but is it really a “plain .NET” killer?

The answer seemed to come around the overhead of WCF – yet Juval deftly deflected that issue with a demo showing WCF doing 200 calls a second. And everybody just bought it – I was shocked. That’s 5ms per call. If you actually take Juval’s advice and use WCF on all your classes, you’ve bought yourself one hell of a performance nightmare. Say you have around 20 of your objects involved in a sequence to handle a user action – not that many actually. With a 5ms lag per object interaction, that user action is going to take 100ms – not including any database or webservice stuff you might be doing. If you do that in a server environment, you’ll be doing roughly 10 concurrent users per core. And that’s not even doing any heavy calculations or anything. Moderately sized systems are running upwards of 1000 concurrent users – if they needed 100 cores (or dozens of servers) for that, I’m guessing that they’d be out of business.

Let’s cut this short – WCF everywhere doesn’t scale, doesn’t perform, isn’t maintainable, or testable either. In other words – don’t do it. I know Juval is a brilliant guy, and an amazing presenter – but I don’t believe he would be employing this with his own clients. This actually bears repeating. WCF is a fine technology for your application’s boundaries, but don’t be pushing it in.

Don’t do it.

After my recent post on using AOP for smart client development, my partner-in-crime, Arnon, suggested I explain a little bit more on the whole issue of multi-threading in the UI. This isn’t going to be another tired explanation of how you should only update controls on the main thread. This is going to be a post on the challenges multi-threading brings and how to address them.

Multiple Threads – Why?

One of the properties of smart clients is that they should be able to work offline. Sometimes that means an explicit action of taking data and bringing it to the local machine so that the user can work on it, and other times it just has to do with the fact that wireless connectivity can be flaky. More interesting scenarios include the submission of batch jobs and receiving notification on when they complete. The bottom line is that the user should be able to continue doing their interactive work uninterrupted as all this is occurring.

While the user is disconnected, obviously the data they are working on is local – the client is not calling the server to perform the work on its behalf. However, in the flaky connectivity scenario, this happens all the time. In other words, the design should be the same for handling all scenarios. One thread for interacting with the user, and (at least) on other thread for handling the issues of connectivity. The one thing that is clear is that we are going to have data on the client with which the user interacts on one thread, and which the background thread will also be updating as notifications arrive from the server.

Local Data and Multi-Threading – a Recipe for Disaster

When multiple threads are working with the same data, unless some specific code is in that object to make it thread-safe, there’s a good chance that object will end up in an inconsistent state. This can be catastrophic if we’re talking about air traffic control systems, dispensing medication, factory floor automation, etc. The problem is that we can’t just lock down the entire system whenever something needs to be done. While in some cases I’ve seen projects make each object thread-safe, implementing some base class for handling locking, that doesn’t work between objects and results in deadlocks.

Just as an example of the multi-object problem, consider the doctor prescribing medication for a patient. Now, the data about a patient in a smart client is not all on the Patient Object – there are lists of connected test results, medication already being taken, which nurses and doctors have treated this patient so far, etc. As a test result gets pushed to the client from the server, a new doctor unfamiliar with the history of the patient orders the same test again. These two objects under Patient – TestRequest and TestResult are being acted upon by different threads. One of the goals of the system was to eliminate duplicate testing for patients – cited as costing the hospital chain millions of dollars a year. Good thing we addressed the cross-object multi-threaded locking thing properly 🙂

Always Switch from Background to Foreground?

One solution I’ve seen used successfully is to always change threads from background to foreground whenever an update comes in from the server. This works when you don’t have many updates or the work performed on the client as a result of an update doesn’t take long. Always keep in mind, though, the flaky connectivity scenario. What tends to happen is that server notifications bunch up and then hit the client all together. When this occurs, clients developed this way are rendered unusable.

It would seem like this solution isn’t valid because of the above, but don’t dismiss it so quickly. This is an easy solution to implement that may address your specific environment and, as such, be cost effective. A large part of the work I’ve been doing is to make the more complex environments just as easy to develop as these simpler ones.

Infrastructure-level, Safe, Multi-Object Locking

Luckily for us developers, in the .net framework there is a class that handles this for us – well, 2 actually: ContextBoundObject and SynchronizationAttribute. When using these two classes, we can create something known as a Synchronization Domain which acts as a global lock for all objects belonging to the synchronization domain. What this means is that if the user thread is trying to add a test request object while the background thread is already creating a test result object, the user thread will block automatically until the background thread completes its work.

There is only one teensy-weensy problem – ContextBoundObjects are really heavy-weight. The last thing you want is having millions of these running around in your client – you’ll end up with a multi-threading safe unusable UI. Also, the creation of an object inheriting from ContextBoundObject takes quite a bit longer than a plain-old.net object. In other words, technology by itself will not solve our problems – we need some patterns for the correct use of the technology so that we can maintain a reasonable level of performance while taking care of safety.

MVC and Threading – Controllers

Regardless of which flavour of MVC you prefer (I’m in the Supervising Controller camp for smart clients), the logic controlling what goes on in the client is found in the controllers. What this means is that actions from the user as well as background notifications will need to go through these controllers. It is important that these controllers be thread-safe since they are state-full – managing which windows are open, which step in a given process a user is currently doing, etc.

The characteristics of these controller objects which make them best suited to inherit from ContextBoundObject are that there are only a handful of these objects at any point in time and that they are created at startup – they’re singletons (in the “only-one-of-them” sense of the word).

The only special thing that controllers need to do in terms of threading is to dispatch calls to view objects on the foreground thread, even if the thread currently running is the background thread. For example, popping up a “toast” that a test result has arrived when a notification from the server comes in.

These elements – inheriting from ContextBoundObject, use of the SynchronizationAttribute, and thread-switching can be pulled up in to a BaseController class:

using System;
using System.ComponentModel;
using System.Runtime.Remoting.Contexts;

namespace ControllerFramework
{
    [Synchronization(SynchronizationAttribute.REQUIRED)]
    public class BaseController : ContextBoundObject
    {
        protected ISynchronizeInvoke invoker;
        public ISynchronizeInvoke Invoker
        {
            get { return invoker; }
            set { invoker = value; }
        }

        protected void MarshalToUiThread(Delegate toCall, params object[] parameters)
        {
            if (this.invoker == null)
                return;

            if (this.invoker.InvokeRequired)
                invoker.BeginInvoke(toCall, parameters);
            else
                toCall.DynamicInvoke(parameters);
        }
    }
}

Well, I think that this is long enough for a single blog post. In the next instalment of this series I’ll be talking about how model objects and views fit into the multi-threaded smart client. After that, we’ll be seeing how service agents, messaging, and service contract design need to be done in this style. While all this blogging will be going on, I’ll be getting a software factory up that will tie all these patterns and frameworks together so that all developers will be able to write thread-safe, high-performance smart clients without needing a doctorate in computer science – not that I have one 🙂

Questions? Comments? Thoughts?

It’s one of the things that sometimes drives me mad about the YAGNI philosophy of Agile.

We need to stop throwing out the baby with the bath water.

Jay really liked that statement with relation to my previous post “Scalability – you wish you’re gonna need it“, so I thought I’d put up a logo for this movement. Anyone feeling like joining in, leave a comment, link, or whatever.

I understand that we don’t need to over-engineer everything, putting in every possible kind of extensibility point, so I accept that part of YAGNI. That is not a license to not think about the extensibility points you do need.

<Remarks>

This is a somewhat tongue-in-cheek post, and I do not want the pendulum to swing to far back the other way. But I do think it’s time it took a step back from the over-zealous “we’ll TDD our way there” thinking. Maybe Ron can pull it off. I’ve yet to see anyone else succeed.

</Remarks>

I wanted to follow up on my recent post, “In order messaging a myth?” by showing the exact code that solves the issue. I have a podcast waiting to come online that deals with the specifics, so keep your eye out for that too.

The important thing to note is that if we just automatically return the message to the queue, we may get “stuck” with that message if the first PolicyCreatedMessage never arrived. This opens us up to a Denial-of-Service attack by quite simply flooding us with a bunch of messages that never get cleaned up.

Anyway, the general idea is to first try the regular happy path, and only if we see that prerequisite data isn’t available, do we see if another thread may be working on that data. This is done by decreasing the isolation level of our transaction from the regular ReadCommitted to ReadUncommitted. This will enable our thread to see if some other thread inserted the policy in to the Policies table but hasn’t committed its transaction yet.

The next step will be how we take this code and make it generic, so that we don’t have write the same code over and over again for the different kinds of message handlers we have.

But that will have to wait until the next installment 🙂

“Is it still valid to assume it is more expensive to design a scalable system?”

In Gavin Terrill’s news post on InfoQ, Big Architecture Up Front – A Case of Premature Scalaculation? he covers one of the questions so many of my clients deal with:

“How hard will it be to make it scale later?”

This is a valid question, especially for companies/products just beginning their lifecycle. When the product/web site isn’t bringing in any revenue yet, how much money should we spend on getting it ready for that future success?

The answer to that question lies in treating capacity and scalability differently (source).

What I mean by that is designing for scalability, yet separating out all technological aspects of the scaling from the core solution. That way, you can start with simple, low capacity technologies that won’t be too expensive. As you grow, upgrade that infrastructure and plug it in to your solution. Arnon’s recent post on Tier Splitting touches on a project we worked on together where we designed it in a way that we could scale down to a single process on a single machine and scale out to a server farm, all without changing the core system.

Let me take the design of nServiceBus as an example:

One primary property of scalable systems is the explicit treatment of all IO/communication. This can be seen in the one-way messaging exposed by the Bus object. There is no immediately evident way to do synchronous RPC-style request/response. This design decision is taken up front. However, the way that messages are passed around is abstracted behind an ITransport interface. You can deploy the first version of your system on MSMQ, and as load increases, switch to a more performant solution like RV or MQ, just by changing configuration. WCF does this kind of abstraction as well.

Another important element of the scalability of a system is how workflow instances are persisted. This behaviour is also abstracted behind an interface – IWorkflowPersister. Start out persisting workflows to a database. As you grow, swap that out of a replicated in-memory cache. In any case, the interaction between workflow and messaging at the logical level is set up front. All the pieces of the design are there. Up front. Helping you design your core application in a way that won’t limit your scalability in the future.

This is plain Separation-of-Concerns; code that works with your specific ESB kept out of your business logic.

Design first, scale with technology later.

[Full disclosure: I’m an editor for InfoQ]

I got this question the other day from one of my long-time readers Bill about nServiceBus and I thought I’d share:

I have a question around processing of messages in proper order.  When leveraging multiple threads to process messages in a message queue, it is possible for the second message in the queue to get processed before the first – especially if the first message is considerably larger than the second.  I have taken a lot of care to make sure that messages are sent in the correct order, only to find that the receiving system can process them out of order anyway.

Consider a Policy Created notification, which must come before a Policy Approved notification.  If both messages are sitting in the queue when the receiving service starts up, the approval message can be processed before the creation message. How can I make sure that message ordering is respected by the receiving system?  I am using WCF/MSMQ as the underlying transport by the way.  The only way I have found so far is to limit the receiving service to a single thread, which is by no means desirable.

Well, the solution is really quite simple (at first).

If you’ve received a message that you think has arrived out of order, just call:

this.bus.HandleCurrentMessageLater();

and that will put the message back at the end of the queue.

Once you start considering the fact that you don’t know when the first message is supposed to arrive, you might turn to using a workflow to handle the logic. The workflow would store the policy id, and then allow for N round-trips, before it decided that something bad had happened (like the Policy Created message getting lost), and then it could forward that to an operator, or possibly contact the first system and ask for a replay of the policy created message – or whatever automated fault resolution protocol you like.

In other words, message ordering is probably more trouble than its worth.

If you’ve read my recent post on the threading issues I’ve been dealing with in Smart Client Applications, then you’re probably beginning to get the picture that its fairly complex. To tell you the truth, it is. And up until this point I haven’t been able to find anything that’ll help – and that includes the CAB/SCSF. But yesterday I had my epiphany. The answer was in AOP.

You see, the main problem that I hadn’t been able to solve was that in order for the code to be thread-safe, you had to make sure that no code in the views would/could change entity data. One solution is not to use data-binding, which sucks, but isn’t enough to be sure. Another solution is to have all supervising-controllers clone an entity before they give it to a view. Even if you could possibly code review every line of those classes, the new guy (or old guy who forgot) will, by accident, write one new line of code that could pass an entity to a view without cloning it first. That’s not a very sustainable solution.

This thing has been bothering me for a couple of months now and I hadn’t found a way around it. Until yesterday, like I said. I was talking to somebody about threading stuff, and somehow my unconscience lobbed me this thought about AOP. Now I’m not the sharpest pencil in the pack, but I know to listen when my unconscience “speaks”.

So I set about going over what I knew about AOP – interceptors, advisors, advice, introductions, etc, etc. And then it dawned on me. I could intercept all calls to any object that implemented IView, check the parameters of those calls, and if they implemented IEntity, to clone them before passing them through.

<Homer-style WOOHOO />

The great thing is that developers don’t need to remember to clone entities – it happens automatically. The even greater thing is that this will lead developers to writing the correct kind of interaction between their views and supervising controllers.

Together with nServiceBus, this is going to make the extremely difficult problem of writing thread-safe smart clients possible.

I’ve never made use of AOP in a framework before so I’d like to get the broader community’s feedback on this before incorporating this in production. I’ve spoken with some serious AOP folks who have allayed most of my uncertainties, but I’d like to hear more. Anyway, here’s the proof of concept (that makes use of Spring).

If this turns out to be a viable solution, I think we’ll have a solid environment for building a software factory on top of. That is something that I’m really excited about. In this multi-core future (present) that is upon us, multi-threading on the client is pretty much a necessity. We need a way to get things safe and stable by default without requiring a member of the CLR team to hold our hand.

Anybody who’s interested in helping, drop a comment below.

Last week I was at a client in their test lab and saw a strange bit of behavior. The system could be described as something like an air traffic control system, showing things moving around on a map. For just a second, a fraction of a second, one of the “planes” disappeared from the map and then reappeared again.

When I asked if anybody else saw it, one of the developers said, “Yeah, that happens sometimes – but it fixes itself right after that.”

“What if the user sends a command to the server making use of that location?”, the PM asked. “Could that cause them to collide?”

You could hear a pin drop.

After everyone got passed the preliminary shock, we got down to work. I asked if I could look at the logs, but after more than an hour, I found nothing. No reason to explain the strange behavior. I suggested doing some more instrumentation so that whenever a location changed on the client-side entities, we’d write that to the log.

After that, we ran the system again in the lab under the expected load (several hundred things moving every second, and the user doing the expected activity) and didn’t notice anything. An intern “volunteered” to keep working the system while the rest of us went to lunch. When we came back, he told us that everything seemed to be working OK.

These Heisenbugs are the things that keep me up at night.

“Watching the system changes its behavior”, one of the older devs nodded his head sagely.

Just as we were about to leave the lab another one of the developers gave a shout, “It did it again!”. We quickly stopped the system. Opened the (rather huge) log files and looked for the latest entries.

There it was.

A context switch between setting the latitude and longitude of an entity.

That should not have happened. Not that context switches don’t happen, but rather that it should have been impossible by design. We had made use of synchronization domains and the appropriate patterns so that two threads could never concurrently be working on the same instance of an entity. The synchronization features baked in to nServiceBus had taken care of everything up to that point.

Before getting into the threading solution, I want to address a specific alternate patch that was deployed in the meantime:

The solution for the long/lat problem was simple – just make Location a value object and use a single setter for it rather than one for Latitide and another for Longitude. We were still worried about other bits of data that were correllated in the domain – things that couldn’t be solved the same way.

After getting 3 grizzled C++ veterans in the room, we did a code walkthrough of the threading model of nServiceBus. We went through the nitty gritty details of synchronization domains, how the Bus object was outside of the domain, why that was important for user experience, how the message handlers couldn’t be ContextBoundObjects because of the performance impact of creating and destroying them at a high rate, why they couldn’t just be singletons, why they still had to run in the synchronization domain, so that the UI thread couldn’t work on the same (or related) objects at the same time, etc, etc.

And then it hit me.

The bus was communicated directly with the message handlers.

After the Object Builder created the message handler, the bus dispatched the message to the handler directly. And since the bus was outside the synchronization domain, then the thread calling into the handler wouldn’t have locked the domain, leaving the UI thread open to go in and touch those very same objects.

They say that really understanding the problem is 90% of the solution. I’m hoping to meet them some day, because they’re really smart.

All that we needed to do was have the Object Builder dispatch the message to the handler instead of the bus – since the builder was configured to be in the synchronization domain (on the client side). Something as simple as just adding the method:

So, instead of the bus using this code:

It would do:

[Just FYI, this is now up on the sourceforge site]

We redeployed the system to the lab, ran all the functional, stress, load, etc tests and everything appeared to be stable. The system has been under scrutiny for the past 4 days by batteries of testers instructed specifically to look for those strage kinds of behavior. Other developers are running scripts on the log files looking for other kinds of context switches that may have been missed by the testers. I am happy to report that they haven’t found anything.

Not that this means that the problem isn’t there. We really can’t be sure. However, the PM has decided that we are stable enough to go into pilot mode – deploying into production beside the current system; having users work on both systems at the same time. I’m optimistic.

I’m personally involved in two more production-projects that are making use of nServiceBus in similarly high-end situations and we’ve never had these threading problems – now two years running.

That was an interesting week.

You can now find my talk from TechEd – ARC401 Designing High Performance, Persistent Domain Models – online. You have to log in to the TechEd site first, otherwise the DRM will block the video.

Enjoy.

Watch in Media Player

Often during my consulting engagements I run into people who say, "some things just can’t be made asynchronous" even after they agree about the inherent scalability that asynchronous communications pattern bring. One often-cited example is user authentication – taking a username and password combo and authenticating it against some back-end store. For the purpose of this post, I’m going to assume a database. Also, I’m not going to be showing more advanced features like ETags to further improve the solution.

The Setup

Just so that the example is in itself secure, we’ll assume that the password is one-way hashed before being stored. Also, given a reasonable network infrastructure our web servers will be isolated in the DMZ and will have to access some application server which, in turn, will communicate with the DB. There’s also a good chance for something like round-robin load-balancing between web servers, especially for things like user login.

Before diving into the meat of it, I wanted to preface with a few words. One of the commonalities I’ve found when people dismiss asynchrony is that they don’t consider a real deployment environment, or scaling up a solution to multiple servers, farms, or datacenters.

The Synchronous Solution

In the synchronous solution, each one of our web servers will be contacting the app server for each user login request. In other words, the load on the app server and, consequently, on the database server will be proportional to the number of logins. One property of this load is its data locality, or rather, the lack of it. Given that user U logged in, the DB won’t necessarily gain any performance benefits by loading all username/password data into memory for the same page as user U. Another property is that this data is very non-volatile – it doesn’t change that often.

I won’t go to far into the synchronous solution since its been analysed numerous times before. The bottom line is that the database is the bottleneck. You could use sharding solutions. Many of the large sites have numerous read-only databases for this kind of data, with one master for updates – replicating out to the read-only replicas. That’s great if you’re using a nice cheap database like mySql (of LAMP), not so nice if you’re running Oracle or MS Sql Server.

Regardless of what you’re doing in your data tier, you’re there. Wouldn’t it be nice to close the loop in the web servers? Even if you are using Apache, that’s going to be less iron, electricity, and cooling all around. That’s what the asynchronous solution is all about – capitalizing on the low cost of memory to save on other things.

The Asynchronous Solution

In the asynchronous solution, we cache username/hashed-password pairs in memory on our web servers, and authenticate against that. Let’s analyse how much memory that takes:

Usernames are usually 12 characters or less, but let’s take an average of 32 to be sure. Using Unicode we get to 64 bytes for the username. Hashed passwords can run between 256 and 512 bits depending on the algorithm, divide by 8 and you have 64 bytes. That’s about 128 bytes altogether. So we can safely cache 8 million of these with 1GB of memory per web server. If you’ve got a million users, first of all, good for you 🙂 Second, that’s just 128 MB of memory – relatively nothing even for a cheap 2GB web server.

Also, consider the fact that when registering a new user we can check if such a username is already taken at the web server level. That doesn’t mean it won’t be checked again in the DB to account for concurrency issues, but that the load on the DB is further reduced. Other things to notice include no read-only replicas and no replication. Simple. Our web servers are the "replicas".

The Authentication Service

What makes it all work is the "Authentication Service" on the app server. This was always there in the synchronous solution. It is what used to field all the login requests from the web servers, and, of course, allowed them to register new users and all the regular stuff. The difference is that now it publishes a message when a new user is registered (or rather, is validated – all a part of the internal long-running workflow). It also allows subscribers to receive the list of all username/hashed-password pairs. It’s also quite likely that it would keep the same data in memory too.

The same message can be used to publish both single updates, and returning the full list when using NServiceBus. Let’s define the message:

And the message that the web server sends when it wants the full list:

And the code that the web server runs on startup looks like this (assuming constructor injection):

And the code that runs in the Authentication Service when the GetAllUsernamesMessage is received:

And the class on the web server that handles a UsernameInUseMessage when it arrives:

When the app server sends the full list, multiple objects of the type UsernameInUseMessage are sent in one physical message to that web server. However, the bus object that runs on the web server dispatches each of these logical messages one at a time to the message handler above.

So, when it comes time to actually authenticate a user, this the web page (or controller, if you’re doing MVC) would call:

When registering a new user, the web server would of course first check its cache, and then send a RegisterUserMessage that contained the username and the hashed password.

When the RegisterUserMessage arrives at the app server, a new long-running workflow is kicked off to handle the process:

That UsernameInUseMessage would eventually arrive at all the web servers subscribed.

Performance/Security Trade-Offs

When looking deeper into this workflow we realize that it could be implemented as two separate message handlers, and have the email address take the place of the workflow Id. The problem with this alternate, better performing solution has to do with security. By removing the dependence on the workflow Id, we’ve in essence stated that we’re willing to receive a UserValidatedMessage without having previously received the RegisterUserMessage.

Since the processing of the UserValidatedMessage is relatively expensive – writing to the DB and publishing messages to all web servers, a malicious user could perform a denial of service (DOS) attack without that many messages, thus flying under the radar of many detection systems. Spoofing a guid that would result in a valid workflow instance is much more difficult. Also, since workflow instances would probably be stored in some in-memory, replicated data grid the relative cost of a lookup would be quite small – small enough to avoid a DOS until a detection system picked it up.

Improved Bandwidth & Latency

The bottom line is that you’re getting much more out of your web tier this way, rather than hammering your data tier and having to scale it out much sooner. Also, notice that there is much less network traffic this way. Not such a big deal for usernames and passwords, but other scenarios built in the same way may need more data. Of course, the time it takes us to log a user in is much shorter as well since we don’t have to cross back and forth from the web server (in the DMZ) to the app server, to the db server.

The important thing to remember in this solution is doing pub/sub. NServiceBus merely provides a simple API for designing the system around pub/sub. And publishing is where you get the serious scalability. As you get more users, you’ll obviously need to get more web servers. The thing is that you probably won’t need more database servers just to handle logins. In this case, you also get lower latency per request since all work needed to be done can be done locally on the server that received the request.

ETags make it even better

For the more advanced crowd, I’ll wrap it up with the ETags. Since web servers do go down, and the cache will be cleared, what we can do is to write that cache to disk (probably in a background thread), and "tag" it with something that the server gave us along with the last UsernameInUseMessage we received. That way, when the web server comes back up, it can send that ETag along with its GetAllUsernamesMessage so that the app server will only send the changes that occurred since. This drives down network usage even more at the insignificant cost of some disk space on the web servers.

And in closing…

Even if you don’t have anything more than a single physical server today, and it acts as your web server and database server, this solution won’t slow things down. If anything, it’ll speed it up. Regardless, you’re much better prepared to scale out than before – no need to rip and replace your entire architecture just as you get 8 million Facebook users banging down your front door.

So, go check out NServiceBus and get the most out of your iron.