Aaren Quiambao

Welcome to Coding Over Cocktails, a podcast by Toro Cloud. Here we talk about digital transformation, application integration, low code, application, development, data management, and business process automation. Catch some expert insights as we sit down with industry leaders who share tips on how enterprises can take on the challenge of digital transformation. Take a seat. Join us for a round. Here are your hosts, Kevin Montalbo and Toro Cloud CEO and founder David Brown.

Kevin Montalbo

All right. Joining me all the way from Australia today is Toro Cloud CEO and founder David Brown. How are you doing, David?

David Brown:

Good. Thanks, Kevin.

Kevin Montalbo:

And our guest for today is an experience and hands on software architect involved in the architecture, design and implementation of microservices, architectures, service oriented architectures and distributed systems. In a variety of technologies. He has significant experience and expertise in application integration and enterprise architecture which is all found in developer to architect.com, a free website. He founded devoted to helping developers in their journey to becoming software architects. 

Apart from this, he's also the author of numerous technical books and videos, including fundamentals of software architecture, software architecture, fundamentals, video series and several books and videos on microservices as well as enterprise messaging. In addition to hands on consulting, he's also a conference speaker and trainer, having spoken to hundreds of conferences and user groups around the world on a variety of enterprise related technical topics. And I guess he can now probably add coding over cocktails to one of those speaking engagements. 

Ladies and gentlemen, joining us for a round of cocktails is Mark Richards. Hi, Mark, how have you been doing?

Mark Richards

Hi, Kevin. Fantastic. I'm doing great and thank you so much for having me on this podcast. This is exciting. I love the name coding over cocktails. I'm assuming that is only for those that are listening and not for those speaking. So, I am appropriately having tea and that will be my cocktail for today.

David Brown:

We have been known to bring a cocktail on the show. It depends on the time of the day.

Kevin Montalbo

I'm personally having coffee because it's seven o'clock in the morning here in the Philippines. All right. So thank you very much, Mark for being with us. Let's dive right in last December. You tweeted about your controversial O'reilly keynote where you stated and I quote, there are no best practices in software architecture. I think this forms a major theme of your book Fundamentals of Software Architecture with Neil Ford. Can you tell us more about how you came up with that conclusion? Why are there no best practices in software architecture?

Mark Richards

Boy Kevin, did I get into a lot of heated debates with that comment. As a matter of fact, That was during the keynote at O'reilly's Software architecture conference, last February almost a year ago. And that was February 2020. And I like to do keynotes in two forms. One is to inspire um the other is to incite. Um And this one seemed to actually do both. Um Yes. As a matter of fact, that phrase was very bold to say and I'm so glad Kevin, you asked that question because I do want to qualify it because it did create quite a lot of controversy on a lot of social media immediately after making that statement, the crux of it really came from two laws of software architecture that both Neil Ford and I coined in our book, The Fundamentals of software architecture. 

And that first law of software architecture that we coined was that everything in software architecture is a trade off and that was the first law. the second law, which really doesn't relate to it. But still I'll, I'll mention is that the why is more important than the how and this was one of our epiphanies that when you're describing an architecture. Now, what's most is why you made a certain choice? I could see how it works, but I don't know, I can't read your mind. Um But let me come back to that first one because it was a fairly bold statement to say based on our first law, which by the way, no one has ever refuted. Um that there are no best part that um that everything in software architecture is a trade off. Um I went further to say what, what this infers is that there are no best practices in software architecture and, and let me give you a couple of examples where this came from and then I can kind of qualify it for you. Because whenever we're doing any kind of thing in architecture, structural architecture, you, you can't say,, well, you should always focus on performance or, you should always split those services up anytime you have a service that does three things split it into three. You can't make these statements because of our first law of software architecture. I could probably spend a half an hour actually going through examples where everything is a trade off. And that's why we always say it depends. 

Every time we get a question, it depends um how, however, I do want to qualify this because I've had a lot of very constructive and interesting conversations with a lot of people on social media and also just on Zoom and, and, and, and phone calls about this. And I will qualify to say um within the structural aspects of software architecture, there are no best practices because every environment, every situation is different. And you can't say, you should always do this. However, I will concur within another aspect of software architecture, which is architecture, the process. Um There are in fact some best practices um always collaborating, communicating with a stakeholder. There's a good best practice um always do that. Here's a good one, always analyze tradeoffs which is kind of meta because it actually confirms our first law of software architecture. So II I had to soften my tone a little bit on that and really focus it more on the structural aspects because I do concur that there are in fact the best practices in the process of creating architectures. Um But yes, that that was quite a um that was quite an interesting keynote. It's it really stirred the pot, which is what I believe, keynotes are supposed to do it. It's what makes them exciting. So

David Brown

The intention. Mark, you said it inside of a response as in, as intended. What were the major objections?

Mark Richards

The major objections were, in fact, it was too bold of a statement that in fact, there are best practices in architecture. And the problem David was that when I made that statement, I wasn't really encompassing both aspects of software architecture. Now, when we think and try to define software architecture, it's really hard to define. And one of the good ways of really getting an understanding and trying to define software architecture is to think about it really as two different aspects, architecture, the structure and that's more the technical architecture that when we start talking about cohesion and coupling and KC and, and all these technical details about structuring our code and, and, and our services. 

That's the structural aspect and I still do maintain, by the way, David that there are no best practices in the structural aspect. It always depends, but the process aspect what you're referring to now, in fact, um is one way I try to define software architecture and, and really um those were, were the surprisingly enough David, those were, those were where the arguments ended up occurring. And it's like, no, what about communicating with stakeholders? What about appropriate documentation? What about this? I'm like, yeah, you know what, right. What about collaborating with teams? And I'm like, whoa, yeah, you're right. And I'm like, I see where-

David Brown

When you came up-

Mark Richards

Go ahead.

David Brown

When you came up with this original concept. How do you distinguish between structure and process?

Mark Richards

It really is structure is when we start applying technical aspects to um this the, how our code, our source code is organized. Is it a one large monolithic application that's deployed as a single unit such as the layered or a monolithic?

David Brown

So the, but my, my thought is when you came up with this statement, there are no best practices. Had you distinguished between? There are no best practices in structural design as opposed to process design or was that a distinct distinction you made after you stirred the pot and got all this debate going well.

Mark Richards

You know what David? This is what I absolutely positively love about conferences and what I miss so much about speaking at them live because without doing this, you don't get the feedback. Um Yes. In fact, both Neil Ford and I did consider the techniques and soft skills aspects as well. Um Let me give you a really good one. The use of architecture decision records. I love architecture, decision records. It's a way of recording and documenting the architecture, but recording the how or I'm sorry, recording the why. But I can't say that that's a best practice. I really like using them. I find them extremely effective but you David may not and your environment may not be conducive to the type of documentation that you might need that is lacking in an architecture decision record. 

So how can I say and claim that that's a best practice. So we did analyze a lot of the process aspects. However, um Neil and I fed off each other, we really didn't have that live bulk feedback that you get from these conferences and making these statements. So um the nice thing I can actually say about this is I am not at all sorry that I made that statement in that keynote because it spawned a lot of healthy communication and examples here and there where all of us actually learned. And that's really the key. I think David is the fact that we make these statements and especially if they incite something or they're a little bit controversial. what it does promote is conversation and that's where the learning comes from, in my opinion. And so I did learn something from that conference that we didn't take into account all of the process aspect of architecture in that kind of bold statement. However, um the, the statement that there are no best practices was my interpretation of our first law. And so that's where kind of I stepped a little over the line there. And like I said, I'm glad I did.

David Brown

Yeah, it's interesting is one of the most successful content pieces we've developed is an article we wrote on why we killed the connector. The connector is dead between application integration and you know, direct API to API integration bypassing connectors is the future. And it incited a similar sort of response because it was almost an opinion piece, right? And, and people said, well, connectors work well for me and you know that I've been using them for years and they, you know, they add value and blah, blah, blah and, and so so it was really valuable because there was valid points, valid discussion. 

It got your community discussing the whole concept and value of connectors and where the industry may be leading and, and brought out a discussion. So whereas if it's a piece on defining an issue or describing a process, you know, it's interesting and it's useful. But if you're, if you're doing some work in that particular space, but it doesn't necessarily get the sort of traction that you want in um in content marketing these days. So let's move on to architecture itself. You've written a lot about microservices. Um Let's let's go into that space. Do you consider them to be evolutionary or revolutionary?

Mark Richards

Wow. Do I consider microservices to be evolutionary or revolutionary? I would have to say David, both. I think that microservices exhibits both of those. And let me, let me explain why I'm saying both. I think microservices was evolutionary. In other words, defining that difference as would we have, did we evolve into kind of this architectural style about 6 to 7 years ago. And I do believe that we did and that's what I love so much about microservices. I do believe that it was evolutionary, it was eventually going to happen. Um And, and let me explain why um two things were the, in my opinion, at least, in my opinion, two things were really the catalyst for microservices. The first was this whole idea of continuous deployment. We had continuous integration and that was a good first step but continuous deployment. When Dave Farley and Jess Humboldt came out with that book was just remarkable. I mean, this, this finally gave us the answers on how to effectively deploy software. And what did we all have a bunch of large monolithic applications that didn't work? So it was this experiment, this evolution to say, well, what if we broke up the applications a little bit that worked? It was like, hey, what if we broke them apart even further that worked as well? And as we started to really break apart our applications further, we found the ability to do these effective deployment pipelines, continuous deployment and and and continuous delivery. 

That was really the first catalyst from the evolutionary standpoint. I I, in my opinion, The second one I observed was really Eric Evans with his revolutionary domain driven design. I think this, these concepts really formed a micro services. I, I'm bold enough to say again, I I love these bold statements that micro services would not exist without the bounded context to this concept that Eric Evans really drove through a domain driven design. And so I I really tend to see David these two as parents of micro services in a way and that was the evolutionary aspect. But microservices and I have been doing microservice for a little over six years now, almost devoting my whole career to it at this point for the past six years, um I have also seen the revolutionary aspects of microservices. Um microservices has finally beat us over, we've been beaten over the head about having to pay attention to data. Yeah. Yeah. Yeah. Microservices was the very first architecture style that came out that required us to consider data as part of the architectural design. No other architecture style in existence has required this, is it a good idea? yeah, that's how you get an effective system. But is it required? No, we can still have this impedance mismatch these two camps of architects and data architects and they they somehow combine the poor developers try to glue them together. 

Microservices was revolutionary in this aspect. Um So that was really the first aspect it woke us up to say, hey, data matters in architecture, try to build a bounded context without data. And you can't um the the other aspect of revolutionary that I kind of saw that that was kind of the main one was really this data piece but also the other revolutionary aspect of microservices was this real bridging of collaboration. Finally, finally, David, we've been, we've been trying to collaborate, not communicate between each other. But when collaborate, working together on a cohesive system and develop that cohesive system and micro services requires this collaboration. without it things completely fall apart and that's where I really get excited. Um We as architects have to collaborate with developers or it won't work. We as architects have to collaborate with data architects and DB A s or it won't work, we have to collaborate with operations. Now, we never really had to before, you know, we talked to them, communicated but not collaborated. And, and that really was the second aspect of this revolutionary aspect of the, the understanding of the intimacy of data and how it connects to architecture. And really this this core piece about collaboration and really building that Dev Ops was a neat idea. I, I started experimenting with Dev Ops way back when I was an employee with IBM. And this goes back into, gosh, the, the late nineties, early two thousands. Um it was just a word, it was a thought. Um we experimented with it but um microservice requires it. And so it was really a catalyst for these things. Revo revolution

David Brown

So if it's a revolution, it's going to cause a lot of disruption. So what are the major hurdles for a company. What are the challenges that they're facing when they're implementing microservice?

Mark Richards

David? What a great analogy because you're right that any revolution there is a lot of pain. There's a lot of collateral damage in any revolution. There's a lot of upset. Um boy. And after six years so far and counting of using microservices, I don't think there's enough time in the week to actually go through all of the challenges and hurdles of microservices. But to your point though, there are some real key ones, David, that I can really point out are things that are cautionary tales for anybody listening to this podcast thinking about micro services or doing it will either be nodding their head or saying,, didn't think of that or even considering microservices going. Um Hold on a little bit and really that first one is the first hurdle that I usually see is all about service granularity. 

How big should a service be? And this is really, really hard stuff. Um Should our payment service that we accept five different payment types for, for our processing? Should that be one service or five? I should notification to our customers, which we do through S MS texting email and even postal letters. Should that be one service or three? And these are the challenges that cause teams to just well have um let's call it um heated debates or? Well, I was trying to think of a friendlier way of saying heated debate, um lively conversations, let's put it that way. Service granularity is hard. Um The other is really breaking apart of data. This is perhaps um aside from service granularity, probably the biggest challenge, at least in my experience at client sites that I've been been at and, and helping. It's, it's really dealing with data and breaking apart data, decomposing data is extremely difficult. Data is interrelated. We've got foreign keys, we've got relationships between data and we, when we start forming bounded context, it sounds easy and it looks good on paper. So you actually try to do it. And I was like www, wait a minute, I need that data now. But you're saying I can't go query that table. No, you cannot query that table. 

Well, then how do I get my data? That really is the second piece. Um The other that um it's interesting, especially when we talk about serverless as part of micro services is um is what I'll call. Well, deployment hell. We used to have DLL hell back in the, the, the sea days. And then, and then of course we had Jar Hell when Java came out. Well, now we have in microservices deployment hell all these services dependent on one another and hundreds of them. And yes, we have operational automation to help us with this. But boy, we knock one service out and all of a sudden things start breaking that we didn't even know was tied to it through workflows. And so, yeah, the, the deployments, um, although it rates really high in micro services, um if not done correctly, um can be your worst nightmare. Dante's ninth level of hell is basically microservice is done wrong and, and that, well, and then, boy, like I said, I can go on with, you know, managing workflows. This is something that's a huge struggle in microservices. service dependencies is where microservice is really starts to fall apart. And um these are some of the real major hurdles and challenges. Um Fortunately, there are solutions to all of these. Um Yeah,

David Brown

I mean, sort of, you know, managed services for deployment and stuff like that is, is, is making it easier and auto remedia, auto remediation by those public services and manage services is making that process easier, you know, if, if you were a public cloud provider, but this, this interesting aspect of the interrelationship of data and the bound of context and, and it's easier said than done, right? So when you start whether you're designing a new app or breaking down a monolithic app, like you said, there's lots of relationships and sometimes when we've been building microservices ourselves, it's like, you know, I don't want to call that data remotely. It's just, there's gonna be performance issues, there's gonna be data integrity issues, there's gonna be all this sort of stuff. 

And so, um let's bundle it into the service, you know. And, ok, well, are we starting to build a monolithic app now then? Are we, are we breaking the, you know, the concept of a microservice itself? It's a real challenge. Is, is there an easy answer to it?

Mark Richards

No, this is the problem David. And, and your observation is absolutely correct. II, I can't tell you and won't tell you. Definitely the clients and the number of clients that I have been in over the past six years that effectively have created a large distributed big ball of mud or what some of my clients call, we have a distributed monolith and I will step back and say, wait a minute, let me guess you're using micro services. And it's like, how do you know? And so, you know, it's so funny you say that David because all these, these, these new buzzwords are coming out. I mean, a distributed monolith is an oxymoron, but it really does describe the trouble you can get into with micro services. Um There are, there are solutions to these hurdles and problems.

 A lot of those David are um how I ended up learning these, which was battle tested, it was being in the trenches and saying whoops um that was not the right move. Um It was all those lessons learned and doing things the wrong way and saying, yikes um that was not good, was it? No, let's do it this way now. And I, I really started recording all those things down, which is where I developed all of these anti patterns and pitfalls that I evangelized and, and kind of being in um well in conferences and trainings and stuff. It allows me the opportunity to be able to share all of those lessons learned about every single one of those hurdles I mentioned and techniques for overcoming those. Um And so it was,

David Brown

Can you share some of the weaknesses of some of the weaknesses you've discovered in micro services?

Mark Richards

Yeah. boy weaknesses. Well, actually, we've, we've touched on some of them just in the hurdles itself. Um But, you know, there's there's two that are, are really come to mind in, in my opinion, at the very forefront of those, the first is performance and you might be surprised by that answer. Um But it, in fact, has been my experience repeatedly that most micro services implementations will in fact have less performance or worse performance than your original monolithic application or if you were to from a green field, go to a monolith. And actually,

David Brown

There's not many people expect, not many people expect that outcome.

Mark Richards

You're right, David. And, and this is one of those gotchas that you end up with when you start. Um Not with maybe three or four services. But once you really start in earnest, developing dozens to hundreds to even thousands of services, um, there's three reasons why. Um,, and, and this is not just an opinion., this is an observation that I have seen in the field,, for the past six years., there's three reasons. Um, one is network latency. Um, we tend to forget that when we're invoking another service,, that's necessarily a remote service and we are going through the network and there is network latency that we didn't have before. Number two is security latency because if I take my monolithic application and blow it up or even start a Greenfield and we've got 70 8200 services. Well, when I start calling other services, I necessarily hopefully need to secure those end points because the service is a sly deployed or a separately deployed function, a single purpose function in micro services. It's separately deployed, who can access that, who can access the wallet service containing all of your PC I information. And so consequently, when I start hopping around services to fulfill a request, not only do I have network latency, but also now I may have to reauthorize you for every one of those hops. At least I have to verify the security token I'm passing into the header. 

And interestingly enough, there is a third reason that's hidden away in the bowels of micro services and that is data latency and that's, and that's data latency. Um Let's say I wanna to retrieve all customer information. Well, in the monolith, that was an SQL join across seven tables. Yeah, that's what we did. There was pretty fast, about 7 to 8 milliseconds. Now I need to join and choreograph seven different micro services, but each one has its own data in its own query. So I have now taken something that was very effective in the database and SQL join. And now I have to make seven database calls. Now, hopefully I can do this in parallel which helps mitigate some of the data latency. But a lot of times I can't, I have to do a workflow. which means that all three of those point to the fact that I may be adding anywhere from 500 to 1500 milliseconds onto every request. Um So that's, that's why perform again. 

It sounds surprising, doesn't, it's like wait a minute, no, making things smaller should be faster. And it's like, well, if you're calling a single service from a single U I, great, how many applications do that? Not many, not many. But you know the other, the other weakness of microservices is um cost and complexity. The two big CS um they're expensive and I think um I make the joke David, by the way that I usually say um, so you're using microservices, I can infer a couple of things about your environment. Yeah. What's that? Well, you have a lot of cost overruns and high attrition. It's like how did you know?

David Brown

Alright, so I don't want to scare people away from micro services like you said they, you know, it is a revolution and the people are doing it for a reason. So what are some of the reasons where, where are they a good?

Mark Richards

So there's so many many good reasons why this is on the hype curve. Um super high levels of scalability, um agility. One of the things that is near and dear to my heart is architectural change. architecting for change. I've been touting this for in, in conferences in various talks. my gosh, David for almost 10 or 12 years about agile architecture and this was before microservices even existed and it was hard, it was hard talking about how to make architecture agile because architecture does change. A microservice has given us this five stars for agility. Um agility being defined as the ability to respond quickly to change. 

Let's face it. Why is microservices so incredibly popular? It's because businesses have to change on a dime. It's the only way some businesses can remain competitive. They have to change fast. Businesses are learning how to change business processes quickly, but then it hits it and everything stalls out for months, years. Crickets chirping and so that's one of the first things microservices has really given us is that agility that ability to respond quickly to change daily deployments. David, this is awesome stuff. I can make a change and have it in production in a particular microservice, a single purpose function within an hour in prod from problem bug fixes new features faster than our competition. Um That's where microservices shines levels of fault tolerance done, right? Is fantastic. Users suddenly say, wow, these, these systems just don't fail, do they like? yeah, they're failing all the time, but you just don't notice it and scalability at a function level. 

When we talk about evolutionary architecture, um the ability to evolve the architecture as our companies evolve. This has the highest rating out of any architecture style for the evolutionary aspects of architecture. If I need to start um evolving the architecture to add more functionality, do different things that our company is doing, taking a different direction. David, this is a matter of dropping in new micro services or adopting existing ones that are needed. A man try to turn a monolith. That's like a huge 800 ft destroyer. It's, it's, it's gonna take four miles to turn that ship around. Now, we were talking a little tiny speedboat and so those are some of the main ones. 

Kevin Montalbo

Mark, What's your take on where microservices are going? What's next for this architecture?

Mark Richards

Yeah, I and this, I get excited about this. I haven't been excited yet but this, I get excited about it. So, where is it going? Um, basically in a nutshell and then I'll kind of expand on this, but in a nutshell, um, companies jumped on the bandwagon of microservices and, and company a is doing it so we should be doing it., I'd like you to, we're gonna do all of our, all of our stuff in microservices or service. And the excitement about where it's going is understanding where we've been and what I am seeing in the industry as a whole. And these are companies that I work with companies. I'm in trainings or conferences that I do. 

What I'm seeing is a level of maturity starting to rise in microservice is not only about the hurdles that we discussed in this podcast, um but also when to use it, when not to use it to really have, I guess I would say David kind of a respect for microservices understanding it is complex and it's not a silver bullet and maybe we shouldn't use it. And this gets me excited because I see that learning happening as teams and companies are getting and gaining these lessons learned. So where I see microservice is really going is finally starting to reach that maturity curve where yeah, it's been a great experiment and some companies still are in the middle of that experiment unfortunately. 

But we're learning a lot and we're learning in my opinion to be cautious, we're learning instead of jumping on that bandwagon and immediately embracing microservices, whether it be personal experience or whether it be the experiences of others like myself that evangelize some of the lessons learned, it's taking a step back and taking a more cautious approach to saying um should we be using microservices the other place, David that I really see microservices going is more towards hybrid architectures. I think the other thing that we have learned over the course of I'll say six years or seven years is quite frankly, not every portion of an application has to be microservices conform hybrids. We can have portions of our applications embracing the micro services architecture and portions being mini monoliths or even service based architecture. 

And this awareness I am starting to see at my client sites and this excites me because it's like, I see half my work's already been done here because you already are seeing some of this stuff that I was about to evangelize for you. So iii I guess I would summarize it in the sense of seeing it be a cautious approach um with an understanding of hybrid architectures um especially when it comes to that data piece, David, this is this is the part where not all data can be broken apart and that means necessarily a lot of times we don't do microservices, but rather a service based architecture approach.

David Brown

Mhm It's, it's you've seen this out of people's own experience. You're talking about the, you know, the battle scars that people are actually, as you say, am maturing and, and are realizing that, that they, they can have this hybrid approach and there are different approaches to the deployment models.

Mark Richards

Yeah, exactly. And also David, the tools definitely are maturing. Um Again, what I usually do with this step is also evangelize and give everybody who's listening. The words of advice, the tools are making microservices and frameworks a lot easier, a lot easier to manage, a lot easier to deploy and also to even create. But the devil's in the details and there's a lot of hidden aspects that are abstracted from us. Now in a lot of the frameworks and tools and the cautionary tale is really understanding, embracing those. But understanding of those abstractions um when we talk about the ease of auto scaling elasticity, which used to take me four months to architect is a switch that I set in Kubernetes. 

Now, I mean, how easy is that? Well, if I'm using an in memory data cache, for example, or an in memory data grid through replicated caching and I've got a 500 KB cache and I all of a sudden spin up 40 instances. Um guess what happens? I run out of memory very quickly. So that's what I mean about the devil in the details. It's I appreciate the tooling and applaud the frameworks and the tooling that's happening with microservices to actually um have it be feasible for most companies. But it still requires that level of maturity to understand the knobs and dials and what's impacted by auto scaling. For example, you know,

Kevin Montalbo

You mentioned that you enjoy conferences and I'm sure that you're missing them a lot nowadays. Where can people find more about you and what you do?

Mark Richards

Yeah. Well, the single place where everybody can go, the nice thing is my website developer to architect.com and that's to so the movement from think of I'm a developer, I want to be an architect developer to architect. And this is a website full of resources. Every other Monday, David, I do something called software architecture. Monday, which is a free video for 10 minutes. I, I usually keep the videos at 10 minutes of some aspect of software architecture and these are free. You don't even need to sign up, you just watch them. And I've already this week actually last weekend I just published lesson 105. So there's 100 and 5, 10 minute videos out there about some aspect of architecture. 

The other thing is the upcoming events page um on my menu item there. You can see upcoming events. These are the places where I'm actually doing still um public training and some public conferences. Still. I'll tell you though, David, I do really, really, really miss the in person experience. It's hitting me hard. It, it started hitting me hard late October and it's hitting me hard. Now. I miss, I miss the interactions. I miss the feedback. I miss the seeing people's expressions and collaborating on this stuff. 

David Brown

So, I mean, I don't miss the travel, you know, happy to not getting on a plane every second week. But yeah, there's nothing like that face to face contact is there, Mark. It's been a pleasure to have you on the podcast. Thank you very much such so many insights there. It's been a pleasure. Thank you again.

Mark Richards: All right. And thank you so much David and also Kevin for for having me on coding, coding over cocktails. really psyched about this. It's been so much fun talking with you about these ideas. Um This is important stuff to get out to everybody. So I applaud you for doing this. Thank you so much for having me.

David Brown

Absolutely, our pleasure.

Kevin Montalbo

All right. That's a wrap for this round of cocktails to our listeners. What did you think of this podcast episode? Let us know in the comments section from the podcast platform you're listening to. Also, please visit our website at www.torocloud.com for a transcript of this episode as well. As our blogs and our products. We're also on social media, Facebook, LinkedIn, Youtube, Twitter and Instagram, talk to us there because we listen, just look for Toro Cloud again. Thank you very much for listening to us today. On behalf of the entire team here at Toro Cloud. This has been Kevin Montalbo for coding over cocktails. Cheers.