Book Image

Learning NServiceBus - Second Edition

By : David Boike
Book Image

Learning NServiceBus - Second Edition

By: David Boike

Overview of this book

Table of Contents (18 chapters)
Learning NServiceBus Second Edition
About the Author
About the Reviewers


Unlike many people who write a foreword for a book, I have myself not actually written a book yet, so I am probably going about this the wrong way. Also, of all the books that I have read, I have almost never read the foreword, which makes me wonder who is actually reading this.

That being said, I think that 10 years of blogging has actually prepared me very well to write this foreword, and it will end up being roughly as long as my regular blog posts.

In any case, I am extremely happy to see how well the first edition of this Learning NServiceBus book has done, and when David asked me to write the foreword for this second edition, I was more than willing to oblige.

Now that you've picked up this book, I think it's fair to assume that you have heard something about NServiceBus, maybe even downloaded it, played with it, or used it on a project or two. What you might not know is the story of how it all began and how we ended up where we are today—seeing the second edition of Learning NServiceBus being published.

Early influences

Almost 15 years ago, I was working as a developer on a gigantic command and control system developed in a language called Ada. This is what Wikipedia has to say about Ada:

"[Ada] has built-in language support for explicit concurrency, offering tasks, synchronous message passing, protected objects, and non-determinism."

These were very important attributes for a system that needed to be super reliable, highly performant, and very scalable. Little did I realize at that time how profound an effect this relatively unknown programming language would have on the rest of my career.

In my next company, a software development firm—the kind that does turnkey projects for its customers—I continued my focus on command and control systems, this time using the fairly new .NET platform from Microsoft. The thing was that many of the abilities that I'd come to rely on in Ada were (to me) curiously absent from .NET.

Like any good craftsman who has gotten used to a certain tool, I started looking around for a replacement, and when I couldn't find one, I went and made it myself.

Starting with MSMQ

Although the main message from Microsoft at the time was all about XML Web Services and .NET Remoting, I found that there was support for a message passing model in .NET that was actually built on a piece of infrastructure that was considerably older (originally built in the NT 3.5.1 days, but released with NT 4.0 in 1997). At that time, MSMQ had made it to version 3.0 which, later on, I learned was the magic number when it came to stability of software built by Microsoft.

Still, I found the System Messaging API to be a little too close to the metal for me to feel comfortable using it directly from my application logic, so I created a wrapper library, which gave me some much needed abstraction.

As I moved from one project to the next, I found this little library to be more and more useful and kept on extending and refining it. The developers in my teams seemed to like working with it as well.

After the third or fourth project, I decided to approach the company's management, suggesting that we should consider turning this infrastructure into a product. Seeing how useful it was to us on our projects, I figured that it was a no-brainer.

It turned out that this company had gone down the productization path in the past and had gotten badly burned in the process. As a result, they were very hesitant to make the same mistake again. Realizing that it wasn't going to happen, I managed to get permission to release the infrastructure to the world as an open source project, but only after legal confirmation that there would be no support or other liabilities to the company.

Thus, in 2007, NServiceBus was born.

This also happened to be the time when I started transitioning into my own private consulting practice.

What open source meant in those days

As I continued to use NServiceBus in my work projects, I kept tweaking and expanding it. Version numbers didn't mean a whole lot, and through 2008, the version progressed rapidly from 1.6.1 to a release candidate of 1.9. If it worked on my project, I considered it worthy to ship.

Documentation was practically nonexistent and developers leaned pretty heavily on samples to figure out what the software did, asking questions on the discussion group when they ran into cryptic error messages (of which there were many).

In 2008, the 5-day format of my Advanced Distributed Systems Design course was launched, which was an extension of the 2-day workshop on the same topics I had been teaching since 2006. This course was based on many of the learnings from my old Ada days and continues to serve as the architectural underpinning of much of NServiceBus to this day.

April 2009 brought some stability with the final release of version 1.9 but came with a marked increase in the amount of consulting and training I was doing. This was great for me as I could finally afford to turn down work in order to continue the development of NServiceBus. This worked out great and in March 2010, the much-heralded NServiceBus 2.0 was finally released.

Clouds on the horizon

By almost every measure, things were going great. More companies were adopting NServiceBus and bringing me in for consulting. The Advanced Distributed Systems Design course was getting quite popular, and for a while, I was teaching it almost once a month in a different country around the world. Unfortunately, almost 6 months had gone by without any meaningful development on the code base.

Then it hit me that if another year or two would pass by in this manner, NServiceBus would start to get stale and the companies that had used it in their systems would eventually have to replace it with something else (costing them quite a lot of time and money).

I had lived through this story several times as a consumer of open source projects. As long as the project wasn't too intertwined in our system, it wasn't too painful to remove it. The thing was that NServiceBus was a fairly large framework that supported broad cross-sections of both client-side and server-side logic, so there would be no simple way to replace it.

I tried to figure out how I could guarantee that the development of the code base would stay a priority, yet as long as my primary source of revenue was services (consulting and training), I couldn't see how it would work. The only solution seemed to be to start charging money for NServiceBus licenses. Although larger companies were able to keep an open source core and sell other products around it, I hadn't seen or heard of any one-person operations that had been able to bootstrap their way into that.

I had no idea whether this would work, and whether the open source community that had supported me all this time would accept it or turn their backs on me, but I felt that it needed to be done. Unless there was revenue coming in directly from the features of the product, it wouldn't have a future.

Therefore, in late 2010, I founded the NServiceBus company and steeled myself for the worst.

Unexpected success

Seeing the overwhelmingly positive responses from the community was quite a surprise. Sure, there were those that grumbled, but only a handful ultimately decided to switch to something else.

I had made it—living the dream!

However, lest I paint an overly rosy picture, I knew nothing about running a product company. Pricing was harder than I ever imagined it would be. The legal factor was a "crazy-complex" where, even after the lawyers explained to me all about things such as indemnification, they told me that it was ultimately my decision whether to accept the client's terms or not.

Most importantly though, I felt that I had secured the future of NServiceBus. As long as there was money to be made from it, even if something happened to me, one of the other contributors to the project could afford to take it over.

Fast-forward to today

So much has happened since those early days of 2011 that it could probably fill its own book, and maybe one of these days, I'll put the proverbial pen to paper and make it happen. Anyway, here are the highlights:

  • March 2012: NServiceBus 3.0 released. This includes official Azure support for the first time.

  • July 2013: NServiceBus 4.0 released. This includes modeling and debugging tools.

  • 2013: The company begins to rebrand itself as Particular Software.

  • August 2013: The first edition of the Learning NServiceBus book comes out.

  • November 2013: Monitoring tools released for NServiceBus.

  • April 2014: The first release of the integrated Particular Service Platform.

  • September 2014: NServiceBus 5.0 released, no longer depending on distributed transactions.

Also, I've got to tell you, the quality of each version has gone up dramatically over time. The level of testing that goes into each release is impressive—looping through every permutation of containers, persistence, transport, and even versions of supported operating systems and databases.

Back to David, and this book

When David wrote the first edition of this Learning NServiceBus book, it was something of a defining moment for NServiceBus—there was finally a book. The technology industry is awash in books about almost every piece of software out there, but for most of the time, NServiceBus was absent. Decision makers took us more seriously when we'd bring physical books with us for their teams.

Books matter!

With this latest edition, David goes beyond just covering the changes that happened in NServiceBus version 5.0, and goes even deeper into the reasoning behind those changes and why you'd want to use which features and when.

As one of the most prominent members of the NServiceBus community, David has interacted with the NServiceBus development team on a regular basis, given valuable feedback on our API, and debated with us on our future technology roadmap.

You're in for a treat.

Udi Dahan

Founder and CEO, Particular Software