Responsible Microservices, with Nate Schutta

Episode 177 · 46:51 · SRT · archive.org · all Tanzu Talk

Are you a zucchini bread guy? I love zucchini bread. My wife makes an awesome zucchini bread and she puts a chocolate chips in it, which I think makes virtually almost anything good. Yeah. You know, I, I hadn't really thought to start that way, but let's just, let's just jump right into it because I think my, uh, my son came home with these giant zucchinis. Like they were, they were like inhumanly large, two of them. And, um, if I, if I had the wherewithal, I would put a picture of it up here, but I don't. Uh, and we'll do it in post. You know, what, what happened is, uh, you know, we rent a house. So my wife had to, uh, do a little bit of, uh, uh, hand grading to get it graded down. And then she was able to, uh, put that into a bread, which was very delicious. I enjoyed it quite a bit. So yeah, I, I hadn't had zucchini bread in a while. My grandma used to make banana nut bread all the time. Oh yeah. It's good. Fresh out of the oven with like, oh yes. Equal parts butter and a fresh made bread is. Right. A hundred percent. Enjoy the most. Yeah. Yeah. So it's all, it's all, it's a buttery delivery vehicle for some people. Well, I wanted to have you here on, uh, one of our Tanzu talk streaming live, whatever episodes to talk about. Now you can't see this because, but I'm using the magic of streaming. I have just put a picture of your book up over our heads. Oh, fantastic. Yeah. Now my wife would call it a pamphlet. A pamphlet. You can see the previous pamphlet there in purple. And, uh, yeah, it is. That's right. Yeah. Yeah. It is over my shoulder. Yep. So now you got responsible microservices. Now, like a good, good, uh, host. I read this hurriedly this morning before we were talking, which I think is the proper, uh, rate. But it's a pamphlet, so it's short. You can get it done in a short amount of time. And so, so tell me, Nate, how would you describe what's going on with this book? What's, what are you, what are you trying to encapsulate here? Well, so this is a, a prose variant of a talk that I've been giving for the last year, year and a half on sort of the principles that we use with clients on should that be a microservice.

Now, those of you who've been paying attention know that that started as a blog post back in the day and, you know, it occurred to me that putting this into a nice handy PDF would be very useful for folks. And then, you know, it makes people happy that they can market behind it. But yeah, it's just, there's so much chatter about how to do microservices. There's not enough about when should we do microservices. And, you know, you and I've talked about this. One of my all time favorite tweets actually is yours about, you know, year one. Oh my God, this technology is amazing. You know, year two, actually, this is really hard. You know, year three, you should probably never use this technology. Year four, oh, look, something shiny and new. And microservices are very much part of that. You know, we've seen a lot of people jump on that bandwagon because some tech companies are doing this and everybody's got to do it. And then people are going, wow, actually, this is kind of difficult. And so this is really the kind of advice that we try to give people on when does this make sense? And I would say more importantly, when does it not make sense? You know, not everything needs to be a microservice. And I think the other thing that comes through that's nice is there's a, well, let me ask you if this is intentional, but I almost feel like it's a, here's the current thinking about running microservices as well, right? Like there's, there's a, I was thinking, I don't know, I don't keep up with the microservices trades like I used to. So I don't, you know, uh, follow them, but like, I don't often see, uh, SRE and microservice mentioned in the same area. Right. And I, which is unfortunate. Is that, am I just behind the times of those things that commonly are the SRE people talking to the microservice people and back and forth what's going on? I hope so. I mean, I hope so, because if you're going to have these highly dynamic environments that all have services coming in and out of existence and changing rapidly, there's a whole lot of stuff you need to make that work or else it's just going to be painful. And I do think, honestly, that's part of the struggle. A lot of people have with microservices is they're so focused on, oh, look, I, I made some APIs and then they didn't think about the fact that, well, how do we monitor this?

And how do we, do we have alerting in place? You know, what, what kind of an environment is this running in? Can we support that environment? You know, and that's a huge part of the challenge that comes along with this. Do we have the automation in place so that when I need to make a change, I can get that change into production quickly and safely? You know, it's, it's, it's always making sure we have both of those pieces together. And, and, you know, that's, that's part of the whole challenge here is making people see the bigger picture beyond just, oh, cool. Now I can put microservices on my resume. Yeah. Yeah. Yeah. And, and, and, you know, in that area that, that, as I was reading through, so you, you get into like, uh, you know, you visit all the old favorites, you got the circuit breakers and, uh, you know, other things like that. And, and, you know, even, I think, I think in, there might've been another place, but in one of the longer, but rare passages of code in the book, not a lot of code in there. Lots of thinking, which is nice. So, you know, it's boxes and diagrams, but it's just arrows and boxes and all that fun stuff. Exactly. And so, uh, there is basically some, uh, some code of how to do like a circuit breaker in, in, uh, in spring stuff. And I was thinking, and then, and then you go on to talk about how like, uh, uh, service meshes, I think you managed to only say service mesh once in the book because I searched for mesh, which was fun. Yes. Yeah. And that's, I think Rohit's fault that I had to put in there once. So we'll blame Rohit for that one. And so I was thinking like with all the talk of, uh, you know, Istio and service meshes and Kubernetes and all this stuff, like, when do you put a circuit breaker in your code versus just in like a sidecar or whatever, right? Like, and because, and, and, you know, let me ask the question and then just make one more statement. It seems like not that this has ever happened in programming before, but we're like, unless, unless we kind of don't get a handle on it sometime in the next five years, we're going to be right back in the position where every single layer duplicates every single pattern and you're relying on some overlay thing to basically write a bunch of configuration that goes sets all of those things up and down the pattern so that they're, uh, synchronized.

Well, I mean, I, I, I, I don't think you're wrong, right? I mean, we, we do that a lot in this industry. And I think part of it is we, we don't know where all this stuff is necessary or where it adds value until we've actually tried it and used it, experimented with it. And then we start to figure this stuff out. And, you know, I talk about this in sort of my, my thinking architecturally material, but trial and error is how we learn as a species. And you think about so much of what we do in software software has been what a human generation at this point, maybe compare that with other stuff we've been doing for millennia and we still screw some of that stuff up. So I think we need to be a little forgiving of ourselves in software that we don't have all the answers yet because we haven't been doing this very long. And unlike, you know, building houses where we're using the same materials we've used for hundreds, if not thousands of years, we're using stuff that we invented earlier this week. And then people are shocked that we don't know exactly how this is all going to turn out. And so I think some of that's natural, you know, it's like, oh, well, geez, we tried putting a load balancing here and that didn't work. Well, let's try putting load balancing over here. Oh, Hey, there we go. You know, so we'll figure this out as we progress and we'll get bigger and bigger abstractions. And there'll be more Lego blocks that we can piece together. You know, I think we lose sight of some of those Lego blocks we already have, you know, think about the original Gang of Four Patterns book. How many of those patterns are just baked into the languages and frameworks that you use every day? You know, it's, it's become just the underlying undergirding part of the tools that we use. And you're going to see the same thing as we progress forward, you know, it's like, oh, wow, you know, these distributed architectures demand certain things from us. Well, let's just sort of encapsulate that and code that into this framework or language or however you want to phrase it. And now it's just there. You don't have to think about it anymore. You know, to me, that's, that's a huge win. That's, that's what we'd like to see. Yeah. Yeah. So, so it's sort of open and flexible at the moment. You might, you might want to put your, you might want to put your circuit breakers in some Kubernetes thing, or you might want to put it over here in, in your spring thing,

or it, you know, no one's quite sure, you know, that it's, it seems like I haven't done the exercise, but there are some obvious sort of like this belongs in the system or the platform versus this belongs in the application code that you can start to draw out. But as always, it's fun to find those things on the, on the edge, on the margins. Or where it blurs, you know, where the distinction isn't clear cut, you know, or it isn't obvious. Should it be here or there? Yeah. I mean, you and I've talked about this before, but the, the one answer that I can give to almost every question is it depends. And I think that's, what's challenging, you know, especially when I think about this from an architectural standpoint as an architect, you know, the friend of mine likes to say that, that architecting or being an architect, everyone would phrase it. It's the stuff you can't Google, you know, cause by the time the questions get to that sort of architect area, there isn't an obvious answer or else already would have been answered. Right. You know, so if this was just an easy design decision, well, there's no reason to involve architect. If it was already solvable again, no reason to involve architects. So by definition, these are harder questions to answer and we got to kind of grind through the possibilities and hopefully we're making good decisions. You know, I mean, we'll know in a year or two, I guess, and we'll see what happens. So maybe architects do things that haven't been turned into frameworks yet. Yeah. That's another way of thinking about it. A couple of friends of mine are... It's parts of programming that hasn't been automated yet. That's the... Yeah. Well, it's like what I said, my friend Neil likes to call it the things that you can't Google. And there's a lot to be said for that. You know, it's the hard parts in a lot of ways. Yes. That's a constantly evolving thing. You know, there was a time before Nygaard coined the whole circuit breaker thing. We didn't, you know, have a circuit breaker. You know, now everyone's like, well, of course we need a circuit breaker. So it's fascinating how that stuff changes. Yeah. You know, I hadn't looked at the circuit breaker thing in a while. And I think that, I think one of the fun things about it is, is the idea that a piece of code should know when it's in a good state or not, which is like, it's simple, a simple

idea, but I don't think that's necessarily something that is part of how most programmers think about writing their code that like, like it should be like self, your, your chunk of code should be self-aware of itself and like, know if it's good or not. It's, it's more like if an error occurs, just like freak out. That tends to be the, uh, the mode. Like just, it's sort of like the, uh, the, the, like, you know, the seven-year-old mode of operating if, if, if everything's fine, you just operate. If anything goes wrong, just sit down and cry and yell really loud. And then that's basically code in a nutshell, Coté, as usual, you've, you've captured and given us a vision that instead, instead of what the parents of the world would like, which is like, if you haven't found the TV remote yet, use your words, you need to keep looking because sitting here and crying that you haven't found it is not going to cause the TV remote to be found. You must. Is that a universal thing? Because, because I've got a 13 year old and I cannot tell you how many times my, like he'll ask, where is something? And I, or my wife will basically say, well, where did you look? You know, he said, I looked everywhere. And then we'll literally walk to right where it is. Like you mean this, this right here, that's on the table. That's in plain sight. I guess that's, that's kids. Yeah. No, I think it, I think it is universal and it is universe. The universal reply to that is universally unhelpful. Like I did, I did this the other night. I need to figure out how to share pictures here. Cause I could show these pictures, but like, I, uh, uh, I'd asked my son to find a towel for whatever reasons. And then, and then my wife was putting him to bed and I went downstairs to close some doors and I saw a towel on the floor. That was his towel. And he had told me he had looked in that exact spot. So I took a picture of it and then I went upstairs and I showed it to him and, and the, the pedantic educational lesson that my son learned from this zero, just that dad's right. Like there was no dad will get the towel. If I miss it, it felt like a real enterprise architect moment where I was sort of absolutely

sort of absolutely showing someone that something was done, uh, in, in a way that I thought was, uh, insufficient or not good. I had a very similar experience last night. I was doing laundry and I asked my son specifically, please get me all of your soccer stuff. And so he brings up his laundry and he says, yeah, I put that on top. And I'm looking, I'm like, well, where's, where's your socks? Where's your, you know, your compression shorts. Oh, those are, those are still downstairs. And I'm like, but did, did you catch the part where I specifically said not, not like five hours ago, not three days ago, but like literally like 10 minutes ago, please go do this. And then, you know, it's, it's joy. Although I will say this much, my wife and I went for a bike ride yesterday morning and we were, we were, we planned on starting our sheets before we left, but we forgot. But my wife left our son a note saying, Hey, we're out on a bike ride. Please take the sheets out of the washing machine and put them in the dryer. He did that, but of course the sheets hadn't actually been washed. And so I asked him, did you notice the sheets weren't wet? And he said, oh, no, no, I didn't. So I don't know. My wife would call that a boy look. So, so I think this is, this is a good way to, to kind of, to kind of mesh these two worlds together, right? Cause what we're talking about here is governance, right? Yes. Governance and guidance. Now I once, I once heard from a enterprise architect that they wanted to move from policing to partnering now, Ooh, I like that in the area of parenting, I don't know, like it's only every now and then where you're thought you're, you're set, you're supposed to think of partnering with your children often, you know, that kind of comes about and then everyone realizes like, no, they need to be parented, not partnered. Right. Right. Now there's another concept I want to throw into the, the, the table smoothie here. And that is this, this concept called like servant leadership. Right. And, and I, I, I think there's a little bit of a whiff in your book, if that's a word that still is okay to use of like servant architecture ship, you know, like be where like, you're like, you know, if I can read a little bit, I'm trying, I'm trying to be like cool podcast

interviewers and read passages that people have written to them. So this is the second time I've done it. We'll see how it goes. But somehow somewhere on page 50, you're like, you, you want to provide adequate guidance to your teams to help them make the right technology choices. And I love this decision trees are invaluable. Now decision trees are one of these things. And, and you go on to talk about how the, the genius of a decision tree is it limits options, right? Which I think that's a good genius counter move is to realize if someone has given you a set of decisions, decision one, decision two, or decision three, you should choose decision five, right? You should always just like go outside of what they've laid out for you. But anyways, this made me start thinking like of that policing partnering thing where I think what we'd sort of like from enterprise architects nowadays is for them to be helpful rather than well, to, to show up and offer their help rather than show up and say, this is how you must do it right instead of, instead of drawing the lines of where you have to operate and how the tools you need to use the governance. I don't know. Is there this notion now that you're sort of there to facilitate the teams doing the right thing instead? So, I mean, to me, this is just a reality that as an architect these days, you're spread so thin. There's no possible way you can be involved in every single decision. It's just impossible. And, and to be clear, I, I, as an architect, I don't want to be the single point of failure. I don't want to be this, this bottleneck on a team's progress. You know, that's, that's not good either. The challenge of course, is how do we create that environment within which our teams can thrive and make, you know, again, these good decisions. You know, you want to make the right decision, the easy decision, you know, give them that guidance. And so the decision trees for me actually grew out of my, my previous job, previous company. I was sort of like cloud architect guy.

And as we were bringing in all these new technologies, as we're evolving to the cloud, you know, one of our senior architects came to me and said, you know, Nate, we're bringing in all this new tech, which is great. We need it. That's awesome. But we really need to give teams help figuring out which of these three options should I use? You know, they're all three will work. Which one is the right one for me in this situation? You know, and we recognize that those first six to 10 apps that are going to go through your cloud migration, they're going to have a lot of attention. You're going to have, you know, architects are going to be hovering around it. You're going to put your senior team on it. You're going to put your best developers on. It's got a lot of management attention, but then you got to open up the floodgates to the whole universe of your development core. And they're not going to have that same level of handholding, that same level of, let's make sure we've got our, you know, we've got our business partners involved. We've got our technical partners involved. So what do you do to make sure that they don't, you know, take the circular saw and slice off their hand? And we try to give them as much guidance as humanly possible so that they can try to navigate these waters. Now, the other part of this that I think it's lost sometimes is it's an efficiency thing. You know, so if I'm starting on a project and I have the universe of options in front of me, well, now analysis paralysis kicks in. I'm beach balling because I'm like, oh, I could do this. I could do that. I could do this. Like, I don't know what to do. So you give people some guidelines, guideposts, North Star, whatever you want to call it so that they can go, all right, well, we got one of these and one of these. So now I don't have to worry about spending tons and tons of mental energy figuring out which of 17 different databases I should use. It's going to be this one. Okay, cool. Now I can move to solving business problems. The things that our business partners want us to worry about. You know, they don't really care about whether we use this database or that database. You know, they just want stuff to work. So let's try to, you know, reduce mental energy to that. It's, to a certain extent, it's that notion of, well, I just wear the same thing every day because I don't have to think about what I'm wearing. You know, it's that Steve Jobsian, I just wear a black turtleneck kind of a thing. You have a limited amount of decision energy.

You know, we all know how that feels at the end of the day. You're like, what should we have for dinner? It's like, I don't know. I'm out of, I'm out of energy. I don't care. You know, just order pizza or whatever and be done with it. So, so to me, I think it's an efficiency thing as well to help our teams free up that energy to focus on things that, that are frankly more important, you know, and a lot of this, we can sort of put it into a set of, well, if this, then that kind of conversations. So then this touches on another thing, which I thought was interesting that you bring up in the book, which is like the, uh, uh, the dream of polygot programming. And I think, I think you, you link to some, uh, uh, 2006 little snippet on this about how that would be great. Right. And, you know, I, I think one of the other things they tell the little programmers is, uh, you know. You were so young then. Yeah. One of the things they always tell them is use the right tool for the, for the job. Right. Absolutely. Which, which I think, you know, maybe this is a discussion we should bracket, but I think that is usually false, but in, in, in a very pick option five kind of way where like, you know, the, it's more about the choice than of course you should use the right thing for the, uh, the job, but sometimes it's better to choose the longterm, more efficient and sustainable thing, even if it's not great. Right. Like, you know, if we were, uh, if it was going way back, if it was like 2000, if it was 1999 and I was suggesting using like XML for configuration on windows instead of an I and I file, like even if XML was far superior, cause I could use like XPath and XSLTs to transform it between a Linux box and, uh, whatever, like it would just, you just use an I and I file on windows that that would anyways. Uh, but that's an example of like, you know, I was drawing out how an architecture draws these, an architect draws these fences and I, and the polyglot one is, is a interesting thought exercise, polyglot being that like, we can use whatever language is, makes sense, or we would like to, uh, for this instance, instead of just always having it be in Java or C sharp or

Perl or whatever. And so like, is it feasible to have like, let's say three programming languages on a project long-term? Like, it seems like, it seems like you're going to have JavaScript. So you got that. If you're going to have a web UI and then you're going to have some primary programming language. And like, it seems like maybe on one project, it's a good idea just to have one programming language, like long-term. I don't know. How has that evolved over time? No, I would agree with you there that, that in general, a given project, no, I mean, there's always exceptions, but a given project is going to have one primary server side language, whatever you've chosen, whether that's Java or JavaScript or C sharp or closure, whatever it makes you happy, whatever it works. There might be certain extenuating circumstances where, well, we do 90% of our coding in Java, but we have this small subset of problems that really has to be done in something else. Oh, right. And maybe like a parser or something. And so you've got some weird parser language. Yeah. Yeah. Or if we're doing data science-y stuff, you know, that tends to not be, you know, one of the quote unquote mainstream-y languages, you know, and that's perfectly reasonable. You know, now this again is where there needs to be guidance from architecture, you know, to say, this is when this is appropriate. This is when this isn't appropriate. And I think it's perfectly reasonable to sort of have a stance as an organization. These are our three primary languages. Choose one and prosper. Now, if you really want something outside of those three, you can come talk to us. And if you have a compelling case, we'll consider it. But in general, these are our primary languages, you know, and that's where we want you to sort of stay. Now, within an organization of any size, of course, you're going to have multiple primary languages.

I just, I can't envision a world where that's not the case. And, you know, even if you are primarily a Java shop, you will at some point acquire a company that uses JavaScript or C-sharp or something, or you will be acquired by a company that uses something else. You know, so there's this idea that we're going to be one and only one. I just, I don't think that's practical today. You know, prove me wrong, I guess, but that's certainly been my experience that they're at a certain size, you're definitely going to have more than one answer. to what it's all about. Yeah. And it definitely seems like within a portfolio or an organization, a group. Well, I don't know, I shouldn't, I'll state the statement in the form of a question, as it were. But like, so, so like on one application, you want to have some kind of like primary language stuff, probably. Yeah. And then let's say you've got like a portfolio of like 500 applications now putting aside like what ends up happening and accretion and all that, like kind of what's the ideal state you want to shoot for? Are you just like use whatever language makes sense for a project? Or would you rather have just like one, a fewer amount of languages that you're using? Personally, I'm going to lean towards fewer because the more choices you have, the more ways of doing things there are, the harder it is to support, the more paths you have to production, the more variability you add into the equation. And the hard part here, I think, is finding where is that Goldilocks number of options? Is it three? Is it five? It's not unlimited. And what I do think is so interesting, fascinating, painful about sort of this microservice, highly distributed application environment, it does enable us to potentially have 15 different stacks. That doesn't mean it's a good idea. You know, and so again, we have to worry about analysis paralysis. But the bigger concern I have here is can you stay current on all of those stacks?

Do you have a way of getting all of that to production in a way that's repeatable and safe? How many different libraries do you need for that? How many monitoring solutions do you need for that? You know, what happens when you need to move people around your organization? How do you hire for something like that? Well, part of your company uses this, part of your company uses that, part of your company uses something no one's ever heard of. You know, and what's fascinating to me is I think almost every company has the Galapagos Island project. And usually what happens is some influential engineer finally convinces their management, please let me build this thing in esoteric technology stack, whatever that happens to be for that organization. And they build it and it's super cool and interesting. And then that person leaves. And now it's like, oh, nobody knows how to support the Galapagos Island project because that was just influential engineer and maybe two or three other people. And what do we do now? And it's like rock, paper, scissors to see who has to go into that code base. And so that, I think, is the other part we have to be very cognizant of as an organization that we want to avoid that wherever humanly possible. You know, you don't want to have that, especially if it's a key, important application and outside, oh, geez, you know, like 70% of our revenue runs through this thing that nobody really understands. Although, I don't know, maybe that's software in a nutshell right there. Well, you know, you raise up another interesting quote there. Like, so, you know, when you're talking with architects here and there, like, how do they run their, their, like, councils of governance nowadays, right? Like, like in the sense of some decision. Like, this review board. Yeah. Like, some decision was made that we're going to use these two programming languages, right? Because we don't want to, we're anti-Galapagos or whatever. That's, we're anti-archipelago to. Is that better? Is that, okay. Yeah, and, and, you know, it's just sort of like, I would assume part of what you want your architects to do, your enterprise architects, is to put, put safety measures in place that

help, like, de-risk your future and so forth and so on. So, someone would think, like, we should have a limited number of programming languages. So, I assume that means, like, they need to schedule a meeting and then they got to go to a meeting and someone has to cover that. And then there's a discussion on it and then they, like, decide on it and then they, you know, update, like, a SharePoint site or something. But, like, I mean, I'm making a jokey example of that. But, like, do you- You're not wrong. Like, how do you encounter that people, like- Sure. Do the, the, the act of governance, the motions of it that result in things happening outside of a whiteboard? So, I, I think, I mean, I, I want to believe we've gotten better at this because the traditional approach to governance was ineffectual and painful. You know, I think back in my career, how many of these, and there's various words that come in front of review board that I've seen, you know, the architecture review board, the change review board, the change review board, review board. I mean, just everything, right? Mysterious. Mysterious review board. And, and the thing that always stood out to me as I went through these processes is it would force me as the tech lead, the architect, to put in a lot of effort producing some kind of documentation. You know, there was always a template that had a bunch of stuff in it that made no sense. You weren't really sure how to do it. It didn't really apply, you know, but you had to put this together in various chapters and pages and documents. And then you'd have to submit that sometime weeks before your meeting. And, you know, it's all this pain of scheduling a meeting and get to the meeting. And then basically you'd read this documentation out loud to people who should have already read the documentation. And, and then seven people would ask the same question one right after each other because they weren't listening or paying attention. It was just like, what's the point of this? You don't know enough about my project to stop it or not. It's just a rubber stamp. What has ultimately happened, I think, in a lot of organizations is they've sort of distributed that better. And so I think about like open source software, right? You know, I worked at one company where we had a fairly stringent open source sort of

acceptance process. You know, you had to go through a bunch of paperwork and get on. Meeting and all this. And we eventually migrated that to, hey, listen, we've got an internal repository. That repository is going to be configured that as long as it's a benign license. So it's something that the lawyers have said we don't have a problem with. And there's no known security vulnerabilities. Go for it. You know, we're going to distribute that decision making out to the teams because the teams know best, or we hope they know best, what they need for their situation. Now, hopefully, they've got good senior leadership in place from a technical standpoint that they're not just randomly grabbing stuff and stitching it together, that they're putting some thought into it. You know, but at a certain stage, to bring in our parenting metaphor again, it's kind of the same as a parent. You got to sort of like trust that your kid's going to do the right thing most of the time, and if not, well, learning opportunity. You know, but this idea of trying to have it all being centralized just doesn't work today if we're trying to be responsive to changes in the marketplace, changes to our business. You know, how can I wait three months to go in front of a group of people who don't have the context when it's like, I need to make a decision by Thursday. Because if we can't hit by Thursday, the opportunity's lost, you know, and that's just a, I think, a reaction to the fact that things are moving more rapidly today. And, you know, you can't afford to sit around and wait and twiddle our thumbs while a group of people who just don't have any context now are going to make potentially an arbitrary decision. Yeah, yeah. You know, on my Software Defined Talk podcast, I interviewed Yana Werner, who works at Tesco Bank, and she wrote this paper with Barry O'Reilly. And this was the first time I read some text to someone when I was interviewing her. But she had this great passage that basically to reduce it was that your, or I should say they, that your cycle time, like, you know, your release time is determined by your meeting cadence time, right? So like the meeting cadence that the managers go through to approve things, basically, whatever,

that's the, that's the primary thing that like drives how fast you can do something or how slow you can do something. Sure. And so just as you were saying, right, like if you, if there is a, a cab, that's a change advisory. That's another thing. But, you know, if it's on a 30 day cycle, then you're going to be in a 30 day cycle. And I don't think that that's like a, it's sort of like maybe a cousin or a sibling of the old Conway thing, right? Like at some point it was established that we're going to do this every 30 days because that's when it needs to happen. But then as the years go by, it's more that like, we're going to do things every 30 days because that's when the meetings happen. Right. Which is a subtle, like a change between them. But yeah, I mean, that seems to be one of the primary problems with, with doing enterprise architecture now is finding out how to, I don't know, not get in the way and yet, and yet still, still do your job. Right. Right. Right. Like still bring the, uh, the value that you do, which is a thrilling. You're hinting at what I've said is like the most dangerous phrase you can say in an organization is that's how we've always done it. You know, and we all fall into that trap where it's like, well, but we've always done it that way. It's like, but why do you have to do it that way? Is, is that a requirement? Is that just an artifact of what just so turns out the first Thursday of the month was when somebody scheduled it five years ago and so that's now the cadence we're on? Like why? I don't know. Maybe they just, that was the time they had free on their calendar. It doesn't mean it's the right way to do it. And this is where, again, if we sort of harness that sort of agile idea of let's review, is it working or not? And if it's working, great, let's do more of it. Oh, it's not working? Great. Let's change it and try to figure out how we can make things better. Instead of just like continually pounding our head against the wall and saying, well, there's nothing we can do about this. Actually there is, you're, you're, you're in control of yourself. So if it's not working, change it and try something different. What's the worst thing that could possibly happen? You know, I, I will say though, a lot of organizations is certainly organizations I've been a part of, they're, they're much happier failing conventionally than potentially succeeding

radically. Because if I fail the way everyone else has failed, well, you know, better luck next time. You know, what are you going to do? That's what happens to projects. If you succeed radically, people are like, whoa, how'd you do that? But of course, if you fail radically, well, why didn't you just do it the way everyone else is doing it? Yeah. Because it would have failed just like those other projects failed, but well, you get fired because, you know, you failed radically instead of failing conventionally. Yes. Failing in exciting, helpful new ways. Yeah. You know, and again, that's how we learn though. And so that's the challenge there is, is being in an environment that can actually accept that and learn from that. That's the hard part. Yeah. Yeah. Yeah. It seems like that's, that's something, uh, you would expect to see from, from architects going forward is like, they're the, uh, the, the net, the maker of nets. I was going to say net weaver, but that might like give people some like SOA problems and memories, but, but, you know, they should be the ones who are kind of like making, uh, experimentation and moving that fast safe, not preventing it from happening. So the last, the last things I wanted to ask about, uh, or the last thing is our, is our old friend, the monolith. Now I I'm starting to build up long-term over the decades, this category of technology discussion in my head, which is like, which is like, I think it happens in three acts. There's like this, this new thing is awesome and cool. It's kind of like you were saying, uh, earlier that I've mentioned this, it's awesome and cool and, and we should totally do it and everyone should run off and do it. And then, and then there's, there's this, this, uh, this drawback where it's like, whoa, maybe everyone should not go off and do it. Right. Like everyone should be using it, but no one should know about it. This is, we'll call this the word we like to use nowadays is it should be boring, right? Like it should be ubiquitous. It should be used everywhere, but no one should be using it directly. Kind of like indoor plumbing, indoor plumbing is boring, right? Like no one, unless you're a professional, don't mess with indoor plumbing, just benefit

from interfacing with it. Right. Yep. So we want things to be boring. And then we get to this third thing where there it's, we've kind of whipsawed too far into don't worry about it. And it's just like, I don't know, use whatever's right. Right. Like you super useful advice. Just do the right thing. Use what's appropriate. And, and I, and when I was reading through your book, I was almost, I was reminded of like the monolith is almost in this area where. So, so I forget when microservices came about, it was around the time when I joined Pivotal in like 2014 or 2015, right? That was when there was, that was in Martin Fowler had that picture of you must be tall to ride this ride, which like, I think it was still probably in every single presentation about microservices. Right. And it really struck me at the time that any microservices talk you would go see in 2015, 2016, the first thing they would tell you is very much so like Kubernetes is that you should probably not be doing this. Right. Please don't leave for the next 45 minutes. Right. It's just like, I don't, it was absurd. And then, and then slowly things come in and there was, there was many sort of long things of like monoliths are great. If you need to use them, you should probably start with that. And so, so I ask you, my coworker, Nate, like, come on, shouldn't people just not do monoliths? I mean, I feel, I feel like, I feel like there's this layup that always happens. Like monoliths are great. You should stick with those. And we're never going to talk about them again. It's like, and to put it another way, I was thinking like, I have not seen any good or interesting or any presentations about successful patterns for monoliths. Like no one covers that anymore. There's no new monolith frameworks. There's no like, here's how to like SRE or monolith. It's all, the only thing people talk about is microservices. And so the sense that I get is that maybe we're just trying to be too nice and we should just be like, don't do monoliths, but like, I don't want to monolith shame you.

Like, I don't, I don't know what's going on there. Well, maybe it's, it's to back to your plumbing thing. We don't talk about it in our plumbing anymore either. We talk about home automation because home automation is the cool new hotness. And I want to be able to like clap and then my lights turn on and I want to say a movie and my toilet flushes. Yeah. Although I guess with, with the, the toilet paper as currency that we seem to do living, I don't, is, is toilet paper hard to get in, in your side of the planet? Pretty straightforward. I think it's finally got to the point now in the States where it's all sort of balanced itself out again. But, you know, for a while there, like bidet sales were through the roof because can't control the paper. Let's put it in a bidet now. So maybe, maybe internal plumbing got really exciting there for a brief period of time. So to your point, I do think that we don't talk about the monolith because it's, it's not exciting and new and people don't want to talk about stuff that, well, we've been doing that for 20 years, 30 years forever. I mean, it, it is ironic to me that probably the most common pattern to see in architecture is the big ball of mud. And yet that is the one we're all like, please don't do this. And yet we just keep doing it. So I'm not quite sure how to feel about that as someone who tries to teach people how to do this the right way. But I think it's important to understand that, that our applications exist on a continuum of modularity kind of on one axis and like deployability on another axis. And, you know, this is something that Spencer Gibb and I were talking about and he really kind of gave me this sort of vision that I then turned into this kind of slide that I like to show about this. But so the modular or the monolith kind of lives in that it's not modular and it's not very deployable because it's just a big blob that you have to stick out together. And obviously we'd like it to be more modular. That gives us some wins. And what ends up happening is a lot of people, they don't build modular monoliths. They build like they try to build this big ball of mud that they put out on multiple servers that distributed big ball of mud, which is probably the worst of all worlds. And so as we're trying to get to that magical upper right nirvana of microservices that are deployable and modular and I can easily swap things in and out, we tend to maybe make some

mistakes along the way of getting there. So that's kind of that argument of if you go from the monolith to the modular monolith, if then from there you now understand where are those seams in your application, what makes sense as a microservice. So I think that's part of the challenge. But I feel like so many of these things, it's us learning where the edges of the map actually are and what benefits from that distributability. Not everything needs to scale to infinity and beyond. Not everything is changing every few minutes, every few days. You know, there's parts of your system that are stable and you know, this is how much compute I need to run this. I don't have to worry about it spiking up. You know, I think about I worked on a system for a long time. My user population was 150 people, 200 people, something like that. I never had to worry about thousands of concurrent users. You know, so that had a very different scaling, so to speak, than if you're Dick's Sporting Goods or something and you potentially have hundreds of thousands, millions of people hammering your site the day after Thanksgiving here in the U.S. You know, so it's just a different set of concerns that you have to sort of apply. And again, that's where I think having that more mature vision of this instead of saying, I need to do this because I want to put it on my resume or it's the new hotness or I saw something on Twitter, okay, does it give you value? Do you have the same sort of context and constraints and forces acting on your application? Then great, you should probably use those tools. If not, it's probably just adding accidental complexity to your world and that's not a win for any of us. What we do is hard enough as it is. We don't need to make it harder just so we can say, hey, I did a microserver serverless functions with Kafka. Like, cool. Did it actually work? Did it help your customers? Did it increase whatever things you care about? You know, revenue, signups, whatever. You know, that's where I think we need to, again, just sort of have that slightly more

adult view of these things and not get so caught up in kind of the buzz and the new hotness and the hype. But, you know, that's... You got to start off with some... I don't know if this is the technical term, but some needs analysis. What is it you need from there to make sure that you're using the right tool for the job? I keep wanting to say the right tool for the right job, which adds a subtle other layer of analysis to it. Like, how does we determine the right job? But, you know... Yeah, that's it. I like that quadrant you could make there, the modularity versus deployability. Those are fun things to think about. All right. So, where can people find this book? You can get it from us. It's on our website. You know, I don't have the link right at the top of my head, but I'm betting you can probably add that into the show notes. Yeah, sure. If you go to... I don't know where I can put it on Twitch because I'm in my 40s. But if you go to Tansu.vmware.com slash podcast, you can find the show notes where I'll put this in the Tansu Talk podcast episode. But also, if you just search for responsible microservices, I'm sure you'll find it and you can... It'll show up on our site somewhere. Well, where are you in Twitter? Just... You can tell people... Oh, N-T-S-C-H-U-T-T-A. I mostly tweet about travel issues, which don't happen anymore, which means I try to OH things that my family says. Oh, yes. Now it's traveling from the office to the bathroom. Right. Right. Well, and the challenge is like my wife is normally right across my shoulder and I had to tell her, hey, sorry, I have a chat with Coté this morning, so I need you to not be in here. Oh. We'll have her on next time. Absolutely. I don't have an indoor voice. And so she has told me repeatedly that I can't... Like if I have a meeting and she has a meeting, like one of us has to move. Because I was doing a call or something and she was having a team meeting and someone said, hey, Christine, I think your TV's on.

And she's like, no, no, that's just my husband. So I don't know. I, I sound fine to me, but she says I'm shouting into my mind. I don't know. It's hard to say. Well, it's hard to say. I'm glad y'all. A lot of together time. A lot of together time. Yeah. Yeah. I wasn't, I wasn't paying close, close enough attention to my decorum. And the other day I, I was dropping off my son for a play date and their parents asked me like, oh, so you don't have to travel that any much more. How, how are you, how is that going for you? And I said, uh, I kind of like it. And they, uh, they laughed because you know, you're supposed to. It's a mixed, it's a mixed thing, right? You're only, you're only supposed to say it's great. I get to spend a lot of time. You can't, you can't admit that, uh, you only kind of like it. Well, there's pluses and minuses to say the least. I like the fact that I've gotten to ride my bike a lot more this year than I normally do. I've played a lot more golf than I normally do. I do like waking up in my own bed to be clear, but you know, I mean, there, there is some benefit in being gone for a little bit of time. You know, there's that what absence makes the heart grow fonder. And, you know, I, I, I, I guess I didn't look real close at your travel schedule for the year, but I know I had a lot of interesting trips that were lined up and, you know, it's kind of a bummer when you're like, oh yeah, my family was going to come with me for like this two week stretch in Europe and that didn't happen, you know? So it's, it's, it's unfortunate. I do think we might try some kind of a road trip thing and we're kind of kicking that around to see if, if this might be an opportunity to take advantage of the fact that we're all kind of virtual right now. You gotta do that. I don't know. That's nice. We'll see what happens. It's good to get out. All right. Well, speaking of getting out, we should get out. It's time. All right. Well, it's been a pleasure talking to you as always, my friend. Yeah, that sounds good. Well, uh, as mentioned, if you're listening to the podcast version of this, you can go to, uh, tonsu.vmware.com slash podcast to find the show notes. You can get that free book, Responsible Microservices, which, uh, sounds very adult. Uh, you know, hopefully there's one that's irresponsible microservices. Maybe that could be a lightning talk. Uh, right. Yeah.

I like that. I like that. Yeah. And, uh, also if you're, uh, if you're seeing this in YouTube or elsewhere, you know, we broadcast these as much as I can, uh, and with many, many other things, uh, on our, uh, our, our Twitch stream. So if you go to twitch.tv slash VMware Tonsu, if you're not on there right now, you should just subscribe to that and, uh, you'll get notified when we're streaming things. We do stuff every Tuesday. I think Wednesday, uh, I try to do them on Mondays when we record here. Other times we've got lots of content for you while you're around. Rumor has it. I'm going to have a show here soon. Oh, that's right. Yeah. The between chair and keyboard. It's just a matter of time here. I've got a whole bunch of people more or less lined up. Now I just need to figure out when I can slot myself into our very busy Twitch stream. What I can claim is my time on our Twitch stream. And then that'll kind of end up in one of these similar kind of channels. So I'm going to try to take an opportunity to get to know some of our friends and even more of our industry. And I, you know, you're making me, you're making me realize I'm kind of set up to be the, uh, the art bell of, of the VMware Tonsu thing. Cause I'm, I, since I'm in Europe, I can start really early, even before, you know, around midnight, 1am. And so if there's anyone out there who has any, uh, odd, you, have you encountered some code that people tell you is not real, some sort of organizational mechanisms that seem like some sort of conspiracy that the government is trying to hide. Maybe you can call in for, uh, you know, Tonsu coast to coast. And we'll talk about it. I like that. The, uh, the deserts of Amsterdam. Tonsu after hours. Yeah, there we go. Which, you know, for me, it'll be like normal hours, but that's fine. Right. Right. It's nine o'clock in the morning. Time zones. How do they work? That would be great. I need to use my time zone power to talk to, uh, the, the, the kooks in the cloud native world. Totally. Stay up late at night. And, uh. Cloud native conspiracy theories. Yeah. Cloud native kooks. We should have that. All right. Well, with that, we'll see everyone next time. Bye-bye.

Tanzu Talk · 🍕 Get more pizza.