WatchMeCode with Derick Bailey & Udi Dahan

🔗Transcription

00:22 Derick Bailey

So I'm here today with Udi Dahan, CEO of Particular Software and world renowned speaker and blogger. And far more than that, also the creator of NServiceBus, a Service Bus, obviously for the .NET platform, which allows a lot of different architectural patterns to be baked into your software quickly, and easily managing your workflow through your messaging system, whatever that messaging system back in maybe. Udi is a wonderful pleasure to have you here. I really appreciate you taking the time to be here. So thank you very much for doing this.

00:57 Udi Dahan

Well, thank you for having me Derick. It's my pleasure.

01:01 Derick Bailey

So today I would like to discuss really the particulars of Service Buses. What those really are, what a Service Bus is, where the idea came from and how a Service Bus can really help us with messaging software, messaging patterns and help us be more productive in these systems that we are creating across multiple physical machines and other boundaries. But before we get into that, I'd like to take a step back and ask you a few questions about how you got started with messaging software. I recently interviewed Jimmy Bogart, who said that you've been doing messaging software since possibly the early 2000s or late 1990s. So how did you get into messaging software back then? And what were you using back then?

01:51 Udi Dahan

So the first use I had was a very large distributed system that was built for the Israelian Air Force.

02:03 Derick Bailey

Oh, wow.

02:04 Udi Dahan

It was built in a very old language called Ada.

02:10 Derick Bailey

Ada. Wow. Named after, Ada Lovelace of course.

02:14 Udi Dahan

That's right. And it was the kind of system where, when they say mission critical, it actually means the literal term.

02:24 Derick Bailey

Mission critical.

02:26 Udi Dahan

It gets bandied about fairly frequently in commercial types of settings. But there it really meant it. And the whole system was built on this paradigm of mailboxes. Everything would be done by putting a message in a mailbox. And that was the first, really large scale project that I was on. And I was just one developer out of a team of, I don't know how many hundreds even.

02:58 Derick Bailey

Wow.

02:59 Udi Dahan

It was just kind of like, "This is the way that we do it." I'm like, "Okay." Sure. What do I know? So kind of went with the flow the language wasn't that great, but the just that style of programming, for me doing the actual development work, it was fairly simple in terms of the amount of complexity that I needed to keep in my head at any time, because each bit was almost always triggered by a message coming in off of one mailbox. You do a little bit of work and then you put messages at other mailboxes. And that was kind of how everything was built. And they had this really crappy interface, definition, language thing. Wasn't that pleasurable to use, ultimately everything needed to do to be coded down to really tight binary format.

03:51 Udi Dahan

But this concept of having a strict message contracts and contract definition and evolution and keeping things to coupled was right there from the very beginning. And I got to see that system go live and see it working in let's call it really difficult types of production environments. It's not the kind of thing where everything's just running in a single data center. But being able to deal with connectivity issues and seeing the system recover automatically from that. So that was my earliest experience of large scale systems development that just happened to have this concept of messaging in there.

04:38 Udi Dahan

And I somewhat took it for granted. I mean, this is how you do large scale systems development. And then when I went out into the commercial world and I saw that that wasn't the case, I was like, "Wait a minute. Why aren't you doing this?" I mean, you're using much more advanced programming languages, what I had used. But why don't you have this thing? Why is everybody doing our RPC type of communication, the synchronous request response because that was a big no-no. I said, you don't even think about doing that. Don't try to do that on top of the mailboxes because it's just going to cause the system all sorts of grief.

05:17 Derick Bailey

Yeah. There's going to be connectivity failures and parts of the system going down. You're not going to have guarantee of everything being there, so I can definitely see how the RPC world is kind of counter to the idea of the mailboxes that you had previously worked with.

05:34 Udi Dahan

Right. So that was the start of it for me. And then moving into .net in doing projects there, I was like, oh, okay. I looked for the thing that was closest to the message box and I said, okay, there's this MSMQ thing. Which MSMQ was not a great technology.

05:59 Derick Bailey

It work.

06:00 Udi Dahan

Well, a round the time that .net was released 2001, 2002. MSMQ was still not that great. It only got better at around 2003. When I think it was SP1 of windows XP or something like that on the client, and then you've got windows 2003 server, then it kind of got quite a bit more robust. But at the time I was using a lot of TIBCO rendezvous, and rendezvous was an absolutely amazing, first of all, very low latency, very high performance messaging platform-

06:32 Derick Bailey

Very nice.

06:32 Udi Dahan

... the .net APIs left something to be desired, but yeah, that's how I got started in it. It was just that this sort of early experience that this thing really works under the most strenuous of circumstances. And all of the other available technologies at the time that the domestic majority were communicating over HTTP or TCP, whether you're talking about XML web services or .net remoting or Java RMI, or all of those various equivalents. The synchronous request, response style, every time I was brought into a project that was doing that, I would say, "But wait a minute, how's the system going to work when that process dies?" And people kind of looked at me funny-

07:22 Derick Bailey

What do you mean?

07:23 Udi Dahan

... even asking that question, why would that ever happen? And I'm like, "Just kill the process and you see how the rest of the system hangs" And like, "Oh yeah, that's not our problem." And it was just a weird concept for me. How is that not your problem, but at the time there wasn't this sort of big dev ops type movement. Developers just focused on writing the code and works on my machine was actually a reasonable statement to be made.

07:52 Derick Bailey

I remember those days.

07:52 Udi Dahan

When checking in code or throwing it over to QA. So I wasn't coming from that background, but that's kind of how I got started and why I felt like something needed to be done to lower the barrier of entry for other people.

08:11 Derick Bailey

So was that the kind of the Genesis of NServiceBus right there, was that desire to lower the barrier of entry for people to do message oriented systems like that?

08:23 Udi Dahan

Well, so at the time was working at a consulting company and the people that I was trying to lower the barrier for were the other developers on the team. I didn't think that they needed to be experts in TIBCO or MSMQ or anything else like that, just wanted to have a nice, simple abstraction on top of that underlying technology so that they could publish events and send commands and handle messages coming in. And then most of the yucky low level concerns about managing and all sorts of options on the message and a time to live. And there's 1,000,001 little options down there, that the average developer that wants to write some business logic shouldn't have to deal with. So it was just kind of taking a lot of the abilities that were in the libraries and just creating an abstraction layer on top of that.

09:16 Udi Dahan

That's how it got started. And after one project to the next, to the next, that abstraction layer kind of got bigger and more fully featured to the point where I was like, okay, it's a thing in its own right. At the time I didn't really think that anybody would need to have like a standardized wrapper around a queuing system, but after a number of years of working with dozens of developers on various projects just saw that there's actually a whole bunch of complexity. And there's a million ways of setting things up that, let's say, 99% of the business systems that are out there, they should all work a certain way. So yes, for the 1% that really needs to do something special in every single case find they can drop down to the lowest layer, but really everybody else should just use a very strong abstraction around the whole concept of a queuing system.

10:20 Derick Bailey

Yeah. And I think my own personal experience is very much mirrors what you just said. I started with WebSphere MQ and my own abstraction layer on top of that in .net back in 2008, 2009 timeframe. And I had looked at NServiceBus as an abstraction layer to use. I'd also looked at MassTransit at the time and honestly said to myself, oh, I don't need these big layers of abstraction. And these extra systems, I'm just going go straight to the message queue. Well, a year and later I had my own poorly specified half implemented, terrible version of a Service Bus and realized when it was too late, I really should have just stuck within service bus because I've baked half of the patterns that you had into my abstraction. And it is very poorly specified and significantly less flexible at this point. So I-

11:21 Udi Dahan

That's the thing nobody realizes that they need one. I mean, how hard could it be? I think that-

11:31 Derick Bailey

Exactly. It's just a message, I'm just putting it here and then I'm getting it. And how hard could it be?

11:37 Udi Dahan

Right. And WebSphere or TIBCO, or those types of technologies that have a great deal of power. There is a great deal of complexity down there. And the answer to how hard can it be is pretty damn hard.

11:51 Derick Bailey

Pretty damn hard. That's true. Especially, we spent tens of thousands of dollars on training for WebSphere, and we still pulled our hair out, constantly fighting that, but we made it work. And it was a similar situation to where you started. I was working on a system for the US military. Their ground-based maintenance system. So it certainly wasn't mission critical like yours was, but it was still loss of connectivity, systems going down. And that's where we got the idea, oh, let's use the messaging system so that we can reconnect things and have messages pushed across when the connection is available. And ultimately it did work out really well for that project. We were quite happy with it, and that was my first foray into messaging. So we've mentioned Service Buses, a number of times here NServiceBus in particular. And the half-baked one that I had built back in those days, but I want to step back again and ask what is a Service Bus what is the real value that the Service Bus is going to add other than just being an abstraction layer on top of your messaging system?

13:01 Udi Dahan

Right. So the first issue is that the term Service Bus itself quite overloaded when service-oriented architecture started to take off and around 2005, 2006 that's when a lot of the vendors that your IBM, your web methods, your Oracles of the word that they had, preexisting message broker technology. And that they'd built for the most part in the early '90s and kind of continued evolving it since then, when they industry said, "Oh, no, we don't want a message brokers anymore." Brokers are passe. They're out. We want this new service oriented Busey thing. That'll be distributed and scalable and all these nice things. Then the big vendors kind of turned around, repackaged a lot of their existing technologies. And to a large extent, they web service sized that said you don't want message brokers fine.

14:14 Udi Dahan

They now speak wisdom. They now support all sorts of other specs from the WS-Star. The security, the transaction, the addresses, the reliability. And of course, you have orchestration and content based routing and all of these other kind of feature sets. Let's call it that's the Enterprise Service Bus. That's where the enterprisee bit is coming in. So what you'll invariably see with a lot of Enterprise Service Bus technologies is that there's a very strong focus on web services and enabling RPC synchronous request response type work for the average .net developer the technology that would be most similar to this would be like a BizTalk. So kind of a big monolith in the middle that you kind of drag and drop all sorts of orchestrations and transformations inside of, and everything connects to it. And it connects to everything else. That's kind of that's the one category.

15:23 Derick Bailey

The big Enterprise Service Bus.

15:25 Udi Dahan

Right. Now where NServiceBus and MassTransit, and a lot of the other offshoots came from was actually the... no, we don't actually like web services in this request response. We were not trying to support that or to make that easy or to promote that as a common integration philosophy, we want to build the heart of our system around the different set of concepts. So I'd say to some extent it was very microservice oriented because the idea around and NServiceBus was how do I build a system, a single system on top of this in a loosely coupled way so that there are lots of separate parts rather than the Enterprise Service Bus perspective of how do I integrate a bunch of distinct, and in many cases already existing systems that are already out there.

16:26 Udi Dahan

So that's what I'd say the NServiceBus and the modern incarnations of microservice type technology are coming from, it's the perspective of how do we build a system the right way as opposed to, how do we integrate a bunch of existing systems.

16:45 Derick Bailey

Existing systems, right.

16:45 Udi Dahan

So I'd say that's the number one difference. And it's very confusing because the terms are just so similar.

16:55 Derick Bailey

Add that little enterprise in front of Service Bus, and suddenly you have a completely different ball game that you're talking about.

17:03 Udi Dahan

Right. So back to your question from before, maybe you can remind me as well as our listeners, what the original question was.

17:16 Derick Bailey

So I wanted to get at what the heart of a Service Bus is like, NServiceBus or MassTransit, or even my own more recent working with my own NodeJs Library that I called Rabbit I'm kind of heading down the path of a Service Bus with some changes I made recently. And I want our listeners to really get a sense of the value and the features and capabilities that a Service Bus should provide on top of messaging system, in whatever language they happen to be using.

17:53 Udi Dahan

Right. So I'd say that there are a couple of levels to a Service Bus. There's the first one, which is a let's call it common messaging best practices type of area, where, for example, let's say you want to do a request response messaging pattern. Then in order for that to work, because it's not synchronous necessarily, you could have a single client interacting with the server along three conversations in parallel because everything's, async by default. So then you need to wait for the client to know which response is associated with which requests that they sent, because everything's happening in parallel. So then you have really simple things like making sure that every response message includes a header on it with a correlation ID, which is the message ID of the original request that came out. And to probably provide a higher level API at the client side for being able to implement like a callback style model. So I'd say that that's sort of the first layer of stuff that you'll see in almost every Service Bus is just kind of making the messaging patterns easier to consume by a developer.

19:18 Derick Bailey

So in the case of the wascally library, which is my preferred abstraction on top of Rabbit MQ, there is a request method, and you get a response directly from that. And it uses a combination of correlation ID behind the scenes. Nobody, other than the wascally library ever knows about this correlation ID, but it allows you to very easily just say, oh, I need to request this information. And it's a message by the way. And then something else on the other end sends a reply back through a Rabbit MQ, private Q or exclusive Q. So in the case of Rabbit MQ, a correlation ID is used slightly differently than in other queuing systems, but it's still there. And we get that reply coming back. And then wascally that library manages understanding which response goes with which request so that the developer doesn't have to deal with that.

20:16 Udi Dahan

Right. And you bring up another point, which is very important. It's also the management of the topology. So which cues are we going to be using for what to make sure that messages go, where they need to go, that they get consumed the right number of times. So if it's a request or a response, it should really be only consumed once. However, if it's an event, then we fully expect it to be consumed multiple times. And there are different ways of setting that up, whether you're using Rabbit MQ or MSMQ, or as your Service Bus, or whatever type of queuing technology. Just making sure that the higher level expectations of a developer, when they're saying, I want to publish to an event, or I want to subscribe to an event that all of that routing is just taken care of behind the scenes, with all of the necessary headers and metadata. So that they can focus on the business problem and then this lower level. We'll just make sure that it's kind of make it so library. Can I just have it work? That's what it's there for.

21:21 Derick Bailey

Make it so number one.

21:23 Udi Dahan

Exactly. So that's the first bit. The second bit is when you start getting into let's call it more production, readiness types of scenarios, where you start dealing with things like that the intersection between the business logic, that's processing a message and the queuing system together. So let's say that as a part of processing a message, you try to talk to a database and you get, I don't known, exception that's thrown, like connection refused by the remote host. The database connection pool is maxed out or something. Now, again, you as a developer can write the code yourself to say, "Oh, okay, I got that. I'm going to catch that exception. I'm going to wait a couple of milliseconds, and then I'm going to retry connecting to the database and do that again." And in essence, you can roll your own retry type logic, but then you find that you end up creating your own type of infrastructure library for business message processing retrying these stuff. Between-

22:35 Derick Bailey

I'll just add a time out, set time out in my NodeJS code here, and I'll just retry it again. And then you end up with memory exploding because you have thousands of messages that are in these set timeouts and all kinds of potential problems there.

22:51 Udi Dahan

So that's the next bit of kind of implementing that type of exception, handling retry logic dealing with poison messages. So let's say a message couldn't be deserialized then moving that somewhere. So there's a whole other set of taking a message driven system and making it fit for production. That usually a developer, when they're starting a project they you don't actually see the need for it, once they deploy the system to production and start dealing with these situations, especially if you're talking about deploying version two, version three of the system where you start having these types of version incompatibilities that you start having to solve these problems, then you're like, okay, so where I'm going to write the exceptions to, and then how do I centralize them? Because I have all of these distributed and you create a whole other set of capabilities to get your message driven system ready.

23:54 Udi Dahan

So you'll see those types of things in a Service Bus technology. So the just handling the exceptions and the rolling back and the retrying and the timeouts and the poison message handling and preferably centralizing all of that information and creating some sort of UI that allows an administrator to be able to see that there is a problem in a system and then to send a message to be processed again, once it's been resolved, there's a whole other set of functionality that, again, people don't know that they need until they start building. And then they realize, oh my God, this rabbit hole goes really, really, deep.

24:38 Derick Bailey

Really deep. Exactly what I ran into in that first project. Back in 2008, 2009, I started running into message size limitations. We were dealing with XML, which is a very verbose format. And we were running into, it was 100 K limit, I think was the default message size for WebSphere MQ at the time, it was either 100 K or one meg, whatever it was, we were sending ridiculously large messages, several megs in size. So we had to go in and essentially build middleware into our stack that allowed us to take a single message, split it apart into multiple pieces that were numbered so that we knew how many total messages there were and which message number this was, send them all across the system, wait for all of the messages to be collected on the other side, repeat it together, and then be able to process it by the actual business logic.

25:43 Derick Bailey

So it's those kinds of rabbit holes that a Service Bus will really help somebody solve. And I ran into a similar problem where I needed some middleware recently and in my project where I have messages that were getting out of order, and that was showing up in the user interface, because there was a status of these three things in the user interface that said they were still running. When in reality, they had already completed and things that depended on those had already kicked off. So the user interface was out of sync with the actual in-memory representation. The messages were out of order. The older messages were getting applied to the database, save and showing things incorrectly. So again, I built some middleware into my Rabbits library that allowed me to just reject old messages.

26:35 Derick Bailey

I keep track of the sequence of messages being sent. If it's an old message, you're canned. If it's a future message beyond I currently am, I don't care. I'm just going to apply that future message because it contains the full document in my case. So there's so many different rabbit holes that you can go down, so many different problems that you can run into exception handling, especially retrying messages. There's a million different things that you need to keep track of that a Service Bus, a proper good implementation will hopefully help you be able to not have to deal with those things.

27:14 Derick Bailey

Where do we go beyond a Service Bus though? Is that kind of the end game for the business layer abstractions or is there something that we do beyond NServiceBus or MassTransit or whatever it is that we're using?

27:30 Udi Dahan

So there are certain let's call it opinions in NServiceBus that we enforce that move it beyond the element of being let's call it technological to being architectural. So one of the opinions in there is that only a given logical end point can publish a given event type. For each event type, you could have one logical publisher and it can scale out that publisher to multiple physical nodes, but you only get one of them. And when people run into that, the first time, they kind of say, but wait, how exactly am I going to make that work for me because what I wanted to do is I wanted to publish a create customer command, and then I'll have this auditing listener. That's going to listen to all of the messages coming through. And that's how I'll do my audit like, oh, okay.

28:42 Udi Dahan

So you want auditing, the right way to do auditing is actually differently. So auditing is something that should be done from the perspective of when an end point processes a message. And only after that message processing was successful, do you want to actually audit that? So you don't actually want to split up a command to multiple queues because the queuing system and all of the previous layers that we talked about will guarantee that that message won't be lost. So it's always going to be somewhere and only after it's done processing, then we'll have another piece of infrastructure. That's going to go audit that. And if you want to extend the auditing functionality, well, there's a different part of the stack that you extend. But you can't go publishing commands. For example, it'll say no, that just won't let you do that. And if you try to have multiple publishers of the same event, because you're saying, I want to publish an audit here, and I want to publish an audit there.

29:46 Udi Dahan

I say, no, wait a minute, you're architecture. You're mixing up logical and physical concerns. And I'd say that that's probably one of the most common problems that people run into when going to design a message driven system is they don't realize that there are actually two levels of work, that you need to be thinking about the logical and the physical. And what the Service Bus, or what we try to do in NServiceBus is we try to make it so that you're modeling at the logical level, according to certain rules. And when you do that, that will guide your solution to fulfilling things like the single responsibility principle, the right way. And thus, you will have highly cohesive, loosely, coupled parts of your system. That if you change something over here, it's not going to end up breaking things all over the place.

30:41 Udi Dahan

So I'd say that's the part where we start getting into an architecture really significant piece of technology, because it's not just a library, it's not just a framework that says, okay, if this is you have to conform to these APIs, it goes a level above that and says, you can't just do whatever you want with your message contracts. We're going to guide you a certain way. And if you follow that, it may not be apparent right from the very beginning. But if you follow that things will work out much better for you. Trust us.

31:17 Udi Dahan

And invariably, we get this kind of pushback where people saying, "No, but really I want to do it this way." You say, "Look, if you want to do it that way, you can drop down a layer and you use the lower level APIs that we have of a messaged receiver in a thing like that, but we don't recommend that you do work at this level, give it a try." And invariably, what people find out is their solution is much better designed for.

31:46 Derick Bailey

I had similar experiences when using NHibernate, the object, relational mapper, I fought NHibernate for a very long time. And I finally gave in on one particular project and said, fine, I'm just going to do it the way NHibernate wants me to do it because I'm tired of fighting it. And at the end of that project, I looked at it and said, "Wow, that was easy." So I can see how the same thing could happen with NServiceBus or other Service Bus implementations, where you have, especially with, with only being able to publish an event from one place. I could see that sounds really painful to me offhand. Like, no, of course I wanted to be able to publish this from multiple places. Because I've got all these things going on. I want to audit from here. I want to do this from there.

32:39 Derick Bailey

But like you said, once you have multiple logical places in your system that do that. Well, now you have multiple logical places in your system that have to be changed every time, the way this works changes. And one of the ideas, especially with the single responsibility principle is to limit the number of reasons to change something. So you don't want to have to change five different chunks of code because one logical concept changed. You want to change that one chunk of code because that one logical concept changed. So I can see a lot of potential benefit in doing that, for sure.

33:23 Udi Dahan

And there are a whole bunch of little things like that. And NServiceBus that you don't realize how important they are until you've built a system that way after doing it the old way. And that's where I think that's what makes a Service Bus, a Service Bus, as opposed to just an abstraction layer on top of the queuing system, it's taking more of that architectural guidance and saying we're not going to let you do that by default. I mean, you really want to do that, you're going to have to drop down a layer and lose a whole bunch of capabilities. But if you do it this way it's really going work well. And I've got to say I've been doing this NServiceBus thing for probably about eight or nine years now. And that model has held up in just so many different business domains, and types of companies and whatever you want to call it that there is a way to break down your architecture according to those rules. And that when you do that you'll kind of get at this light bulb moment and say that is so much better.

34:46 Derick Bailey

Yes. Very much so. So I want to shift gears for a moment, I guess a few minutes ago, you mentioned systems on top of the Service Bus that would allow you to monitor and manage the health of the overall system that you're building is this where your service platform comes into play from particular software?

35:14 Udi Dahan

Yeah.

35:14 Derick Bailey

So what does that really entail? What is this service platform that you offer?

35:19 Udi Dahan

Well, without getting into too much detail, there are very basic things that you start to realize that you need around monitoring when building a message queue driven system in a regular type of RPC system the Ops people are watching log files to see if exceptions are being logged. Because that's an indication that there's something wrong with the system. Now in a message driven system, because it has these kinds of retries built in. It could be that there's an exception that occurs, but the system just able to recover from that automatically. So then that influences not only how you log things, but also how the people will go about monitoring it.

36:05 Derick Bailey

Right. Because that could mask a problem.

36:08 Udi Dahan

Well, part of it is it masking a problem or is it recovering from a transient situation in which the ops person doesn't I actually need to do anything. So the connection pool was mask out, the retry logic kicked in, and then, 50 milliseconds later, it all sorted itself out, do nothing, no reason to start sounding the bells and saying, "Hey, come over here, look at this."

36:36 Derick Bailey

Don't need to call the on-call person at 2:00 AM for that.

36:38 Udi Dahan

Exactly. So those types of things drive a very different style of monitoring of a system. And it also leads to things like considering service level agreements. So how long should a message remain in a queue and for that to be okay, and that really starts to fit into the business side of things how long should it be as a developer what do I know? The queuing system says for as long as I can keep it around forever, and it's just using a megabyte of storage on disk, that's practically free. But then how long should we wait before we notify somebody about this? The next level above that is when you move from single message to message chains or message flows, saying if something failed, I'd really like to be able to see the chain of messages that caused that message.

37:36 Derick Bailey

Wow.

37:36 Udi Dahan

So it could be that this event was published as a result of a command, which was sent as a result of another event, which was the result of, and you have this kind of really long flow.

37:47 Derick Bailey

I would really like to be able to see that in my current system.

37:51 Udi Dahan

Now in an RPC system, it's really simple because everything is synchronous and blocking. And if something fails, you get this big gigantic call stack that shows you everything, in a message driven system, because everything's decoupled, you lose that. So what we do, first of all, NServiceBus, we piggyback additional headers that every time a message is admitted, we hold onto the conversation ID of the original message that comes out. So in our audit, we're able to piece together the causation flow, message A cause, message B cause, message C cause, message D and then we have a UI that allows you to visualize that and show you how happened if things failed at all. The full message data that was in there, what message flowed to which endpoint. So it actually generates like sequence diagrams for you. It's all those things you need when debugging a message driven system.

38:52 Udi Dahan

That, again, you don't know that you need until you're stuck hearing through log files of millions of messages. So those are the other thing that are the clear, most easily visible things that you're going to need when building a message driven system. And of course, there are others, but it's kind of where did the service platform in particular come from? It's just all of these things that people running and debugging and troubleshooting message driven systems, and versioning them run into over the lifetime of their projects and of their systems. And I said, yeah, that's a problem we should solve there. That's another problem we should solve. And just kind of doing more and more, and more and more so arguably, because we've been around the longest, we've been exposed to the most of these kinds of problems, and kind of had the longest time to actually go around and fix those types of things.

39:55 Derick Bailey

The most experience with the number of problems that people are going to run into, to be able to solve these problems that people are going to run into. So is that service platform a commercially available product or is that part of the open source?

40:12 Udi Dahan

So in terms of licensing everything is dual license. So the code is open on, GitHub. Everybody can come look at it and learn from it. And of course, contribute patches that's one of the things that clients appreciate, whereas open sources that if I have a problem, I don't have to wait for the vendor to release something.

40:36 Derick Bailey

Yeah, definitely.

40:38 Udi Dahan

So being able to patch the code directly is a huge benefit. But it is licensed meaning that there will be patches and there will be maintenance and there will be 24/7 support. And really you do want all of those types of things because you don't want to be in a situation where you're being woken up at 2:00 AM and then you have to spelunk through the NServiceBus best code base to figure out what's going on, much better to just pick up the phone and say, "I have a problem." We're like, "Oh right. There's a patch release out. Just go use that one." So having that there is very useful. And I'd say for the vast majority of people and companies their time and peace of mind is worth so much more than whatever licensing cost is there.

41:41 Derick Bailey

Absolutely.

41:41 Udi Dahan

It's really attractively licensed compared to everything else. Of course, there are free things like MassTransit, but you can't call up Chris at 3:00 AM and expect him to help.

41:52 Derick Bailey

No, I don't think he would like that very much. I know I wouldn't like that. So if our audience would like to go find more information about Service Buses in general, about NServiceBus, and about your service platform, what are the best resources to learn about these things?

42:12 Udi Dahan

I'd tell you about messaging patterns in general, the enterprise integration patterns, website, and book that documents a lot of them. So a great deal of information there. So if you decide to go down the path of how hard could it be, just do this you'll find that book is just an invaluable reference for all of the things that you need to build. And some sample code on how to build that. So I think that's great. In terms of, the higher level architectural guidance about how to build these types of systems, I've been blogging for about that kind of stuff. So check out my blog, udidahan.com. I guess, we'll have a link in the show notes.

43:06 Derick Bailey

Yes we will, definitely.

43:08 Udi Dahan

And about NServiceBus and the service platform that's particular .net. So very easy to find.

43:18 Derick Bailey

That's wonderful. So I do have one last question for you before we wrap up here. If you could say one thing, just one thing as the most important points or message in this case for somebody that's getting into message oriented software development and architecture, what would that one piece of advice be?

43:45 Udi Dahan

So allow me to divide that in half.

43:48 Derick Bailey

Sure.

43:48 Udi Dahan

So for the person on a project that needs to deliver a working system, the answer to the question, how hard can it be? Is very damn hard to not go inventing your own wheel. Okay. That would be my main message.

44:11 Derick Bailey

That's a good message.

44:14 Udi Dahan

For the person that's kind of in this I want to learn, I want to figure out, I want understand the technology. I don't actually have a specific business problem to solve. Then I'd say find open source implementations, get into their code, run the samples, pick it apart, put it back together again. That's a great time to build your own and you can learn a lot about queuing systems that can serve you very well when actually building a production system, once that Rabbit MQ, for example by default, doesn't do multi queue transactions.

45:12 Udi Dahan

So if you're reading from one queue and you're writing to another queue, then you can end up in a situation where some messages actually escape or that in the Rabbit MQ client publisher confirms is turned off by default. Now that's a very nice feature for getting high performance numbers on benchmarks. But that can result in message loss in certain failure conditions. So those are the kinds of things that arguably you wouldn't find out by just using things like NServiceBus because it hides all that from you. So when somebody says, "Well, why should we use Rabbit MQ rather than active MQ queue?" Or what are the of this over that.

45:59 Udi Dahan

It's really hard to speak to the comparative strengths and weaknesses of technology because the abstraction layer just hides it all from you. But again, I look at that as a more from a research perspective to kind of just learn about the technologies and all of the knobs and dials that are down there. And then potentially that can help you understand why certain decisions were made, and why developers should be shielded from some of these things when writing their code. So that would be my... it's kind of a message to this audience and a message to that audience and the connection between them.

46:39 Derick Bailey

Yeah. That's phenomenal advice honestly, I think I could use some of that advice myself right about now there are certainly some times where I'm looking at my code that I'm writing and NodeJS with wascally and Rabbit MQ, and going this is really damn hard. So I really appreciate you taking the time to do this interview, to be here, to share this phenomenal knowledge and wisdom with the audience today. Thank you so much for being here.

47:12 Udi Dahan

Well, thank you Derick, it's my pleasure.