Episode 91: VMware's James Urquhart on Event-Driven Integration

Brian Dawson: Hello, this is Brian Dawson with DevOps Radio. Today we have another episode of DevOps Radio where we are joined by James Urquhart, the strategic executive advisor and author of Flow Architectures: The Future of Event-Driven Integration, working at VMware today. Hello, James, how are you doing?

James Urquhart: I'm doing great. Thank you very much, Brian. It's good to be here.

Brian Dawson: Great. I'm looking forward to having a conversation. I'm looking forward to – you're going to make sure that I leave this episode as an expert in event-driven integration, right?

James Urquhart: Well, or at least a good speculator about its future.

Brian Dawson: All right, I'll take that. So James, today you're a strategic executive advisor at VMware, a company that when we talk DevOps has had a serious impact on what we do, all the way from the days that they prevented us from having to issue CDW orders every time we wanted to run an app all the way up to now. But before we get into the details of what you're doing there and your book, I was hoping that you could give our listeners an overview of what you do as a strategic executive advisor and a quick view into how you wound up there. You have a pretty wide-ranging experience in what we know as DevOps companies. So I'd love to share a bit more about that with our listeners.

James Urquhart: Oh, I appreciate it. Thank you. Yeah, I have a, at this point, 30-year career. It just blows me away to have to say that, but a 30-year career in distributed systems dating from obviously the early nineties when we were doing very sort of hand-coded client server work. You know, I worked on a system back then that was a Smalltalk frontend talking to a FoxPro backend to give you an idea, right? So and over the course of time, in the late nineties worked for a company that did a 4GL called Forte Software. They did it for 4GL for distributed systems. And did presales and post-sales there. And very hands-on technical engineering and consulting in that time period.

And then I kind of got a little bit of the product management bug. And so I did a stint at Sun Microsystems where I was sort of more internal product related stuff but then ended up at a company called Cassat for a while. Was an SE but also worked very closely with the product folks there. And they were sort of my first exposure to sort of commoditizing the data center. They built a data center automation environment. And so I got a very good sense of between Forte and Cassat, a really good sense of the kinds of things that cloud computing are bringing to the masses today, right? The idea of a very automated mechanism to just deploy and manage and run distributed applications and a very automated infrastructure mechanism to support providing infrastructure on demand to those applications as the need it.

And around the same time, I discovered the concept of complex adaptive systems as well which is a very important science that is changing the way a lot of fields of science and social sciences and everybody are kind of considering the way systems work and the way that agents interact in a system. It really resonated with me that the internet is becoming this massive, massive complex adaptive system with all kinds of dependencies and is really not a manageable entity on its own. And it struck me that enterprises were increasingly at the time looking like that as well, right, where there was no central enterprise architecture where everybody knew where their pieces fit with everybody else but that there was more dynamic creation of systems that were integrating with each other dynamically and coming to life and being shut down and in very unplanned ways.

So long story short, I did a VP of product stint for a company that got bought by Dell in 2013. And then I did a stint doing product work for a company called SOASTA that did large scale performance testing and real user management technologies but was really a data company at heart and so I created some data products from them. Ended up at AWS as a GM on a project there that I won't say too much about – for a couple of years.

And then found myself wanting to get back in front of customers and wanting to get back in the role of having conversations with people with, you know, large sets of problems that need to be dealt with. And ended up in this role at VMware where really my job is to work with the most senior leaders in organizations, usually CIO/CTO but also engineering management and others to look at not how do you execute at a team level a DevOps approach but how do you organize an enterprise to take advantage of Lean and Agile and SRE in a way that – and the platforms that support that in a way that is beneficial to the business and allows for good people management in addition to good outcome management.

And it's a big challenge, right? There's a lot of information out there about how to run DevOps teams, but as you get to larger and larger scales of teams that are interdependent on each other, it's a very, very difficult problem to manage. It's right now a bit more of an art than a science in terms of how you handle that, although it's becoming more understood. So that's really my role. I'm a little bit more focused now specifically on developer path to production. So everything from concept and financing for project all the way through to day two and even day three shutdown and end of life activities. What can we do to minimize toil and also maximize economies of scale and efficiencies within an enterprise without handcuffing developers which is always the tradeoff, right? Is the concern that you're going to block a developer from being able to do something that would be really valuable for the business. So doing a lot of work with technologies in the Kubernetes space around that path to production.

Brian Dawson: Wow. There is a lot there. First I want to say that it is impressive that for a 28 year old, you know FoxPro and 4GLs. Right? What we're now calling low-code and no-code and has turned to other things. Everything is connected. Is it fair to say – and, by the way, there's a lot there I could sink my teeth into but I have to be responsible supposedly people tell me. So really when you talk about what part of what you have done and are doing as a strategic executive advisor is really an extension of your work in complex adaptive systems, right?

James Urquhart: Exactly. I mean there's no getting away from the fact that you have to look at how you manage and you plan in a very different way when you move from that sort of well-defined, I can put a blueprint around it size and scale to a highly dynamic, we need to be able to move and adapt. And the organism that is the organization as a whole has to be able to not just survive but to thrive. And so that mentality of shifting your idea from I can define all the variables and the parameters ahead of time to I can't and I have to be able to respond to the variables as they change is a critical piece of what management has to think about today and how they have to plan around that. It's also, by the way, one of the reasons why I got very interested in the event-driven concepts as well, the event-driven architecture concepts because it's a necessity in order to do the same thing from an automation perspective.

Brian Dawson: Yeah, man, there's so much there. I mean I think, you know, right, if I deal a lot with scaling DevOps practices and its component practices and with a focus on the human element, humans developing software for humans but doing it at enterprise scale which is very different. One of the things you bring to mind for me is that it's analogous to how you describe the internet as a complex adaptive system, right? There's a common connection. Hopefully and oftentimes a larger higher order outcome depending on the org, the teams, et cetera, but with our new approach to software development, collaborative development, a number of other kinds of practices and principles that we're adhering to, you basically end up with a body that is composed of multiple organs that each have their own function, their own way of beating, their own way of operating, and moreover each of those oftentimes is in a state of evolution and you have to figure out a way to embrace and manage that.

I love it and I can see the tie in to event-driven architecture which I guess takes us to one of the next questions I want to ask you. You have a book coming out – I'm sorry – Flow Architecture: The Future of Event-Driven Integration and I'd like to expand on something that you just started on. But first, can you tell me what is event-driven integration and then to expand on where we were, why is important, why does it matter in today's software development environment and in a DevOps world for want of a better term?

James Urquhart: Yeah, boy, a lot to unpack there but let me try to be as concise as I can about the core pieces.

Brian Dawson: Take as much time as you need to unpack it. I cheat. I always pack like three or four questions in one. So the what and why.

James Urquhart: Yeah, I think the big thing is so when I talk about flow and the term flow, and boy, believe me, myself and a number of people that I work with as I kind of was crafting this concept spent a lot of time trying to think of, you know, is there a term out there that's not heavily overloaded that would be the right way to describe this. But flow is where people – I kept continuously getting feedback – was the right description of what we're talking about here. And what flow really defined is talking about is the movement of real-time data as it's needed to all the different parties that may be able to gain value from that data and that are authorized to gain value from that data. So and most people when they think of event-driven architectures and what event-driven means, they think, okay, an event is a description of a change of state of something and a creation of new state or maybe a change of a value or a change of multiple values in the state of some represented entity.

And so event-driven applications means that the applications within my business talk to each other, there are events that come into the system and they respond to the events and may even talk to each other, all the different services may talk to each other with events. All of which is a much more composable way of putting an application together. You have much less dependency between the consumers of those events and the producers of those events which enables you to allow basically data to move as fast as it can through the system and the processing in the system till it gets to some end state, maybe gets stored in a database someplace, maybe gets displayed on a screen somewhere. Maybe it triggers another form of event to be sent to another entity. But the big thing that's kind of different – sorry, did you have a question?

Brian Dawson: Yeah. Just, yeah, please don't let me break your thought but I probably prematurely or inappropriately digging down but conceptually as I rock it, is there a difference between modern event-driven integration and a published, subscribed model to different entities communicating? And please don't lose your place but just help me –

James Urquhart: No, no, so the core tenets of – so just to finish the flow definition here so flow – and then I'll explain that as I kind of get into that. So flow is focused on that movement of information across organizational boundaries. So making it as simple as possible for organizations to say, hey, I want to subscribe to that stream that comes from this – so I'm a trucking company. I want to subscribe to that weather stream so that I can in real time get the latest weather data to match with the latest traffic data that I get from this other stream so I can plan my truck routes and schedules more precisely, right?

And the state that we're at right now with that kind of an integration where we're trying to subscribe to stream – so to your point, publish and subscribe is actually core to the basic concept. I've looked. There may be other mechanisms that are a part of flow in its end state. There may be other things, but all signs point to it's basically a producer publishes an event to a topic and a consumer subscribed to that topic and receives the event. And so when you look at subscribing across those organization boundaries, there's no standard interfaces or standard protocols to do that today. It's all custom. If you want to receive the Twitter stream to do some data analysis on a Twitter stream, you cannot then take the exact same connection code that calls the Twitter API and then turn and point it to say a tech stream coming from Twilio, right? That's a whole different API, whole different stream process, whole different protocol for defining the elements that you're going to receive through the stream.

And so when it comes to this form of data that represents sort of state changes that are important at a fairly discrete level, we lack a standard way of doing that. And when I first thought of that, the first thing that occurred to me was, you know, it's interesting. If we did have that, it would be incredibly cheap to do that kind of integration, right, because you'd have libraries that already knew how to use the standards. You've had programs and monitoring or observability or whatever term you want to use. You'd have, you know, security software that understood the protocols and the connection mechanisms.

And you'd have – in fact there are companies already working on new forms of core infrastructure, meaning new forms of network connectivity on top of TCP/IP but new forms of connectivity models that are very publish and subscribe aware and are very focused on sort of globally how do you efficiently connect to a topic that's maybe being distributed across multiple locations, right? So edge computing concepts coming into play there.

So that's the core concept of the book is I use Wardley mapping and I use promise theory, two great modeling techniques that begin to understand situational awareness of where we are today and where things might move. And I use those two things to make a strong case to say we are going to see standard protocols and standard publish and subscribe interfaces for enterprises to connect to streams from other enterprises or for nonprofits to connect to streams or governments to connect to streams or publish.

And we're going to see those very standard interfaces, I would argue that it's going to boil down to a very known interface that may have some things that handle different use cases slightly different but that you point at and you go, yeah, I know what that standard is. And that when we get to those standards, you're going to see a marked change in the way businesses do business with each other because the cost of integration will go, for real-time data will go so low that you can do things that are just impractical to do today.

Brian Dawson: Yeah. I have a brother that is a product manager and has had a number of roles, you know, spent times product managing and you know I have a number of peers that are the B-to-B integration team and there is work, there is planning, there's some process and a product, so to say, and maintenance for every B-to-B connection that say an organization, even such as Expedia where they have their own level of standardization to map and map to others. So interesting. So disappointed I don't get to ask you all the questions I want to ask.

Now, what I do hear quickly before we move on is if we think about the Web 3.0 – and this is going to be difficult actually for us to get in and out of this quickly, but it really sounds like a more internet, cloud, and API oriented aware – a way – I'm sorry, an API aware way of bringing forth what we sort of in the recent what 10/20 years saw with SOA, service oriented architectures and service lookups with service descriptors and sort of akin to the promise that I think we haven't fully realized of Web 3.0.

James Urquhart: I think, you know, a lot of people have kind of given that feedback of, boy, this sounds like SOA again or sounds like other things. Yeah, to a certain extent that's absolutely true. I think the difference of what I'm proposing though is that we now have tools and mechanisms that work at scale, that work at very significant scale, right? We now have demonstrated capability to handle massive streams.

When I worked at SOASTA, the real user management we were doing was think of the largest – with the exception of Amazon, sort of largest retail organizations and the largest media organizations out there, news media and others and you think about receiving the data from every single browser interaction – not just the high level what page did they hit and what's their username, profile data, the performance data, for every single element load that happens on the page, every call response that happens from the browser to a backend somewhere to get an image, to get a Facebook button, to get any number of things and being able to measure very clearly at great detail for every single user what exactly was their experience in terms of page load performance.

And that data came in from these websites that have hundreds of thousands to millions of users a day just 24 hours a day on a regular basis, and we had to have the engine that would consume that data. And then we were able to find and build a system that was able to consume that data using a lot of off-the-shelf products, not having to custom code every aspect of what we did. And I think Kafka and I think a lot of the Apache event processing portfolio that's out there plus some things that the CNCF are doing around serverless with the Knative and then the cloud event specifications that's connected with that, they are now moving in the direction – those pieces have moved in the direction where enterprises realize we should be able to do more things in real-time, less batch processing, more real-time processing the data that we exchange with other businesses.

And that's really the starting point, right, is they begin to replace all of this batch processing that we still depend on. I've been told with great assurance from people that are in the financial services industry that it's very likely that with the possible exception of bitcoin there's not a single financial, digital transaction that occurs that doesn't have to go through some form of batch processing before it's fully settled. Right? So we absolutely the economy relies on batch processing and it delays how fast we can do certain things. Sometimes that's a good thing, but very often that's a bad thing. And so what I look at with the event-driven, the real driver for this is going to be better customer experiences. Customers doing business with one business and going to another business to do something related and already seeing their transaction at the first business reflected in what they see in the second, right?

Brian Dawson: Yeah, the continuity.

James Urquhart: Right. All that kind of stuff is – real-time inventory is already taking advantage of the stuff, making it basically a no-brainer for any business to be able to supply to another business.

Brian Dawson: Well, it is maybe my experience with Walmart.com – sorry Walmart – when trying to get a PlayStation would've been better. Maybe it wouldn't have put it in my cart because you knew that you didn't have inventory. But no, so I'm going to get to the other component of my question real quick because I also hear – I heard you kind of – I heard actually some inter-enterprise, right, inter-org application of this, but it's also for inter-org, right, continuity? But going back to somewhat to the inter component, it could span either space. Let's go back to the question of why's it matter, why is it important – I mean you hit kind of the why it matters. This is DevOps Radio. Is there a correlation between the need for what you cover in the book, which I'll absolutely have to read and learn more about, and the way software development is shifting along DevOps lines?

James Urquhart: Yeah. So there are two aspects of that. So one is as we build more event-driven systems, the nature of what we are building begins to morph to reflect that, right? So instead of building a lot of things that are intended to be call response, you're generating things that are intended to be a lot more like say the Linux, you know, text processing commands that are out there and what you can use with Linux Pipe commands. And so the nature of that is then that it actually decouples even more a lot of what happens as long as there is an agreed upon protocol between how everybody is talking to each other and gives a little bit more flexibility and it becomes more important to adhere to the standard and to understand what payloads you can process and how you can process them than it is to understand what the big picture architecture is ahead of time.

That's not to say somebody shouldn't worry about the big picture architecture, but it becomes less important to understand where does this service fit in the overall architecture. So that's one side. I think it's going to affect the way we architect applications which is going to be friendly to Agile and Lean approaches to software development. What the other piece of it is I believe that the dev tool chains that we have out there themselves are going to be more and more event driven and more composable where you can bring different elements in, where you need to on what's going on.

So you've got kind of the core CI/CD and repository and code repository and then container repository kind of picture that's core to the build and deploy process. But in addition to that, now we're talking about what if you could very easily insert compliance automation in the right places in your process and be able to move that around as you learn about where is it really important for us to run certain rules against our systems? There's a lot now with the whole Solar Flare, the whole –

Brian Dawson: SolarWinds?

James Urquhart: SolarWinds, sorry, yeah. SolarWinds, Cloudflare and SolarWinds, I'm getting them mixed up.

Brian Dawson: No, that was a good combination.

James Urquhart: But SolarWinds, the whole SolarWinds thing, right, is there's going to be more demand for software that can pay attention to and insert themselves into the relationships between components of your build chain. And so with that concept in mind, one of the things I think will happen is you'll begin to see a move – and it already is happening if you look at Tekton and Argo. Tekton admits cloud events today. So you can actually do some event-driven response to my CI completed and reported the following state which would allow you to have multiple things respond to the completion as soon as it's complete. I mean just there's a lot there but I just I'd also call out the modernization and improvement on the webhook approach. So if we look at what GitHub and GitHub actions, we talk about that CI/CD space and that very much – and sorry to jump in and step on you, but we started out early on even before the call talking about scale and enterprise scale and you brought it up earlier. I think one of the things that really triggers me to the extent that I'm grasping what I'll read in the book is there is a keyword you use and that's crossing organizational boundaries. The complex adaptive system that is agile CI/CD and DevOps in the enterprise, I mean that's the challenge. How do we flawlessly in a consistent way cross organizational boundaries and also in a way that we can ensure we're, to your point, injecting rules and policies to ensure governance and compliance to ensure that the data we need to get and roll up across the applications is there? Anyway, I'm digging it.

James Urquhart: And I'm sure you guys, I'm sure the Cloudbees' folks and others out there in the space are very aware of this rapidly now shifting environment in the way build chains work and because the underlying infrastructure now is adopting faster, right? Yes, Kubernetes is standardizing but the components that round out the Kubernetes story are quickly adapting and changing today, networking and all, all of the things that you have to be aware of as you kind of build and run your applications. And so to me that's one of the drivers here is that the constantly adapting state of the systems that we're working with, we want to begin to be opinionated about things but we also want to be very quickly able to reconfigure when the system or when the inputs and the outcomes we're looking for require it.

Brian Dawson: You've, for lack of a better word, excited me as we dug deeper down into it. That last line, think about this, right, when we talk about Tekton or we talk about Jenkins' Pipeline script or whatever we use to describe our path to production. We describe it very statically, right. And at best we're now getting to a place where you can use sort of include style constructs, right, to have some shared process, some shared steps. But what you triggered with me with changing networks, right, is we truly look to automate an end-to-end workflow to deliver from right now commit to production quickly.

We have people – and I'm thinking separate and then kind of B-to-B APIs but sort of where you're going, you know, people that wake up every day and it's about maintaining, using human interaction to try to find out probably after it breaks that some configuration or something downstream changed and then you got to deal with updating sort of the static description of the workflow in the systems and then you got to propagate across the org. So where it gets really intriguing for me, if I'm interpreting your correctly, right, is think about this idea that all of the variable or changing elements in that path to production can be dynamically recognized and reconciled through –

James Urquhart: And from multiple vendors, right? And so they not only can dynamically reconcile but you know that if you build your component to fit into somebody else's tool chain in a certain way, that they will be able to consume it or that if you want to subscribe to a stream coming from a service that can help your tool chain be more efficient and no example comes to mind, but if that is something that comes up, you can quickly do that too. You can have a stream that comes into your environment to help with that. So that's really what it comes down to. That's what the book is really about. It's just laying out why people will care, right, why do businesses want this in the first place and where's the state of things now and what are some of the ways you can pontificate that things will evolve to an end state where we have that very easy integration?

Brian Dawson: Phenomenal. Phenomenal. So I know I have to get you out of here. I want to quickly, let's extending from DevOps and connecting sort of DevOps to VMware and enabling technologies, you have done work with Tanzu. In communicating and preparing for this, you had commented that Tanzu is really enabling customers to drive or I'd almost argue achieve modern application development. Can you just take – I want to reserve some time so can you take a couple of minutes just to give the high level of what is Tanzu and how's Tanzu similar to other things we've talked about here enabling modernization of the development process?

James Urquhart: Sure, that's great. Yeah, so VMware Tanzu is actually a brand, right? It's a suite of products under the Tanzu brand that aim to solve three core problems of modern application development – how do you build applications, how do you run those applications meaning what are the infrastructures and automation that you can put into place to actually run the environment, and then how do you manage that stack, right, that stack of the application and the infrastructure and everything in between.

And so core components of it are Tanzu Application Service which is the old Pivotal Application Service which is evolving right now as we speak towards being very Kubernetes native in the way that it does things. It includes the Tanzu Observability by Wavefront which is an observability environment that allows you to see that entire stack including your vSphere and your Kubernetes environment all the way up to your application level observability. It includes Tanzu Build Service which is the first sort of decoupled element from the Taos components which is focused on building cloud native build packs and using the cloud native build pack standard to give you a very consistent way of assembling containers with all of the dependent components needed for your software and automating a ton of toil that you would normally have to have yourself in order to do that work. And it includes Tanzu Application Catalog in there. I'm going to leave a lot of things out. Tanzu Application Catalog, the old Bitnami stuff, right, a catalog of opensource components is available. And Tanzu Service Mesh as well for the networking component.

There's a number of other products in the suite and really our focus is to provide both the individual products that people need to solve specific problems in their dev tool chains where it makes sense to but also to provide that VMware consistent story of a very solid, consistent, enterprise-ready baseline for getting the capacity you need, the server network storage capacity and capabilities that you need to run your applications consistently.

So the last thing I'll say real quickly about it is we have, for instance vSphere 7 we've integrated your Kubernetes management right into the vSphere application suite and right into the vSphere console. So all the skills you have for managing VMs and the VM real estate you can apply towards spinning up clusters and spinning up pods as necessary in your environment as well. And including, you know, providing interfaces that are well known to your developers to allow them to do self-service in that respect as well.

So it's an exciting time to be at VMware because we really do, I think, stand alone in a lot of ways in the fact that we already have that trust level in terms of the infrastructure virtualization and the ability to abstract infrastructure for developers in a way that's very, very trustworthy. And what we're doing now is we're bringing that abstraction up a layer to what containers are and beginning to include and bringing in the stories of Bitnami and Pivotal in terms of making application development to that infrastructure much easier and much more performant for the developers as well.

Brian Dawson: Okay, well, I swear I must have been nose down too long because there's a number of acquisitions in that response that just missed. Funny, Bitnami, I was a big Bitnami fan. Great way to use packs to spin up. So I have to make sure before I let you go that we get your book promotion, but I also cannot get to that or the book giveaway – I cannot get that without first asking the dev oops. So can you share a dev oops, not DevOps but O-O, dev oops or oh **** that you've experienced in your career, a technical or other challenge that you faced, a mistake that you made that you learned from that you could be as vulnerable and as generous to offer up to our audience here?

James Urquhart: Sure. Well, I talked about, you know, those early client server days, stuff that we were working on. And we were working very quickly to help this large telecom to kind of get their stuff out and working in object-oriented programming early in the days of sort O-O stuff and I thought I knew everything, right? It's pretty typical of somebody who is sort of that two, three, four years in to a certain programming language and a certain structure that, oh, I know what I need to know. And so I'd come up with this object model that in fact used the concept of events within Smalltalk to go, hey, here's a really interesting way that I can just snap in new ways of doing it. I think it was like an invoice, right? Invoice with line items or something.

And so I build it and I test it and it works just perfectly and it's awesome. So I go and release it to QA and QA comes back and goes, "It doesn't work." I'm like, no, I've tested it like a bunch of times. It works. They're like, no, if you do this, it breaks. Sure enough, if I do that, it goes into this infinite loop. And I'm like, crap, what'd I do wrong? So I work on it. Oh, I think I found the problem. So I fix that problem, release it to them, the next thing that the QA person does puts it back in an infinite loop.

And the lesson to me that was kind of learned there was sort of if I had known about test-driven development, it would have been obvious what to do and like what I was not doing right, did not have the right unit tests in place to really make sure I was covering the bases. But what I really learned out of that was that there were better practices that were already stated pretty clearly in the industry about hands – basically the Gang of Four patterns book I think had just come out and there were patterns I should have looked at and used that would have absolutely not given me these problems and made it – and then in the end, that's where I ended up. I ended up implementing something that looked exactly like a Gang of Four pattern that was seamless and worked perfectly that didn't use this eventing stuff at all, didn't use any of the fancy stuff at all. And thank God I wasn't releasing directly to production because I guarantee that I would have thought my tests were right and I would have brought the world down. One super quick real short story, the other thing I learned is that as a product manager is the number one trap you can fall into is if your buyer is not your end user. Don't focus on building a product that the buyer wants because they won't end up being able to sell it to the end user so.

Brian Dawson: Unexpected but great tip to call out and I love, as I always say, right, hands-on keyboard software engineering patterns and lessons that you learned and then jumping back up to look – at the end of the day it's not just developers that create software, right? There's multiple chains in getting the code we write for the problem we try to solve to the point where it's bringing impact for somebody. So that was a great surprising note. Well, James, I got to say just phenomenal conversationalist, really enjoying this. I really have. Before I let you go, let's talk a bit about what you've brought to DevOps Radio and that is the ability for us to do our first promotion along with you. So you, as we said, have just authored a new book. And let me confirm, when does it release? When is the official release?

James Urquhart: We just looked today and so the Kindle version was released on the weekend and Amazon is indicating that they'll ship within a day or two as of today. So it is officially available in both print and electronic versions, and I welcome people to go to Amazon to take a look or to O'Reilly as well. If you have an O'Reilly subscription, you can read the book there for free so.

Brian Dawson: Well, hats off. There was a quite clap in the background. Congratulations. Here's to hoping that, like you know, books like Gang of Four, right, that you're giving a view that helps lead the industry forward and has a real impact. I am sure that with this, just based on our conversation here, that you'll be leaving an impact. So what you have offered is the ability to do a promotion. So listeners out there, DevOps Radio listeners, if you are listening to this podcast and you haven't already bought the book, which hopefully you have, but you'd like a copy, what we're going to ask you to do is after listening to this podcast, please send out a Tweet, tag Cloudbees, tag James at – and James, I'm going to ask you – well, actually here we go. Tag James on Twitter.

James Urquhart: Yeah ,you can copy me in @J-A-M-E-S-U-R-Q-U-H-A-R-T.

Brian Dawson: Awesome. And tag @cloudbees, C-L-O-U-D-B-E-E-S. I can spell that, James –and hashtag DevOpsRadio. And what we will do is we will collect all of the tags and we will very scientifically and algorithmically select a random person from that list and get a copy of Flow Architectures: The Future of Event-Driven Organization – of Event-Driven Integration.

Thank you. Hold on, let's leave an edit point here. We'll pause. So tag James, tag Cloudbees, add #DevOpsRadio and we will select someone to get Flow Architectures: The Future of Streaming and Event-Driven Integration. So with that, James, thank you for your time. I want to get you on to your next thing. I wish you the greatest success with your book. And I really appreciate the thoughts and concepts that you've contributed here today.

James Urquhart: Well, thank you very much, Brian. I really enjoyed being on the show and stay safe out there.

Brian Dawson: Likewise. Take care.