Messaging Architecture and Services Bus with Udi Dahan

so I’m here today with Judy DeHaan CEO of particular software and world-renowned speaker and blogger and far more than that also the creator of n service bus a service bus obviously for platform which allows a lot of different architectural patterns to be baked into your software quickly and easily managing your work flow through your messaging system whatever that messaging system back-end maybe Judy it’s 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 well thank you for having me Derrick it’s my pleasure 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 and messaging patterns and 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 so the first the first use I had was a very large distributed system that was built for the Israeli Air Force oh wow it was built in a very old language called ADA a dome you know ada lovelace voice that’s right and it was the kind of system where when they say mission-critical attack he means the literal term mission-critical it gets bandied about fairly frequently in commercial types of settings yeah but but there it really meant it and and the whole system was built on this paradigm of mailboxes everything would be done by putting a message in a mailbox okay and you know that that was sort of the the first really large-scale project that I was on and you know I was just you know one developer out of a team of I don’t know how many hundreds even Wow so it was just kind of like this is the way that we do it I’m like okay sure what do I know right so kind of went with the flow though the language wasn’t that great but just that style of programming it 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 fit was almost always triggered by a message coming in off of one mailbox you know you do a little bit of work and then you put messages and other mailboxes and that was kind of how everything was built and they had this really crappy interface definition language thing it wasn’t wasn’t that pleasurable to use ultimately everything needed to do to be coded down to really tight binary format but this concept of having strict message contracts and contract definition and evolution and keeping things decoupled was right there from the very beginning and I got to see that that system go live and and see that it working in it’s called really difficult types of production environments right 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 how this concept of messaging in there and ie someone took it for granted I mean you know 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 why aren’t you doing this I mean you’re using much more advanced programming languages than what

I had used but why don’t you have this thing why is everybody doing our PC type of communication the synchronous request response because that was a big no-no I said you know don’t even think about doing that don’t try to do that on top of the mailboxes because it’s just gonna cause the system all sorts of grief yeah there’s gonna be connectivity failures and parts of the system going down you’re not going to have guarantee of everything being there so I can I can definitely see how how the RPC world is kind of counter to the idea of the mailboxes that you had previously worked with so that was the start of it for me and then moving into dotnet in doing projects there it’s like okay you know I looked for the thing that was closest to the message box and I said okay there’s this MSM queue thing right which Mississippi was not a great technology but well you know in around the time the dominant was released 2001-2002 mq was still not that great it only got that art around 2003 okay when I think it was SP one of Windows XP or something like that on the client and then you got windows 2003 server then it kind of got quite a bit more robust but at the time I was using a lot of typical rendezvous and rendezvous was an absolutely amazing first of all very low latency very high performance messaging platform there you know the dotnet api’s were you know left something to be desired but you know that 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 master majority were you know communicating over HTTP or TCP whether you’re talking about XML Web Services or dotnet remoting or Java RMI or you know all of those various equivalents the synchronous request response style you know every time I was brought into a project that was doing that I would say but wait a minute how how’s the system gonna work when you know that process dies yeah and people kind of looked at me funny what do you mean even asking that why would that ever happen I’m like here you know I just killed the processing you see how the rest of the system hangs they’re 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 DevOps type movement developers just focused on writing the code and works on my machine was actually a reasonable statement to be made I remember checking in code or throwing it over to QA yeah so I wasn’t coming from that background but you know that’s kind of how I got started and why I felt like you know something needed to be done to to lower the barrier of entry for other people so was that that the kind of the genesis of service bus right there was that desire to lower the barrier of entry for people to do message oriented systems like that 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 okay I I didn’t think that they needed to be experts in TIBCO or MSM cure 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 that most of the yucky low-level concerns about managing connections and all sorts of options on the message and time to live and there’s a million and one 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 we’re in the libraries and just creating an abstraction layer on top of that that’s how it got started okay and you know after one project to the next to the next though that that abstraction layer kind of got bigger and more fully featured to the point where I was like okay this is it’s a thing in its own right right but you know at the time I didn’t really think that anybody would need to have like a standardized wrapper around the game 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 yeah and there’s a million ways of setting things up that you know

for 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 fine 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 queueing system 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 back in 2008-2009 timeframe and I had looked at and service bus as an abstraction layer to use I had also looked at mass transit 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 gonna go straight to the message queue well a year later I had my own poorly specified half implemented terrible version of a service bus and realized you know when it was too late I really should have just stuck with in-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 think you know nobody realizes that they need one I mean there’s this this you know how hard could it be you know it’s just a message I’m just putting it here and then I’m getting it and what how hard could it be right and WebSphere or TIBCO or those types of technologies that 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 WebSphere especially there we 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 it was there 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 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 and we were quite happy with it and that was my first foray into messaging so we’ve we’ve mentioned service buses a number of times here and service bus 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’s 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 right so the the first issue is that the the term service bus is itself quite overloaded okay when when service oriented architecture started to take off and around 2005 2006 that’s when a lot of the the vendors you know your IBM your web methods your Oracle’s of the world that they had pre-existing message broker acknowledging grace and that they’d built for the most part in the early 90s and kind of continued evolving it since then and when the industry said oh no we don’t want a message brokers anymore brokers are passe they’re out we want this new service-oriented bussy thing that’ll be distributed and scaleable and all these nice things then the big vendors kind of turned around repackaged a lot of their existing technologies and to large extent they they webservice sized I said you don’t want message brokers fine they now speak wisdom they now support all sorts of other specs from the WS star they you know the security the transaction the addressing reliability and of course you know you have orchestration and content-based routing and all of these other kind of feature sets so that’s let’s call it that’s the Enterprise Service bus that’s where the enterprise-e bit is that again so what you’ll invariably see with a lot of Enterprise Service bus technologies is that there’s a very strong focus on on Web Services and enabling RPC synchronous request response type work

okay for the average dotnet developer the technology that would be most similar to this would be like a BizTalk right 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 that’s the big Enterprise Service bus right now we’re in service bus and mass transit and a lot of the other offshoots came from was actually the no we don’t actually like web services in this request responsi style we’re 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 micro service-oriented okay that’s because the idea around and service bus 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 so that’s what I’d say the end service bus and the modern incarnations of micro service 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 right right so I said that’s that’s the number one difference right and and it’s very confusing because the terms are just so similar yeah add that little Enterprise in front of service bus and suddenly you have a completely different ballgame that you’re talking about right right so so so back to your question from from before maybe you can remind me as well as our listeners what the original question was so I wanted to get at what the heart of a service bus is like in service bus or mass transit or even my own more recent working with my own nodejs library that I called rabis I’m I’m kind of heading down the path of a service bus with that 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 their messaging system in whatever language they happen to be using right so I’d say that there are a couple of levels to a service bus there’s the first one which is 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 a way for the client to know which response is associated with which request that they said because everything’s happening in parallel right 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 right model so I’d say that that’s sort of the the first layer of stuff that you’ll see in almost every service bus it’s just kind of making the the messaging patterns easier to consume by a developer right so in the case of the Wassily library which is my preferred abstraction on top of RabbitMQ 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 West Valley library ever knows about this correlation ID but it allows you to very easily just say oh you know 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 RabbitMQ private queue or exclusive to you so in the case of rabbitmq a correlation ID is used

slightly differently than in other queueing systems but it’s still there and we get that reply coming back and then lastly that library manages understanding which response goes with which request so that the developer doesn’t have to deal with that right and you bring up another point which is very important is also the management of the topology right so which queues 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 a request or a response it should really be only consumed once however it’s and if it’s an event then we fully expect it to be consumed in multiple times and there are different ways of setting that up whether you’re using RabbitMQ RMS MQ or as your service bus or whatever type of queueing 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 that this lower level will just make sure that it’s kind of the make it so library right can I just have it work that’s that’s what it’s there for make it so number one exactly so so that’s the first bit the second bit is when you start getting into let’s call it more production readiness okay types of scenarios where you start dealing with things like the intersection between the business logic that’s processing a message and the 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 know exception that’s thrown like connection refused by the remote host the database connection pool is maxed out or something right now again you as a developer can write the code yourself to say okay I got that I’m going to catch that exception I’m going to wait a couple of milliseconds and then I’m gonna 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 timeout set timeout in my node.js code here and they’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 the potential problems there 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 you know moving that somewhere so there’s there’s a whole other set of taking a message driven system and making it fit for production right that usually a developer when they’re starting a project they 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 2 version 3 in a system where you start having these types of versioning compatibilities that you start having to solve these problems then you’re like okay so we’re I’m gonna write the exceptions too and then how do I centralize them because I have all of these distribute machines and you create a whole other set of capabilities to to get your message driven system ready right 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 you know Poisson 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 this rabbit hole goes really really 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 100k limit I think was the

default message size for WebSphere MQ at the time is easy either 100k or 1 Meg whatever was we were sending ridiculously large messages several Meg’s 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 re piece it together and then be able to process it by the actual business logic so it’s 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 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 I keep track of the sequence of messages being sent if it’s an old message york and if it’s a future message beyond where i currently am care I’m just going to apply that future message because it contains the full document in my case so there 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 to not have to deal with those things right so where does where do we go beyond a service bus though is is that kind of the endgame for the business layer abstractions or is there something that we do beyond and service bus or mass transit or whatever it is that we’re using so there are certain let’s call it opinions okay in in service bus 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 endpoint can publish a given event type okay so you for each event type you could have one logical publisher they can scale out that publisher to multiple physical note nodes but you only get one of them and when people run into that the first time they kind of say but wait how how exactly am I going to 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 okay so you want auditing the right way to do auditing is actually differently okay so auditing is something that should be done from the perspective of when an endpoint processes a message and 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 Q’s 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 on at 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 you know just it won’t let you do that and if you try to have multiple publishers of the same event because you know you’re saying I want you know to publish and audit here and I want to publish an audit there say no wait a minute your your 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 right 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 an end service bus 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 so I’d say that’s the part where we start getting into an architectural II significant piece of technology because it’s not just a library it’s not just a framework that says okay this is you know you have to conform to these api’s it goes a level above that and says you know you can’t just do whatever you want with your message contracts we’re gonna 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 yeah and you know invariably we get this kind of pushback or people saying yeah no but really I want to do it this way they say look you know if you want to do it that way you can drop down a layer and use the lower-level api’s that we have uh you know an iMessage receiver and 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 you yeah I had similar experiences when using and hibernate the object relational mapper I fought and hibernate for a very long time and I finally gave in on one particular project and said fine I’m just gonna do it the way in hibernate 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 I can see how how the same thing could happen within service bus or other service bus implementations where you have especially with with only being able to publish an event from one place I can see that sounds really painful to me offhand like no of course I want to be able to publish this from multiple places because I’ve got I’ve got all these things going on I want to audit from here I want to do this from there but like you said once you have multiple logical places in your system that 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 what the single responsibility principle is to limit the number of reasons to change something so you 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 sure and there are a whole bunch of little things like that and in service bus that you don’t really you don’t realize how important they are until you’ve built a system that way after doing it the old way right and and and that’s where we’re I think that you know that’s what makes a service bus a service bus as opposed to just an abstraction layer on top of a queueing system it’s taking more of that architectural guidance and saying you know we’re not gonna let you do that by default I mean if you if you really want to do that you’re gonna have to drop down a layer and lose a whole bunch of capabilities but if you do it this way it’s really gonna work well and and I’ve gotta say you know I’ve been doing this in-service busting for probably about eight or nine years now right and and it’s really that model has held up in in just so many different different business domains and types of companies and you know whatever you want to call it that it’s you know that there is a way to to break down your architecture according to those rules and that when you do that is that you’ll kind of get at this lightbulb moment and say that is so much better yes yes very much so so uh 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 overall system that year that you’re building is is this where your service platform comes into play from particular software so what what does that really entail what is this service platform that you offer well you know without getting into too much detail there there are very very basic things that you start to realize that you need around monitoring when building a message queue different driven in a regular type of RPC system the ops people are watching log files to see if exceptions are being logged right 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 influence is not only how you log things but also how the people will go about monitoring it because they say you ask a problem well part of it is you know is it masking a problem or is it recovering from a transient situation in which the ops person doesn’t actually need to do anything right so the connection pool was maxed out the retry logic kicked in and then you know 50 milliseconds later it all sorted itself out do nothing you know no reason to start signing all are sounding the bells and saying hey come over here look at this don’t need to call the call person at 2:00 a.m. for that 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 well how long should it be I don’t know as a developer what do I know the queuing system says I can keep it around forever just using up you know a megabyte of storage on disk practically free but then you know how long should we wait before we notify somebody about this the next level above that is when you move from single message just 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 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 I would know I really like to be able to see that my current system that’s 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 right so what we do first of all in in service buses we piggyback additional headers that every time a message is admitted we hold on to 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 cost message because messages see cause message D and then we have a UI that allows you to visualize that and show you how things happened if things failed at all the 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 that you need when debugging a message driven system 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 things that that are you know the 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 the you know where did the the service platform in particular come from it’s just all of these things that people running and debugging in troubleshooting message driven systems and versioning them run into over the lifetime of their projects and of their systems I said yeah you know 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 the most of these kinds of problems and kind of had the biggest there were the longest time to actually go around and fix those types of things the most experienced 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 in so is that is that service platform a commercially available product or is that part of the open source so in terms of licensing you know everything is due a license so it’s open so the code is open on github everybody can come look at it and learn from it and of course contribute patches that’s that’s one of the things that that clients appreciate read open source is that you know if I have a problem I don’t have to wait for the vendor to release something yeah so being able to patch the code directly is a huge benefit but it is licensed meaning that you know there will be patches and there will be maintenance and there will be 24/7 support and and really you do want all of those types of things because you know you don’t want to be in a situation where you’re being woken up at 2:00 a.m. and then you have to spelunk through the an service bus code base right to figure out what’s going on yeah much better to just you know 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 so having that there is very useful and you know I’d say for for the vast majority of people and companies their their time and peace of mind is worth so much more than whatever licensing cost is there and it’s fairly attractively licensed compared to everything else of course there are free things like mass transit but sure you can’t call up Chris at 3 a.m. and no I don’t think he would like that very much I know I wouldn’t like that so if if our audience would like to go find more information about service buses in general about n service bus and about your service platform what’s what are the best resources to learn about these things I’d say you about messaging patterns in general there’s the enterprise integration patterns website and book right 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 yeah just do this you’ll find that that 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 years about that kind of stuff so check out my blog udita I’m calm and I guess we’ll have a link in the show notes and about and service bus and the service platform that’s particular net okay so very easy to find 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 so allow me to divide that in half 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 do not go inventing your own wheel right okay that that’s that that would be my main message that’s a good for for the person that’s kind of in this you know 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 the I’d say find open-source implementations get into their code run the samples pick it apart put it back together again you know that’s a great time to build your own yeah and and you can you can learn a lot about queuing systems that can serve you very well when when actually building a production

system once you know that you know RabbitMQ for example by default doesn’t do multi queue transactions right 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 escaped or that in the rabbitmq client publisher confirms is turned off by default now that’s a very nice feature for getting high performance numbers on benchmarks right but that can result in message loss in certain failure conditions right so those are the kinds of things that arguably you wouldn’t find out by just using things like in-service bus because it hides all that from you so when somebody says well why should we use rabbitmq rather than active and cure what are the benefits of this over them it’s really hard to speak to the comparative strengths and weaknesses of technology because the abstraction layer just Heights at all from you but I again I’d look at that as 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 right 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 yeah that’s that’s that’s phenomenal advice honestly I think I could use some of that advice myself right about now there’s there are certainly some times where I’m looking at my code that I’m writing in nodejs with wascally and RabbitMQ 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 well thank you Tara cuz my pleasure