I had the distinct honor of talking with two of the worlds thought leaders in Software Architecture about their book - Fundamentals of Software Architecture: An Engineering Approach. We also get a sneak peek at their next book, Software Architecture - The Hard Parts. It was an amazing interview and these two have some of the best ideas in patterns, problem shaping and solution design in the market today.
Paul Preiss 0:12
Well, this is Paul price with the argument. I'm really, really excited about today's talk. As you guys know, the argument is a new podcast from the eisah. And we are just, I'm just thrilled to have Mark Richards and Neil Ford on, I would say, I would do an introduction for you guys. But if anybody who's listening to this hasn't heard of you, I would be absolutely surprised. I mean, how he, between the two of you, what are you at the 25, Booth? 30 bucks, 25 bucks, something like that. And 2000 conferences,
Unknown Speaker 0:47
Unknown Speaker 0:50
I can't I can't trust the person in the post office. Don't believe that. So we're, we have notoriety. But that doesn't mean anything important. Right.
Unknown Speaker 1:04
Well, so we're here to talk about your late your pre existing book, and also your upcoming book. So fundamentals of software architecture, architecture and engineering approach. I guess that that my first question is, just tell us about the book. Right. Right. Tell us what's what, what's the what's the the general theme, and what's the general approach? And you know, what, what are you going after it for in the book?
Mark Richards 1:33
Well, I'll start, Neil. So we, you know, way back about seven years ago, Neil and I were, were hanging out together on actually on vacation. And we kind of mused and said, you know, it's it's terrible. There's not really a comprehensive book about architecture. And Neil, so why don't we, why don't we work on that. And so that was about seven years in the making close to that of just really vetting out some of our existing material, creating the material. And really creating a comprehensive book that really dealt with the whole gamut of software architecture, the techniques, which is the first third, really the technology aspect with all of the, the styles and such was, which is part two, and then part three, the whole last third of the book on soft skills of being an architect with leadership negotiation decision making all those pieces. And so that was really our goal. And I think, at least for Neil, and I, we we achieve that goal?
Neil Ford 2:34
Well, that he shortened that a little bit, it was a really a giant filtering process, because the immediate reaction to that conversation was, there's no way you could write a book about software architecture, it's just too way too much of it, it touches too many parts, it gets way too multifaceted, you know, it would be 10,000 pages or more book. But then we started making a serious effort and started iterating on it by teaching the material at conferences, workshops and training classes. And we realized, as we kept iterating on the material was like, okay, that is sort of optional. But this is really the core part of software architecture. And actually, there was a whole swath of problems that we ran across that we started digging into. And it's like, Okay, this is too difficult for fundamentals book, let's set this aside into a pile that we're calling the hard parts. And we'll talk about that pile later, because that's where the second book you mentioned comes from. But I'll mention a little bit about the subtitle, which we very purposely called an engineering approach, because I firmly believe so I am one of those that took a circuitous path through my education and took a while in mechanical engineering, I decided for a while that I want to be a mechanical engineer and got through the statics class and got through the dynamics class, it was one of those classes at Georgia Tech, where it was its own prerequisite, meaning that you're expected to take it once and fail it and then maybe the second time through, you could pass it because it was so difficult. And so at about that time, that's when I switched over to computer science, and of course, got my degree there. But I spent enough time in a proper engineering discipline to see what an engineering discipline looks like before I came over into the computer and the software engineering world. And that's why I say that we're mostly still a sophisticated craft, not an engineering discipline, because if you look at for example, mechanical engineering, they have an enormous amount of measurement and metrics and math that describe to a tee. The problem is that I have an A great example that is very quiet recently, when we're recording this podcast. There was a tragic building collapse in Florida or condominium building collapsed. What really struck me about that, despite of course, the obvious tragedy of people unexpectedly losing their lives, is how surprised all of the building engineers were that this building collapsed. if there'd been a piece of software and people have gone Yeah, of course, it collapsed. Everything we build is as unreliable as can be, and you sneeze on it breaks, and you have to put it back together. And that's a level of the maturity of an engineering discipline who has objective math and you know, has really good trade offs and really good tolerances for real world events, that we just don't have anything like that in software yet. Now, I think we will eventually get there. But we need a few more decades or a few more centuries of work. Because what we've gradually been doing, I think, is we basically adopted metaphorically a whole bunch of manufacturing metaphors and things like that for software. And we've been gradually teasing those things apart. You know, the Agile Software movement, in large part was, let's distance ourselves from these manufacturing metaphors that just aren't working for software. And you know, speed up feedback, because it's softer, we can make it change faster. And so I think that's where in the process are doing is gradually pulling it apart and making it its own proper engineering discipline with metrics, etc. And so this is a long digression. But that's one of the things we wanted to focus on in the fundamentals book is what are the really measurable things that we have now in software as part of this journey toward making it a proper, you know, certifiable engineering discipline?
Unknown Speaker 6:16
Yeah. Well, so now, what's your background? It makes it so it'd be nice. You come from an engineering via the engineering mindset, computer science, are you the same, you've got the same background?
Unknown Speaker 6:30
Almost. I started out actually, as an astronomer, and so I've always been into chemistry, biology, the hard sciences, as a matter of fact, and so yeah, so my career was as an astronomer, and so I had that scientific background, and also the rigor involved with a lot of that hard science. And so you said that word. So yeah, so we kind of we kind of shared that that sort of parallel paths a little different in terms of the hard sciences. But But yeah, still still share that.
Unknown Speaker 7:03
And one of my one of my mentors, well, I think my, the person I considered my mentor was, well, he was a physicist, theoretical physicist, and actually used to meet pretty regularly with the Freeman Dyson. And I, you know, and he was like, Yeah, but you can't make any money at that. So I became a CTO. Seriously, there's this, there's a, there's, I want to unpack what you guys have said, because, and I really do want to focus in on the book. So there's a couple of, you know, maybe we'll go through some phases here, because I think the the profession, the real engineers question. Also, it there's a lot of complexity to that in the modern world. And there's, you know, and to and to challenge that a little. You said two things that often, that often don't conflict. And this is one of the things I liked about the book is you talked about conflicts and, and, and the hard parts a little bit, but one is speeding things up, but then it's also building things better. And those don't, you know, that, you know, we spend a lot of money and a lot of time in society, making sure building I live in Amsterdam, by the way, where, you know, they come by and check the facade every 30 seconds, basically, structural engineers coming by in the house to to make sure that the things don't fall over any further than they kind of were already did. But you know, but so, so how do you I guess I'll just go ahead and go there. How do you speed things up, but then do better engineering?
Unknown Speaker 8:46
Well, though, so that's really so we touched on this in the fundamentals book, but that's really more of the subject of building evolution architecture. So let me let me give you a little bit of a the way this kind of worked out historically. So if you look at the late 80s, and early 90s, really common phase on almost every software project was the integration phase. Everybody worked in isolation, he got together at the very end and integrated it all together. And it was horrible. And in fact, it was a pretty strong correlation to the size of the project and how horrible that integration phase was. And Kitt back in the XP, folks in the beginning of the 90s, came up with this radical idea of continuous integration. And one of the interesting things about continuous integration is not only do you do less work, at the end, you actually do less work in the aggregate. Because if you let some software problem tangle up into this massive ball that you have to untangle, you've created this massive problem for yourself. So one of the key lessons there was automation can fix those kinds of fiddly manual problems. So fast forward to the early 2000s. In the DevOps revolution, get operations people running around, manually installing software's and applying patches and important things were falling through the cracks. So what do we do we automated that Now, what do you have you have architects running around doing architecture review boards and code reviews and other ineffectual things, important things are falling through the cracks. How do you fix that problem? history has taught us you automate that governance. And that's really what this idea of fitness functions from the evolutionary architecture book was about. You can't govern, you can't automate every bit of governance. But there are a lot of things you can govern, we give examples of, for example, the structure of the of your architectural design. If you design a layered architecture, and you want to preserve the isolation between those layers, you can use a tool like arc unit to write a unit test that makes sure that developers don't accidentally cheat between the structure. That's how you automate. Because if you do that with code reviews, I mean, you'll catch some of those. But you know, gradually, your code base will degrade because of these little death by 1000 cuts. And that's why you know, code bases as they get older, get harder and harder to deal with. I've seen some code bases that had really good governance, that have lived for decades, in some cases, because you know, they've been very intentional about doing that. So I think that's one of the ways and not the only way. But one of the steps towards getting to a proper engineering discipline, is look at lean into the things that we have superpowers for. So you know, part of the reason that mechanical engineers had to invent all that math is it's crazy expensive to build things so you can rack up. But we can do that as much as we want. Because software is soft, and it's cheap. And we can iterate and rebuild it and throw it away and rebuild it and throw it away. And we should lean into that advantage and automate as much of that as we can. Because there are just too many details and moving parts and software. So you want to automate away as many of those details as you can. So you don't have to constantly think about all those details all the time. Until we get to some sort of math that allows us to encapsulate all those details away safely, then we have to figure out a way to manage those details. And the best way we have to do that now is through automation and testing and some of those practices.
Unknown Speaker 12:02
Well, as a matter of fact, that's that's how we leverage the identification of what I like to call architecture, vitality. In other words, finding structural decay within our architecture. And just like the building examples, we just went through with the disaster in Florida or even Paul, what you were saying about just always checking the facades of buildings and the structural of that. It's my feeling that and observation and experience that we don't do that enough with software architectures, this is the structure that is holding up our applications. And it's not enough just to say there, it's done, it's perfect, over the course of years, that it experiences structural decay, and one of the best ways I have found of locating that structural decay is in fact fitness functions, right in these on the back end that just run in the background and look at those trends of changes that are constantly being made to an application is an impacting the overall availability or scalability or fault tolerance, reliability of our architectures and, and this is something I just absolutely cannot stress enough, the need for that before applications basically implode.
Unknown Speaker 13:17
So fitness functions was was one of the my favorite parts of both evolutionary architectures and then getting into the metrics, and going further taking fitness functions and talking about what what kind especially understood, what I really liked was the notion of, instead of setting a quality attribute, you had a goal for, you know, reserved, actually using data to look for what you know, where can that That, to me was a big aha kind of moment. Because I've always, you know, I've always thought about it as Oh, you know, we need to say x perceived performance and X amount of resiliency and X, you know, in me mean time to recovery. And we're going to set these goals. And one of the big eye opening moments for me in the book was was was actually thinking about looking at the data first, and then letting the data design your fitness functions, your your the outcome of your metrics, from those tests, and, and those kinds of things. And, and I wonder, how do you how do you teach that? I mean, I really love that in the book, but how do you get teams, especially large, diverse teams that are, you know, international to really kind of dig in on that, like, is it not I don't mean training the people I mean, like, what are the techniques to actually get that I mean, you mentioned an arc unit, for example. What are some of the other ways to make that a part of the engineering culture?
Unknown Speaker 14:53
Well, so one of the tricky things about any kind of architecture function like this is that every architecture is is snowflake, I have no idea of what you know, intentional platforms you've chosen and the ones you didn't choose and the legacy and you know, what protocols and what kind of junk and I mean, so it's almost impossible to craft a tool that people can just download and turnkey and work on because I have no idea what kind of chaos is going on within your ecosystem. So one of the key things there is to identify what are the key things within our ecosystem that will allow us to move in the direction we want. And so a great example of that is our largest global client now has within their enterprise architecture Group, a roll called an evolutionary architect. And their job is to coordinate with the domain and integration and other enterprise architects to make sure that the decisions they make, facilitate the evolution that the enterprise architects are trying to drive globally for this organization. And a lot of that is building fitness functions around so you know, a lot of what they're thinking about is not the very low level kind of code metric kind of fitness function. But rather, I want to build an internal capability around a platform or an API around something like accounting. Well, I've come to believe that enterprise architects should not specify the technology that that API platform should run on, because they're too far away from the real world. But what they can do is specify with fitness functions, what kind of architectural capabilities Do I need from that point of my architecture, and then let the domain architects make the technology decisions, which does two important things, it gets enterprise architects out of making decisions, they're probably not qualified to make any more. And it gives responsibility to those domain architects to make decisions with consequences. But within the sandbox that they the enterprise architects have created around fitness functions around these important things like scale, or elasticity or security. And so that gives them a way to have influence that is verified, because you're running these fitness functions all the time. But without having to constantly be in everybody's pockets, you know, all the time and in the details of their project too much. I mean, that's really one of the keys, I think, to being effective at a holistic level like that is not having to be involved in all the details of every project, because you'll just drown in all those things. Instead, figuring out what is the appropriate level of detail and then start codifying the things that you want organizationally from that.
Unknown Speaker 17:32
Okay, so I'm gonna ask the, the the, you know, ever present argument question in our community. You since you since you brought up the E with the A, we're gonna talk I just want to ask you, because the book really talks about software architecture from an engineer's view. And, you know, having and having been a software architect on on some bet law, some, I've always considered myself a software architecture, no matter how big a skyscraper we were building, right. But there is a very strong divide in our field between the disciplines. And I'm curious how you guys see that divide between the you know, whether we call them information architects, or as cloud architects or enterprise architects or business architects, or as we consider it, you know, or solution or software, you know, it and I don't, I'm not looking to, you know, get a fistfight going, I'd love to actually get that call going actually, as well. But maybe that's a different argument. But how do you characterize the relationship between the disciplines and and still maintain the quality of excellence that you're that you're specifying in the book? Yeah,
Unknown Speaker 18:55
I think one of the one of the things you mentioned, which really just really hit me, Paul, was when you said, the divide between these kind of roles. And that's exactly the problem. You know, we we have good definitions, at least in my mind, a fairly clear delineation of the roles of an Enterprise Architect versus an integration architect, a domain architect, maybe an application architect, and we can fairly, it's fairly straightforward to get a good concise definition of what each of those roles do. But you hit the key point, though, Paul, and the reason why I think there's so much not only confusion, but arguments regarding these roles is the divide. The great divide between these, a really good example, an enterprise architect, and this is my humble opinion about the role, works closer with the business stakeholders, to take major business initiatives, what the business wants to accomplish, and say, make this happen, get this done and develop a roadmap of the overall system. that need to be accomplished to maybe fully automate the order entry process. This involves a lot of domains, a lot of different departments, and definitely a lot of systems. That Enterprise Architect is at the level of understanding the business needs and the capabilities that it is providing for those, and what needs to change in each of those systems. Now, where the problems occur, because of what you had said about that divide those artifacts turned into projects that domain architects or appellation application architects would own. And the problem is like the problem with a software architect or an application architect and development teams, these artifacts are not either they're not conveyed effectively, or they're one way communications down to the application or domain architects. And this needs to be bi directional. Yeah,
Unknown Speaker 20:57
yeah. Oh, yeah, that was another that was when you guys were talking about collaborative is one of my favorite sections, was the what was it was the kind of one way arc architect to developer pathway versus the mentoring circular pathway, that was at least something that we've at eisah have been talking about for years is that engineers and architects, it, you know, are, are effectively peers. And they, they're just looking at different things in some ways. But that's, that's I love that you. You said that the one way street doesn't work. It doesn't. Yeah, yeah. But again, though, doesn't that we when we when we think about a demand, demand shaping or demand pipeline, right. One of the core tenants of agility, then that that you guys talk about is again, that the engineer and the engineer in the business, though, the architect, the software architect, and the business, and, you know, I think the question then becomes, what is that? What is that look like? If you heal the divide? How does that how does that become a circular, you know, relationship? Or a, you know, a peer or up mentoring relationship? or, or, or that kind of thing where, you know, how do we make that demand shaping work, while still allowing teams to be as close to their business purpose as possible.
Unknown Speaker 22:32
I've always been a firm believer that the project manager and the architect should be peers, and that the Arctic does not work for the project manager, because if the project manager says, this needs to happen, the architect can say, No, we can't happen. Because of this concern. Too many projects get in deep trouble, because the project manager says, Well, this needs to happen in the Arctic says, well, that can't happen. And the project manager says, No, what's going to happen? Right, it's like, all right, then we'll cut corners, and an incorrect job can make that happen. And of course, with the promise that, okay, we promise, we'll give you some time to go back and fix this horrible thing you're doing. And of course, that never materializes. So you end up with one horrible hack after the other. So I think it's important for the business person, the project manager, the business analyst to understand that this is, again, a two way street, that the architect is a peer, not just to the engineers who are responsible for making their vision come true, but also the business people Because ultimately, the business people want the architect to allow them to make that vision come true. And, you know, if you're making a lot of compromises, then you know, you can, you can sprint for a little while, but then you've got to catch up and, you know, catch your breath and, and do proper things. So I think that's part of it's getting a good collaborative relationship going with the business people in the project management and not making it a boss employee relationship.
Unknown Speaker 23:55
One of the things to follow on that, that I always like to tell people, you know, developers typically traditionally implement our architectures. And I like to think about it, I like to think about it in a different angle. And that is that developers what they're really doing, are validating our assertions and assumptions as architects. And sometimes we are wrong in our assertions, especially when implementation reveals those kind of details. And when developers start saying, yeah, that won't work because of a firewall, we have to use this kind of communication protocol. That never gets back to me. And that influences some of my decisions that I made as an architect. The same holds true with enterprise architects communicating to domain or solution or application architects. Those architects are in turn validating the assertions and assumptions and EA is making and without the two way communication. That's why all of a sudden you get these comments that I see A lot in my consulting gigs. Everybody seemed to agree and approve the architecture all the developers got it. But all of a sudden, three quarters away through the project, that's not what we're implementing. You didn't understand it. And it's like, oh, no, no, I understood it, but it won't work. And then some I hear those. It's a problem of collaboration. way street, it's it's the only way in my experience of 26 years of getting architecture to work. Neal, I had to laugh when you were answering that question. Because back, this is nothing new. By the way, in the late 90s. I was an application architect on a particularly large project, and the project manager said, Now we're going to have arguments. I want to have arguments because I'm going to say one thing, and you're going to counter and say something else. And I said, Okay. And about halfway through the project, the project manager called me in and he said, into his office, and he said, You're not fighting with me. You're supposed to be arguing with me, it's like, well, I've got nothing to argue about. I mean, so far, things are going well. It's like no, pick a fight with something. I mean, he wanted that fight to happen. And that's what I was laughing, Neil, when I cuz I trust that memory back of that peer negotiation?
Unknown Speaker 26:13
Well, this is actually a really good piece of actual advice for all the architects listening here. Is vine, an early opportunity to be corrected by somebody on your team. Because as soon as they see that you are correctable, they will have the confidence to correct you, which is exactly what you want. That creates the feedback loop and not the Oh, this is I can't I can't correct them. Because they're the architect, find an early opportunity to let the the most junior person on your team correct something that's incorrect about yours and make it really public. That that's done. Hey, good job, you found that I didn't even think about Yeah, it's awesome. Because that makes anybody else want to
Unknown Speaker 26:56
do in this podcast right here. Let's coin a new architecture anti pattern, and the name of it is the infallible architect, anti pattern.
Unknown Speaker 27:09
And hey, wait,
Unknown Speaker 27:10
I got it, I got an addition, let's coin the the pattern, which we'll call the stump the architect pattern. There you go, Sam, go sit in front of a group of developers until they stump you and show them that you're human.
Unknown Speaker 27:26
I think it's really sad, right? I was an architect on a big project, a startup at one point, and I had written some code. And you know, I was coding architect and I came in the next day and looked at some diffs. And one of the interns had changed some my code, and I bristled up is what you mean. And I looked at, it's like, okay, that's better. Yeah, that's better. What I'm doing,
Unknown Speaker 27:52
you know, we, we talked about it, I said, in our, in our, in our classes, etc, about what we call healthy tension. So I grew up in construction, right. And I and, you know, when you're on a big building project, right, it turns out that the foreman, and the architect and the structural engineer, and the lead plumber, and the lead electrician, and you know, and all of the different different roles, it turns out that they yell at each other a lot. And as a kid, I'm kind of like, Whoa, you know, Dad, you're, you know, the my grandfather started. But so we talk a lot about this healthy tension. And that's what I hear in what you're saying is that is, is a, that it's about collaboration, B, it's about being able to voice your opinion, see, it's about the end result is better, with everybody participating, and, and everybody pulling in a different direction a little bit, to try to land us into the best position. So I thought that was really good. Now I want to get, I want to get into some of the more, I guess, technical side of the architectural aspects of the book that I just really loved, you know, I don't get as many opportunities to build as big as systems I still get, I still have the product we're working on in some of that kind of stuff. But so tell us what you're like 2021 where we're five years into microservices, we've serverless cloud, etc. What are the you know, in functional programming is taking over from object oriented programming, you know, there's there's all of these trends going on. So tell us about sort of your core proposals for software architecture, patterns and pattern application in in you know, medium to large systems that you really are seeing as as the as the best approach. You know, because from the book, I got a lot of you I see a lot of the trade off. And I think that's the what I love about both of your writing is that you make the trade off about math, as opposed to about sort of hype. But tell us, tell us a little bit about sort of 2021? how, you know, where are we? How do we start applying these patterns? Where do we, you know, what have we learned about microservices over the last few years? What have we learned about serverless? Over the last few years, see cqrs, etc. You know, that's, I think I kind of want to dig in a little bit into into some of your, your thinking about that.
Unknown Speaker 30:36
Sure. Well, I'll start and then mark and respond. What we like microservices is interesting, because, you know, I'm actually surprised at how successful we've been with microservices, just because there are some, you know, fairly sharp edges in microservices. And I think that there was enough awareness of the sharp edges early on that a lot of people didn't stumble into, you know, these really obvious bad patterns. And you know, the Gartner hype cycle, you know, there's the the hype, and then there's the trough of disillusionment, and then you know, settles into, I don't think we've hit the trough of disillusionment quite yet on microservices, which is suggested still sort of growing, because we still see a lot of people being successful when it's applied correctly, just like anything in architecture, it's not a silver bullet, you've got to, you've got to have the right shape problem. But when that's there, and you've got good engineering practices in place, so we're still seeing a lot of support and a lot of enthusiasm for that style of distributed architecture, which is mostly under the label microservices, all pretty broad label now,
Unknown Speaker 31:44
more of a style these days, right? I mean, it said, kind of like saying client server back in the day, right?
Unknown Speaker 31:50
Things like serverless, Mark, and I have been, we don't have that as one of our delineated styles in the fundamentals book, because we don't think it's a distinct architecture style. It's a deployment topology. And the reason we say that is because then we make the differentiation in our book between styles and patterns. styles are sort of fundamental topological arrangements of components were styles, like cqrs, you mentioned, can be applied. And that pattern can be applied in a lot of different styles. And that's why we say we think serval, is more of a deployment pattern, because you can implement microservices, or pipes and filters, or modular monolith, or a number of the styles in a serverless kind of ecosystem, just with different trade offs and constraints. So that to us is the most interesting thing is not as a unique architectural style. But what are the unique constraints that come with using that as a deployment medium for an architectural style?
Unknown Speaker 32:46
Well, I love I love the name Paul, of this podcast, the argument because I disagree with Neil. So let's have an argument. I, in my experiences, do actually believe and I have actually for a couple of years now that microservices is, in fact entering into that trough of disillusionment. And I see this because of the frustration of companies, business owners, teens themselves, really struggling with this extremely complex architecture style, whether it be granularity, mostly with data. And also the user interface pieces of kind of developing micro front ends is really, really hard. And you've got all three layers in micro services, not to mention the gateway, which is now number four. And the arguments in suing about a large gateway, which starts to recreate SLA all over again, my point is, most of my experiences with microservices. And I won't say all because there are some companies that I would say, are good showcases for actually doing it right. But the majority are struggling with cost overruns, maintenance, nightmares, a low testability, all of the five star ratings that Neil and I gave to all the characteristics of microservices aren't being achieved, tying workflows together synchronous calls between services, one service goes out, it takes out half of the ecosystem. And I can I can go on Paul for almost an hour with the disillusionment that I've seen companies say there's got to be something else which I've seen that move to more hybrid architecture styles, specifically with service based combined with microservices is now at least I'm seeing in my experience is becoming kind of the norm for a lot of distributed architectures. splashing a little bit of event driven architecture, and, and that's what I'm seeing 2021 becoming quite frankly, well, Neil, we've got to have time for rebuttal. I mean, you know,
Unknown Speaker 34:54
I mean, so you know, we're both consultants, so consultants tend to see train wrecks more than they see Get a nice pretty thing. Somebody hired you to come bless their beautiful architecture, they come to help you fix something that's broken. Those things are true. I mean, nothing that I say should construe that Microsoft has gotten any easier. There's still a lot of difficult problems to solve. But, and you know, some people are struggling with it. But, you know, probably for me, the biggest surprise I've had is how few disasters have been. Because we're not first all Microsoft is I thought, Man, there's going to be some people that make some horrific train wrecks out of this and a few but not as many. But yeah, toward Mark's point, I mean, you know, it's getting more and more complicated, because you know, what's happening after you get past HelloWorld, and microservices, and then you get past your first workflow, then you get knee deep into transactionality, and scale and that kind of stuff. And that's when it gets hard. But you know, that was hard before microservices, because it's always been difficult distributed architectures. But one of the things that one of the observations that Mark and I made recently is because we built a lot of distributed architecture systems back a couple of decades ago with with bare skins and, you know, stone axes, my tools, but you know, we were wondering, why is it why microservices, so different from those because it's still events and messages and message queues and, and it's that it's data fidelity, and it's transactionality. Because when you move the bounded context and the data into the service boundary, now transactionality becomes an architectural concern. And that's a really difficult architectural concern to manage in a lot of cases, because you have to, in some ways, reorient the way you think about your architecture to be able to do transactions at scale, for example, that's, that's, that's where the I think the the difficulties come in, I don't know that people have gotten worse at microservices, I think we're tackling more difficult problems as time goes by with microservices, and we're starting to see some friction.
Unknown Speaker 36:53
So you know, I just want to remind everybody that the the acronym, soap stood for simple object Access Protocol, right? And what I mean, we always start our trends always start with solving solving a problem in a simple way. And that, you know, and then it becomes the, then it becomes the pattern does your, and then a B, and then you start tackling really big problems. And then, you know, what I see and what I'm curious about what you guys think is because we it's like we hold up things like Netflix, or, you know, fair of Spotify or whatnot up until this sort of stratospheric sort of heavenly, we wit, you know, we're we're going to be like them, but their business models don't match, like, you know, when a bank is has a much more complex business model, then, you know, a streaming TV service. So what I say, you know, we talk about Conway's Law. And we talk about some of these kinds of things. Where, and I'm just curious, do you have some rules of the road then to decide between these pattern applications? Because I mean, I've literally seen some large teams effectively reverse the strangler pattern, right? They just say, No, we're going to build a monolith. And we're going to split out a service and then split out and others, because we don't want to API gateway initially, and we don't want this and we don't want the configuration, then we don't want discovery. So I'm wondering, what do you know, the book has so many great guidelines, but it's also it's also, um, I think it's also I felt challenged when I was reading it, I was like, oh, man, I'm not up to these guys. Yeah, so maybe some simple rules of the road for really being able to identify, you know, pattern application in these distributed systems.
Unknown Speaker 38:53
You know, one of the one of the things Neil and I really worked probably hardest on in the whole book, were the star ratings, that we aggregated for all of the various architectures. And unfortunately, I think, too many people took that fully to heart. And because what you're really talking about Paul is something that Neil and I called domain to architecture isomorphism. In other words, your star ratings from the characteristics you want may match perfectly. It may be just a perfect fit, but the shape of your problem doesn't match the shape of that architecture. And that's really that second overlay. You know, once you've identified some candidates, it's really saying, well, microservices solves all of our problems, except our problem is really complex, integrated workflows, which is not the shape of micro services. And I think that's where part of that trough of disillusionment I've seen. It's not necessarily that microservices is bad. I actually really really like micro services. It's just that too many, too many teams or too many companies are trying to use it for The wrong problem. And that's, that's that isomorphism that we observed.
Transcribed by https://otter.ai