Lesson 203 - Understanding Architecture Style Risks Transcript, AI Summary & Key Points

00:00 hello everyone and welcome to software architecture Monday my name is Mark Richards as you as you may have noticed uh starting in 2025 I've changed the Cadence to software architecture Monday to occur monthly on the first Monday of each month as a matter of fact uh today's lesson is lesson 203 understanding architecture style risks based on our star rating charts when Neil Ford and I wrote the fundamentals of software architecture book oh we created star ratings for each architecture style based on various

00:40 architectural characteristics and you can get this chart from my website by going into the resources tab or menu item on developer to architect uh.com one of the things which I'm going to show you in this lesson is we didn't mean for these star ratings to be restrictive in terms of well if we need this and it doesn't support it we can't use it certainly certain things can only be solved by architecture things like elasticity and fault tolerance however I did get a couple of questions over the past couple of months that

01:20 I wanted to show you as a way of kind of interpreting some of these star ratings uh the first question I received uh was or that was posed to me um based on your star ratings chart can we use microservices for a new high performance system we are building or based on your star ratings of two stars are we forced to choose a different architecture style and another question that was posed to me last month we see from your chart that microservices is the most expensive architecture we could choose is it always so

01:56 expensive or are there ways we can mitigate that cost to make it less expensive so that it fits in our budget so these are two really good examples questions that were posos to me that made me think about a different way of interpreting these star ratings so the original purpose of these star ratings was really to say does the architectural style lend itself towards these architectural characteristics because there's certainly ways of making certain architecture Styles performant or not performant but there's another

02:34 way I thought of to interpret these star ratings and that is when choosing an architectural style you can leverage these star ratings to determine where the likely risk is within that architectural style choice and that's what I wanted to show you in this lesson let's go back to those questions that were posed to me um by uh by clients uh in the past couple of months so based on your star ratings can we use microservices for a high performance system because you're showing it two stars well let's actually take a look

03:09 at why we actually rated this two stars the bottom line is it all has to do with latency due to interservice communication when we make a request to a service uh that service goes and retrieves data from its own database within its bounded context but then commonly has to go to other services to get further data and those Services retrieve data they may do some processing return that information back to the calling service and this chain happens quite some time and then finally returns the result of that processing or

03:50 request to the user well two Services aren't overly bad but we've got three kinds of Laten involved with even just these two Services the first is Network latency the most common kind of latency we we see uh this could range anywhere from 60 to 300 plus milliseconds but we also have another kind of latency and that is security latency to protect those end points that we're calling and the third is that hidden one that I call data latency because for a single request we're made making multiple database calls now and all

04:31 those times start adding up and it starts to add up when in fact we start calling multiple services so this kind of architecture would certainly perform extremely well this will not and unfortunately when we use single-purpose Services they're typically fine grained and consequently we do typically have a lot of inner service communication which tends to slow down microservices so rather than saying oh we can't use it let's take a look at this as risk and how can we mitigate the risk if we have a scenario where we do

05:14 have a lot of in service communication the first way to mitigate that risk is to adjust your granularity many times all those in service calls are result of the fact that we went too far across the line in terms of that fine grained single-purpose service and because our functionality is highly semantically coupled bringing all that functionality together in a single deployment unit a single service removes all of that latency therefore speeding up our microservices ecosystem another Technique we can use is to share

05:57 data particularly if all those inner service calls or most of them are to retrieve data I don't own because it's not in my bounded context and in which case we still have a b bounded context but it happens to be a broader bounded context uh from an infrastructure standpoint we can sometimes solve this problem through what's called cervice location now this means services that communicate with each other constantly are put in the same uh kubernetes pod or the same virtual machine therefore all of those calls now become

06:38 local calls they're still remote but we're transferring 60 to 300 milliseconds into something that's 1 to two milliseconds and this can significantly increase responsiveness however there's a cautionary tale to all of these risk mitigation factors and because co- service location will typically impact things like fault tolerance scalability elasticity and those sort of operational characteristics well another Technique we can Leverage is especially if we're calling services to retrieve data is to use inmemory

07:19 replicated caching uh tools for example like Apache ignite coherence hazelcast gemfire infinispan these are the kind of tools that leverage in memory replicated caching and therefore removing all of that latency for having to retrieve your data so that's just kind of an example of saying you C you can still use it um microservices but there's risk associated with it and ways to mitigate that risk but what about cost because this question came up last month that was posed to me about is it always expensive where does

07:57 that cost come from well instead of just saying it's too expensive what we can do is analyze where that expensive cost comes from and in microservices it typically comes from the size of the system small systems will be fairly cheap but larger ecosystems start Rising exponentially in cost a lot of that has to do with some of the licensing costs associated uh with any kind of services third party services or data um development skill set and experience is particularly important within microservices because it is a

08:36 complex architecture and as a matter of fact speaking of a complex architecture also the complexity of the business problem perhaps influences microservices more than other architecture Styles because it is also a complex architecture and if we combine a complex architecture with a complex business problem it's probably going to take longer hence cost more also the anticipated rate of change after that initial development will influence the microservices architecture cost as well as or any organizational change needed

09:16 breaking apart data um modifying your existing deployment pipeline but one of the other things that we can do to mitigate that cost is to consider those hybrid architecture possibilities that not everything has to be microservices in our system and forming hybrids with something like service-based architecture uh would significantly reduce the cost associated with microservices there's one other example I wanted to show you and that was we we've kind of been focusing on one extreme end microservices but what about

09:58 monoliths they have risk as well because we notice that with the layered and the modular monolith they're not very agile um it doesn't lend itself towards these two architecture Styles don't lend themselves towards maintainability testability and deployability does that mean that we can't use them if we're facing constant change of course not what it means is that's our risk area and when we look at mitigating that risk we focus on simple small well-structured monoliths and we combine that kind of characteristic with

10:37 proper engineering practices and some tight governance using automated Fitness functions and these kind of techniques can then help mitigate that kind of risk so because you see only one or two maybe even three stars in an architectural style that you would like to use what it means is that you're likely to incur risk in that area and that's the area to focus on where we could possibly mitigate that risk so that you can in fact use that architecture style so this has been lesson 203 understanding architecture style

11:17 risks again um thank you so much for uh listening and stay tuned in one month the first Monday of each month uh for the the next lesson in software architecture Monday