Particular Software Blog

With the upcoming version 6 of NServiceBus, we bid the IBus interface farewell and in its place, welcome a new wave of context-specific interfaces that are more intuitive and easier to test.

In the 1960s, Shigeo Shingo, a Japanese manufacturing consultant from Saga City, Japan, pioneered the concept of *poka-yoke*, a Japanese term that means "mistake-proofing." In a nutshell, *poka-yoke* involves saving time and cutting waste by reducing the possibility of defects. Although some number of mistakes will always occur, processes can be put in place to catch those mistakes before they turn into actual customer-facing defects. This is a model we've been trying to follow with NServiceBus -- not only with regards to our internal development processes, but also in our efforts to guide developers toward building message-driven systems. Through countless API design decisions over the years, we've been making it ever easier to use NServiceBus the right way and ever more difficult to use it wrongly. This way, developers naturally fall in to a pit of success.

Upon the return from my visit with the newly-discovered Ossian society, it happened that my ship capsized and I was marooned for a time on a tiny deserted island somewhere in the Caribbean Sea. One might think that the biggest problem with being marooned would be finding food for survival, but that was not the case on this island. Coconut and pineapple trees grew all over, and as luck would have it, I stumbled across a hidden cache of rations likely left behind by Spanish explorers or pirates. Among the supplies were dried and preserved meats and a collection of rum in glass bottles. The biggest problem when stranded, after finding food and shelter, is keeping one's own mind occupied. One day, I took a discarded rum bottle, inserted a note, and threw it into the sea.

Have you ever been pulled in to a software project and had to figure out how everything works? Often, your options are limited to either sifting through piles of documentation or diving into thousands of lines of code. Unfortunately, the documentation probably became obsolete as the software grew and evolved and, while the code is accurate by definition, it requires a lot of concentration to trace through and figure out how everything fits together. Ideally, what we really want is…

In the spring of that year, my travels brought me upon a previously undiscovered civilization. The people called themselves Ossians, and they lived in an isolated collection of villages in a remote part of South America. Being remote as they were, their level of technology was understandably primitive. But I was surprised by the locals' recent obsession with new forms of communication. It all started, they told me, when one of them discovered that by attaching a rope between two clay pots and stretching the rope taut, a voice uttered into one side could be heard on the other. (I neglected to tell them that even as a boy I had done this very thing with tin cans.)

We've been hard at work on the next major version of NServiceBus for a long time, and we're really excited to show it to you for the first time today! With major improvements in performance, top-to-bottom async support, and an even cleaner API, this version takes NServiceBus to a whole new level. And as of today, NServiceBus 6.0 is now available for public beta.

In 2004, Gregor Hohpe published his brilliant post "Starbucks Does Not Use Two-Phase Commit." When I read it, my time working at Starbucks during my college years suddenly became relevant. Over the years, I gradually realized there's even more that programmers can learn from the popular coffee chain. Although many people may want to build scalable software, it can be much harder than it first appears. As we work on individual tasks, we can fall into a trap, believing all things are equally important, need the same resources, and happen synchronously in a predefined order. It turns out they don't—at least not in scalable systems, and certainly not at Starbucks.

In the second keynote of NSBCon 2015, Ted Neward introduces the concept of Platform-Oriented Architecture (POA) as the logical successor to the currently used SOA/REST architectural approaches. POA is a developer-focused approach that has an established communication backplane, an entity definition, a built in agent model and a set of expectations around various execution topics. Ted also talks about the relationship between POA and operating systems, programming languages, and database engines.

One of the great things about NServiceBus is that it is so flexible. But with that flexibility comes the opportunity to do inadvisable things. What kind of things, you ask? At NSBCon 2015, Kijana Woodard shares the top mistakes (14 in all) that, in his opinion, developers routinely make when using NServiceBus. From row-based database operations instead of set-based ones to using callbacks as a permanent solution, Kijana covers a myriad of different issues that are inadvertently, or possibly intentionally, introduced to many NServiceBus projects. Watch Kijana's NSBCon 2015 presentation and learn how to avoid the pitfalls that many developers make.

Have you ever wondered how Particular Software makes NServiceBus? At NSBCon 2015, David Boike outlines the systems, tools, and methods used in Particular to manage a large number of Github repositories, along with the techniques that make sure all of their releases follow semantic versioning.

The Moore's Law party is over. We cannot make processors more powerful by making them faster. We have no choice but to embrace multiple processors, multi-core processors, and multiple threads in our code. But how do you do this? In his session at NSBCon 2015, Andrew Skotzko introduces us to message-based programming with the actor model and Akka.NET. Andrew shows how immutable messages, combined with the actor behaving as a unit of concurrency, make taking advantage of all those processors and cores much easier.

Not all NServiceBus implementations are on-premises. More and more people are releasing applications into the cloud. Jonathan Matheus speaks at NSBCon 2015 about the challenges and rewards of working in the cloud. As the official cloud hosting provider for RavenDB, RavenHQ uses NServiceBus to handle database provisioning and usage-based billing.

Udi Dahan opens NSBCon 2015 by summarizing the current state of the NServiceBus ecosystem. He outlines the foundation of our practices over the last year by comparing Particular Software to a duck on water: it looks calm on the surface, but below the waterline, it's paddling like hell. This ethos of continually working to stay ahead of the issues that NServiceBus users encounter sets the stage for a discussion on the current and future state of the platform. Udi explains the [retirement of ServiceMatrix](http://particular.net/blog/beyond-servicematrix), new features in ServiceInsight, and the future of NServiceBus with the coming release of v6.

Dealing with legacy systems is difficult. Complete rewrites take time. Components and functionality need to be migrated in stages while the remainder of the application stays operational. There's also the issue of integrating with third party systems and the impact that these can have on any system you're trying to improve. Jimmy Bogard deals with these types of legacy system problems on a daily basis. Most of his work is rescuing rewrite projects, some of which are the second or even third attempt to get rid of a legacy system. At NSBCon 2015, he talks about various integration patterns he uses in his projects and explains how NServiceBus helped him solve a few typical challenges.

In his presentation at NSBCon 2015, Gary Stonerock II talks about transforming a tightly-coupled synchronous process into an SOA/messaging-based solution using NServiceBus. Gary's team recently finished a rebuild of their clinical trial platform, and he shares with us some of the challenges, such as establishing stronger encapsulation and isolation, that they faced and how they overcame them.

Knowing which NServiceBus transport is best for your application is not easy. There are many factors involved in selecting a message transport; distributed transactions, legacy integration, cross-platform capabilities, and cloud deployments are a few that might be considered. At NSBCon 2015 Andreas Öhlund outlines the different transports that are available for NServiceBus. He covers the highlights and lowlights of each. Rather than telling you which transport is the right one, Andreas provides you with the tools to make that decision yourself, within the context of your project.

In our house, cleaning out the dishwasher is a shared chore. My son starts the unloading process by removing a dish or utensil from the dishwasher. If he can put it away, then he does. If the proper location for the dish is out of his reach, then he passes it to his mother. She then goes through the same process; put the dish away if she can, or pass it off to the next person in line, which is me. When I get handed a dish I will put it away and, since I'm 6'4" (1.92m) tall, I can reach all of our cupboard space which means that the process ends with me.

I can't draw to save my life, but I love comics, especially ones that capture the essence of what it's like to be a software developer. They capture the shared pain we all go through and temper it with humor. Luckily, I no longer work for large corporations, so it's easier now to read Dilbert and laugh without also wincing.

It all began so innocently. Through a friend, I found a job at a small, young, high-tech company. It was a perfect fit for work-life balance—work from home and flexible hours. This job was completely in English, which was a major plus for one who chose to move overseas and, 10 years later, still struggles with a new language! As a bonus, there was a growing human resources component to the job, tapping into my original career choice years ago before I stepped off the corporate ladder to be home with my kids.

When we originally started developing ServiceMatrix, our vision was to develop a tool that could help design distributed systems. One of our main goals was to enable architects to graphically design an immediately executable solution so they could quickly iterate on their designs. We also wanted to help developers who were new to NServiceBus to get started more quickly and avoid many common pitfalls with messaging. Unfortunately, even after years of effort, we just could not find the right balance between the "it just works" code generation experience and leaving developers enough control over how their solution was built. Although we were aware of many other companies who had struggled with this very issue, we also fell into that well-worn trap of thinking "this time will be different". We haven't given up though, and have started down a different path instead - one that doesn't rely on code generation and is more integrated with the rest of the platform.

Languages and frameworks evolve. We as developers have to learn new things constantly and unlearn already-learned knowledge. Speaking for myself, unlearning is the most difficult part of continuous learning. When I first came into contact with multi-threaded applications in .NET, I stumbled over the ThreadStatic attribute. I made a mental note that this attribute is particularly helpful when you have static fields that should not be shared between threads. At the time that the .NET Framework 4.0 was released, I discovered the ThreadLocal class and how it does a better job assigning default values to thread-specific data. So I unlearned the ThreadStaticAttribute, favoring instead ThreadLocal. Fast forward to some time later, when I started digging into async/await. I fell victim to a belief that thread-specific data still worked. So I was wrong, again, and had to unlearn, again! If only I had known about AsyncLocal earlier. Let's learn and unlearn together!

Have you ever wondered what it might feel like to read product documentation without the benefit of being an expert in the product? It’s a frustrating exercise, but it's usually something I can work around once I figure out the gap between what I know and what the reader knows. It’s never been brought home so completely as it was the other day. I had a hankering for some home-baked cookies and, perhaps stupidly, I figured I’d cook them myself. After all, how hard can it be to follow a bunch of simple instructions to bake some cookies, right?

It’s safe to say I knew next to nothing about the challenges of a software development company when I joined the Operations department at Particular Software two years ago. My background is in Human Resources, and that part of me was intrigued by the little I knew about the company – just past the start-up stage, 100% dispersed, flexible hours, growing fast. As a passionate planner, it rocked my boat a bit that there was no master plan for the company. Three things were clear, though. One, I was part of a team passionate about our culture, organization, and products. Two, we wanted to build tools that developers were equally passionate about. And three, we wanted to build the kind of company where we all wanted to work.

I recently started as a software engineer with Particular. Being new means I've had plenty of opportunities to realize what I know and what I don't know. With every new role, project, or technology, I've always found there is a lot to learn. I look at the team around me and see their good qualities, how they have it all together, and I realize how far I have to grow. They are experts, and I am supposed to know what I'm doing as well. You respect the knowledge of your peers, and you want them to respect yours, too. Admitting that you don't know something is scary. Will you lose a bit of that respect? What if you admit not knowing something that was obvious to everyone else?

If you follow industry news, you have probably heard about microservices. They are everywhere. More and more companies are exploring this architectural style, sharing their successes and their failures. The landscape is changing and advancing rapidly. Much has been learned recently from these real-life implementations. However, one of the most frequent and controversial questions remains the same: so how big should each microservice be?