Architecture meets delivery with Chris Richardson

Episode transcript

Rob Zuber: Hello, and welcome to The Confident Commit, the podcast for anyone who wants to join the conversation on delivering software better and faster. (singing) Today, you’re listening to episode six, and we’re joined by the brilliant Chris Richardson to talk about the importance of architecture in all of this. I’m your host, Rob Zuber, CTO of CircleCI, industry leader for all things CI and CD. Hey, Chris. Thanks for joining me today.

Chris Richardson: It’s good to be here. Hopefully, I’ve had enough coffee today to be brilliant, but I’m not sure.

Rob Zuber: Well, great news for someone like you, I think, is that your voluminous knowledge base and track record that precedes this particular conversation will fill in any gaps for people. I don’t think you have to be brilliant in every moment to be considered brilliant.

Chris Richardson: Oh, yeah, [inaudible 00:00:55], I’ll try and be humorous.

Rob Zuber: All right, sounds good. Sounds good. My coffee level is also in question, but we’ll make it work. Cool, well, it’s great to have a chance to chat with you. And as I alluded to, I think that you’re someone who’s done a ton of thinking recently and over time about architecture. And I feel like architecture is in kind of a… Well, we’ve seen a lot of change, as we have across all of software delivery and software development, I want to say over the last 20 years, but I always talk about 20 years because that’s the span of my career, more than because that’s the specific window in which all these changes have happened. But certainly around agile and rapid delivery, and breaking things down, and stuff like that, and I think architecture has followed suit in some ways. So, just to kick things off, what does the word architecture mean to you? When you talk about architecture, what is it that you’re specifically thinking about?

Chris Richardson: Yeah. I think in an informal way, architecture is all those big picture decisions that you make about the overall structure of your application or system, right? There is a more formal definition of it, which I pulled up just so that I could quote it correctly. But it’s the software architecture of a computing system is the set of structures needed to reason about the system, which comprise the software elements, whatever they are, the relations amongst them, and the properties of both. So, you’ve got a third of these elements that have relationships between them. And it’s a tool to enable you to reason about your application, in which you could just distill that down into, it’s like a bunch of boxes and lines, right? That’s what architects are famous for drawing. But then if you think, well, what of the nature?

And one of the interesting aspects of architecture is that if you think about, we’ll go back into the real world, because you could say that’s where the term has its origins, right? Kind of interesting. I’ve never really thought about the origin of the term. But imagine that you have a building that’s under construction. That has an architecture. And depending on who you are, which stakeholder in that building, you have quite a different view of what architecture is, right? So, if you’re a structural engineer, then you’re concerned with iron or steel and concrete, if it was a high rise, right? Whereas if you’re an electrical engineer, you’re concerned with all sort of wires and stuff, right? Then the plumber, it’s tubes and pipes, that kind of thing. So, architecture is actually multi-dimensional. And software is the same. And you’re talking about 20 years and trying to go thick. Remember, when this was defined, there was a 4+1 view model of architecture, of software architecture that took the same approach and said there’s different perspectives. So, as a developer, we build object oriented software, so architecturally, we’re concerned with packages and classes.

But then another perspective on that is how those classes get compiled into modules, JAR file, I’ll say, if you’re in the Java world, and then how those modules are combined into components or executable or deployable things, right, which could be literally executable files, or, say, Java WAR files. And then there’s the process view by a bunch of communicating processes, and then there’s the deployment view, which is nodes and networks, right? So, if you’re an infrastructure network engineer, that’s what you think of, right? As opposed to me, a Java developer, I think of classes. And then the plus one of the scenario is to animate all of this, right? To show how requests flow through the system, and you could view it from a class perspective, or from a network perspective, and everything in between.

Rob Zuber: Right. So, it’s really interesting that you… That’s an important overlay, the stakeholders, and who’s participating, and how they’re viewing what’s effectively the same architecture, but what’s important to different stakeholders. One of the things that I think is really interesting, you said elements, whatever they are, is, that’s something that shifted a lot. And you’ve done writing, speaking about microservices as an architecture. One of the things that I’ve been thinking about a lot lately, many people have moved to microservices based architectures. Many teams have you build it, you run it models, where engineers are on the pager for the pieces they’ve put into production. It feels like we’ve turned every engineer into all of those stakeholders in some way. As a member of a software team, now I need to understand the network, and the operational capacity, and the deployment tooling and everything, which is ostensibly great, but also drastically increases the cognitive load, the amount of work that any one engineer needs to be able to understand about the system. Does that resonate with what you’ve seen? And do we have pathways to get ourselves back out of that, do you think?

Chris Richardson: Yeah, no, that’s an interesting observation. And I think partly, I agree with you. I think, say, partly, I disagree with you, in the sense that some organizations, it’s still sort of quite siloed, right? But you could say that we have this trend towards DevOps, shall we say, right, which embraces that an engineer does everything. And in general, that’s good, right? If you’re responsible for something running in production, that’s really encouraging you very strongly to write production-ready code. Right? Yeah, which even is as simple as putting in the right log statements so that if there is a problem in production, you can actually troubleshoot it, right? So, I feel like there is this growing cognitive complexity that we all face. But then at the same time, I think another way of thinking about the whole DevOps thing, right, is… And this is in the book, Team Topologies. It’s one of my favorites, right? It’s all about people like the operational people, they provide a platform that abstracts away a lot of this stuff, so that I, as a developer, can focus on writing my service, and then I have a self-service deployment platform that I use to deploy things and all the low level networking and whatever stuff is hidden from me, because I don’t need to be aware of it. And I want to focus on understanding the business problem that I want to solve.

Rob Zuber: Yeah, agreed, both on that being a great book and the model that it provides in terms of effectively platform teams, pulling away some of those layers, creating shared capabilities. I get the sense, and it’s also important that you call it out, probably the bubble that I live in, which is, my customers are all practitioners of CI and CD, and operating in a very, we’ll call it DevOps way, but this services based, you build it, you run it, that’s probably not the whole world, so we have to remember that. But I do think that that layer is really good, and that notion of abstracting away those pieces. I wonder how good we are at it and how many people have gotten there. It feels like we’re in that transition, do you know what I mean, where we’ve taken on the complexity, but we haven’t solved the complexity in this new kind of pattern. Does that make sense?

Chris Richardson: Yeah. Well, there’s this quote that comes to mind repeatedly. It was William Gibson, right? It’s, the future is already here, it’s just sort of unevenly distributed. I think that’s the right quote, right? And so, when you look around, you do a survey, clearly, some people will be doing, quote, the state of the art, whereas other people are lagging somewhat, right? You can even take this with, you think about microservices, right? It’s kind of funny, I think the blog post that promoted the term was back in 2014, which is, I guess, a long time ago. But then it was all new, and it seemed new and exciting, but then in reality, companies like Amazon had already embraced that way of working back in, I think it was 2002. So, there’s all constantly, you finance these ideas that you thought were new, but someone somewhere has been doing it that way for a while. And it takes a while for things to diffuse and become mainstream.

Rob Zuber: Yeah, I think that’s probably a very important point, and the diffusion or adoption of these things. And second, one thing that always occurs to me, and this year, you cite Amazon as an example, is we tend to get the blog post or the tiny, little window into what’s happening inside of an organization like that, and say, “Okay, this is the solution to all of our problems,” without understanding everything that goes with it, do you know what I mean? You’re talking about Team Topologies, for example, how a team’s structured in order to support the choice of services as an architecture. Without diving in and understanding all of it, I think you run the risk of adopting one piece that you don’t necessarily understand or understand the implications of. And on that point, you mentioned team structure, you mentioned platforms, architecture and organizational structure have been correlated for a long time, thanks to Conway. I think you can’t go to a conference without someone quoting that. So, as you work with organizations on architecture, do you spend a lot of time also working with them on how to structure and organize themselves in order to support the kinds of changes they’re looking to make?

Chris Richardson: I think partially, in the sense that… So, one thing I constantly talk to clients about is there is this concept of a success triangle, which is where in order to deliver software rapidly, frequently, reliably, and sustainably, you need three things. And one thing is process, which is DevOps. The second aspect is organization, right? And that’s a network of loosely coupled, autonomous, cross-functional product teams, right? And then the third part is you need an architecture to enable those two other things. So, in many ways, I present, say, microservices as the enabling architecture to achieve the goal of loosely coupled DevOps teams, right? And I focus on the architecture piece, but at the same time, I make it very clear that you have to master DevOps, and you have to have this loosely coupled network. Because if you don’t have those other two pieces, you’re not going to properly realize the benefits of the microservice architecture.

Rob Zuber: Got it. That makes a ton of sense. So, you’re having the conversation about the implications, but maybe not sitting down and saying, “So therefore, I think this person should go over here, and this person should go over here.” That’s up to an organization to understand-

Chris Richardson: Yeah, but I sort of… We can touch on that, but it’s… Those are adjacent areas to what I focus on.

Rob Zuber: Right, right. And so, I’ve been wanting to ask this question, and it seems so simple, but how do you know when your architecture is good? What are signs to you or to any of us as we’re working on something that we needed some change, or that we don’t? I think we always feel like everything could be better, but when would you say, “Yeah, this is in a good state,” you can tell for the following reasons?

Chris Richardson: Yeah. Well, that gets into the issue of, what’s the point of this architecture thing, right? Is there more to it than just being able to call yourself an architect, which sounds awfully fancy, right? So, the way I explain is if you look at the requirements for an application, there’s the functional requirements, right, the user stories, and then there are the non-functional requirements, or ilities, or software quality attributes. And essentially, the architecture enables you to achieve a given set of non-functional requirements, like scalability, availability, I don’t know, extensibility. It’s funny, there’s a Wikipedia page that lists a whole lot of ilities, right? And then there’s some other ones that don’t quite fit into the ility framework. And it’s interesting, right, because I came at it from the perspective of I’m interested in this microservice architecture thing, right? And it was like, well, what is it? What do you mean by… What do you mean by architecture, and what do you mean by microservice architecture?

And I think this was back in 2016 or 2017, I think, I started looking into what those words meant, which then led me to rediscover a whole bunch of classic architecture work from SEI, CMU SEI that was done in the ’90s, and so on. Yes, and then that goes back into, yeah, architecture is to enable you to achieve certain non-functional requirements. And in particular, the area where the primary objective around the microservice architecture is all about having the right… Basically, it’s a way to enable you to deliver software rapidly, frequently, and reliably, and sustainable over the long run. And the reason you need to do that is that the world is super dynamic and unpredictable. Gosh, even epidemics come out of nowhere, right, which usually disruptive to even IT, right? And so, businesses need to be nimble, which means that given that software is powering many products and services offered by business, IT needs to be nimble and agile and deliver software rapidly, frequently, and reliably.

And there’s been a whole bunch of work around that, right, while actually, if you just deconstruct the success triangle, DevOps require is all about delivering a stream of changes frequently into production. And in order to do that, you need an architecture that’s highly deployable and highly testable. So, deployability and testability if you want to fit things into the ility framework. And then in order to have a loosely coupled organization, you need to have a loosely coupled architecture, right? That’s Conway’s Law. So, architecture and organization are, what’s the word, isomorphic, I don’t know, some fancy word for that. And that actually goes back to needing an architecture that’s loosely coupled and modular. So, you have these architectural requirements that you need to satisfy.

And then interestingly, in order to… You can actually quantify how good you are at delivering software rapidly, frequently, and reliably, which is going back to your original question about how do you know how good your architecture is, right? So, you can quantify the development velocity related aspect of it in with those DevOps metrics like lead time, right? What’s the time from a developer committing a change into production and committing it what, say, doing a git push, and then that change being deployed into production, right? Good number there is 15 minutes. And that actually has… That is a requirement that impacts your architecture and also impacts, well, how your whole development process as well, right? And then another metric is deployment frequency, which also goes back to architectural and organization and process requirements, right? And then also, there are some metrics around how reliably you’re doing it, right? What’s your change failure rate, and then your mean time to recover from any production outage?

So, you can measure those metrics, and in particularly, if you start to see us decrease in those metrics, then that’s a hint that if you’ve got a monolith, you’ve actually, maybe you’re outgrowing your monolith. Assuming that you’ve optimized your development process, right, at some point, you’re likely to hit a wall where… And this is very specific to the monolith versus microservices argument, right? But you just figure out, well, this monolith has got so big that we can no longer deliver changes rapidly, frequently, and reliably, and we need to functionally decompose into a set of services.

Rob Zuber: Got it. Well, I will say that at CircleCI, we’re big fans of rapid delivery. It’s the thing we spend all of our time thinking about. And it’s absolutely an interesting way to bring those together, and the enablement of it. One thing that I was thinking about as you were talking, and you shifted into the more temporal moving quickly element is some of those classic ilities, right, the stability of the system, we thought we were getting by reducing the rate of change, right? That was the classic model, well, let’s only make changes that are really well controlled, and understood, and all those things, because then we reduce the risk, which, of course, in my mind, proved to be incorrect. And I think that’s where we’ve trended. But how do you pay attention to those things over time or ensure that you’re designing, I guess, for that? How do you design for stability with a rapid rate of change, or quality with a rapid rate of change? How does the architecture play into that?

Chris Richardson: Well, I think one is, I think you primarily need to have these metrics, you actually actively measure and track lead time. Well, lead time, deployment frequency, change failure rate, and so on. And those need to be elevated to first class requirements, right, along with, say, the whole scalability thing, right? Most organizations deal with scalability, right, because that’s a very customer facing feature, right, metric. But I feel like where a lot of organizations fall flat is there are all these non-functional requirements that are hidden from the customer, which then… And this all gets into the area of technical debt, right? So, you got, let’s say, product owners, and their focus is on delivering revenue generating features, which is really functional requirements. And I think the… And apart from scalability and performance related metrics, there’s a whole class of non-functional requirements that are invisible to the end user, and they get neglected. And so, your architecture, not enough effort is actually spent on architecture. I feel like a lot of the time, what architects do is work on big features, big functional requirements, and not spend enough time thinking about the invisible non-functional requirements, which are important for long term, sustainable, and successful development.

Rob Zuber: Right. Well, you threw in long term at the end there. I was going to say, every invisible requirement becomes visible to the customer at some point, it’s just a matter of time. When your system collapses because it never was going to be able to reach that scale, right, it wasn’t ready for that. Or when you slow down development enough that you just stop delivering new features because no one understands the code base, it always ends up in the customer’s perception, they just might not understand what that perception is, versus a feature or the site is up or the site is down sort of thing. And I think that’s an area where I would agree a lot of organizations struggle to have that long term view because it’s… Every system is new, in a sense, right? That next level or that future is new to everybody. So, I was actually think it’ll be interesting for someone like yourself, just to give you work, that’s why I invited you here, to show some stories or case studies of this was a decision made at this point in time, and here’s where it became a problem sort of thing. I don’t think any of us have that time horizon view, and I think it would be really interesting to look at.

Chris Richardson: Well, I feel like maybe the metaphor is organizations, I think, typically dig themselves into holes, right? And every day, you dig that hole a little deeper, right? And it probably takes years, right, before you’ve dug a hole that’s deep enough that you realize you can’t see out of it.

Rob Zuber: Yeah, one of the questions that was on my mind this morning, and this feels like a good time to talk about it, is are rewrites just inevitable? Are re-architectures… It’s a bit of both, right, this particular system needs to be rewritten, or this whole thing needs to shift and change fundamentally. Are we just either that… I don’t want to say bad, I don’t want to be so judgy, but do we have that much of a challenge seeing the future, or do things change so much in unpredictable ways that we can’t tell? Or do we just under invest? And if it’s the other way, if we can’t predict, should we design systems that we can easily rewrite, throw away, re-architect? Is that acknowledging that there are particular stages of growth that we might not get through?

Chris Richardson: Well, I think it is possible that at some point, you might have to just throw it away. But the problem you have is, what do you mean by a rewrite? And I think what’s really problematic is if you have to have a big bang rewrite, where we have to spend the next three years rewriting the application from scratch in order to, first, recreate the features that we have today, and then add the new features that you actually needed yesterday, right? So, certainly, the way to do rewrites is with an incremental migration or incremental rewrite. And there’s the strangler application, right, or strangler fig application, where little by little, you migrate functionality from an old application into a newly constructed application. And so, I think in a way, one of the appealing aspects of the microservice architecture for me is that a lot of the rewrites around if you have a microservice architecture, then you can basically rewrite an entire service, right? It should be feasible to do that. You could switch its technology stack, right? You suddenly decide, oh, we’ve been using Java and we love Go lang now, right? You can rewrite your services from Java to Go lang incrementally, right? Whereas if you’ve got a monolith, that’s far harder to do.

And fingers crossed, I feel like if we got it right, we can actually build applications that will survive for a long time and can be incrementally modernized, so we don’t end up with these 30 year old bloated, incomprehensible monoliths, right? For instance, I remember working with a client. I think they were a multi-billion dollar business. And their key business application was written in some… It was 4GL, if anyone can remember what one of those were, right, using a database from a company that no longer exists, right? And so, huge problem with actually even rewriting it, because the people with the technology skills, maybe they’re retired by now, right?

Rob Zuber: Right. Yeah, absolutely. And I think that I was going to highlight the people in that, and then the understanding even of what it does, or to your point, the ability to do an incremental change. We’ll just take out this piece, but if we take out that piece, does everything collapse? Nobody really knows anymore those sorts of things. Do you have patterns for… I don’t think that particular case is the norm, but there’s plenty like it, right, with these systems that nobody fully understands. Do you have patterns for modeling your way out of that?

Chris Richardson: Yeah. Well, there are refactoring patterns for refactoring from a monolith to a microservice architecture. The challenge that you have is that it’s like taking a module at a time and turning it into a service. The problem you have is that module might not be clearly defined inside the monolith and tightly coupled either just through explicit co-dependencies, or it might be embedded inside a transaction, that then if you extracted it out, has to span the monolith and this new service, which creates a whole host of problems. And so, you got all these different types of coupling that can be difficult to break. An interesting idea, it’s funny, I used to, in presentations, it was probably like eight years ago, and it got dropped at some point. There’s this interesting metaphor with the human body, right? So, human body is comprised of a gazillion cells. And cells have a finite lifetime, which might be measured in… I don’t know if it’s as short as hours, but days, weeks, months, years, right? Maybe your brain cells live for a while, [inaudible 00:31:11] might be longer. So, if you think about the human body, it is constantly renewing itself, right? Cells die, get replaced by new ones. And so, in some senses, you are not physically the same person you were a year ago, right? Bits of you have been replaced.

And that’s a great metaphor. And this is from Richard Gabriel, a computer scientist. He wrote something, what, a few years ago that inspired this. But that should be a long live system so that you can replace parts of it incrementally, but the system still remains the system. And I think another common metaphor around that was, you got a boat that’s comprised of wood, and you replace it one plank at a time, it’s still the same boat, right?

Rob Zuber: Right. Yeah, I was trying to remember the context in which I’ve heard that, but I’ve definitely heard it. Yeah, I think it’s a really interesting model. What is the external interface of your system effectively, right? What is the customer seeing? The user, whoever that might be, you might have multiple users. And then how much of that… Is there value, I guess, is the more important point. I’m no biologist, but there are reasons that your body is replacing cells over time, right? So, are there good reasons to be thinking about, yeah, this stuff decays? To the point of the inevitable rewrite, an inevitable rewrite of a tiny little piece of the system that says, you know what? This is good enough for now, but then we’re going to replace it with something better when we reached this point, feels very comfortable, especially if it’s intentional, right? Oh, this will get us to the place we need to get to, and if that breaks, we know what to do next. But that’s a bigger investment. It’s not worth it right now. I think we’re not always good at that kind of thinking, but if you can do it in those small pieces, could be a great way to actually mentally model the evolution of your system.

Chris Richardson: I think one very tangible driver behind replacement is technology changes. So, technologies come and go, right? And even within a particular technology, the versions come and go. And so, there’s two types of evolution. And so, you look back far enough, right, it just so happens that Java has been around for 25 years, right? Which is quite successful. But, say, within Java, there’s been many versions of it, right? And there’s a whole notion of with any technology or technology version, you should remain current, right? So, one way of putting that, the relevance of a given technology inside your organization, it should basically mirror the relevance of that technology in the marketplace, right? Because that has implications for hiring and all kinds of things, right? And then more tangibly, you want to be able to apply security patches.

Rob Zuber: Right. Absolutely. The whole notion that you want to be able to keep stuff current, I think is really valid. The technology one is particularly interesting to me because I see people adopting technology because it’s cool and new versus, because it supports some driver for either for a particular problem you’re trying to solve, which could be technical, it could be, to your point, business in terms of hiring or maintaining a team, whether you can get a particular type of expertise in a particular technology stack is a really interesting… If you’re trying to hire data scientist today, for example, you probably have a limited subset of stacks that you would choose from for the work that they are going to do, versus front end developers, et cetera, right? And so, there are many, many different reasons. But it’s also interesting, because Java has been around for a very, very long time, huge base of developers. Not exciting, maybe, for a lot of people, but at the same time, totally stable and well understood, right?

And I think that one of the things that I find really interesting is the early stage of a company versus later stages of a company, right? As someone who’s mostly been involved in startups, and many of our customers are in that world, we want to get something to market really quickly, and use a lightweight, simple tool that we know and can can iterate on fast, versus now we have scaling problems. There’s a long list of large orgs today that started out on different stacks because that allowed them to move quickly, and now that’s not their biggest concern, right? It’s scale, and reliability, and those sorts of things.

Chris Richardson: Yeah. Well, also choices around technology, it’s specific, especially around newer, what’s adopting new technologies. There’s technical drivers, right? There’s logical, rational reasons for choosing a particular technology. But then there’s a whole lot of just sociological reasons as well. I don’t want to be too negative, but it’s like fashion, right? And so, there’s a mix of rationality around decision making, and then emotions as well.

Rob Zuber: Absolutely. And one of the things that, to that point, I don’t know if fashion is the point that I was thinking of, but technologies tend to bring entire communities, right? It’s not just, oh, I like this particular language, or I think this can solve my problem. So, there’s the community in terms of the support. We talked about Java having so many years of tooling, and developed libraries, et cetera. But also just styles and approaches. And you bring all of that with you when you make a technology choice to the point of the social element, that I don’t think I caught on to that as a younger engineer, and I definitely see it today.

Chris Richardson: Yeah, humans are emotional, social creatures. And in connection with people, it plays a role.

Rob Zuber: Yeah, I think it’s easy for us to forget in the world of technology and engineering that so much of what we do is based on the people doing it, and so little is the code in the end, right? It’s a reflection of talking about reflection of the organization of the people involved, individuals, what their personal preference is, it all shows up in your code, in your architecture by the time you’re done. So, one last parting question, I guess, as we talk about evolution and growing, and a lot about scalability and systems with independent teams, et cetera. So, one of the interesting things that I always see is, you’ve got this two person, three person project or startup, it could be in a bigger company, in a small company, it doesn’t really matter, and a desire to adopt all the best practices at the beginning to avoid having to make big changes later. And it feels like that ends up being very cumbersome, right? We can create a lot of complexity when we don’t even know what the thing is that we’re building yet, or whether there’s product market fit, however you want to think about that piece. So, if you were starting something new, what would you think is most important to focus on in your early build, and what would you defer until later and not worry about as you’re trying to just iterate and get something to market?

Chris Richardson: Yeah, well, I feel like you should build the simplest thing possible, right? And using whatever skills you… Assuming you’re building your own software, right, whatever technologies that you are personally familiar with, for the most part, right? Because certainly, I think part of it, if you take a step back, it really does depend on the context, right? So, some south of market startup, they start off generally small. And at some level, they don’t really know what they’re doing, right? You have to iterate and figure out what problem you are actually solving, right? Product market fit, and you pivot, and then eventually, you hit upon the right thing that then causes growth, right? And you don’t have any significant customers, right? And so, you’re not dealing with problems of scale. You actually haven’t written much code, so you’re not generally dealing with complexity either, right?

And so, just build the simplest damn thing that you’re capable of building in general. But then, there are many other different contexts for that, right? Imagine that you’re building something small, you’re building something inside a large enterprise. And for whatever reason, you know it’s going to be big, because maybe it’s serving hundreds of thousands of employees with inside the enterprise, right? Or maybe someone’s giving you a gazillion dollars of VC, and on day one, you’re going to have 200 engineers building some software, or maybe the domain is well understood, right? So, there is a giant it depends around what your initial architecture should be.

And I’ll give you another example, right? Imagine that you were building a medical application, where software… And the software development of medical applications is heavily regulated, right? Imagine it’s some cloud based product that’s controlling insulin doses, right, or something like that. You can’t do DevOps, normal DevOps practices. You can’t do canary deployments in that world, right? Because lives are at stake. But then it may be… So, there’s value in having a distributed architecture from day one, where the medical part of what you’re building is heavily regulated, right, and develop slowly using ISO standard, blah, blah, blah, and then the rest of your system is built using DevOps, right? And so, it’s a giant it depends.

Rob Zuber: Well, I’ll articulate that it depends the way that I hear it, because I think it’s a great roundup, which is effectively understand your context, right? It’s probably true for every decision you’ll make as an architect, as an engineer, everything else. You can’t just take what someone else has done or said is a good practice and apply it to what you’re doing. You need to understand the implications for your business, what matters in your business, what you’re trying to achieve, and then you can assess those things and decide what’s right for you.

Chris Richardson: Yeah. So, it just touches on something that’s very… One of the few things I actually am a fan on, right, and it’s this concept of a pattern, right? And a pattern is this reoccurring solution to a problem that occurs within a particular context, right? And so, it’s, how do we do X? And the solution that’s applicable actually does depend on the context within which you’re trying to solve the problem, right? So, you have to know the context in order to pick the right solution. And then not only that, is, another key part of a pattern or the consequences of the pattern, which are not only its benefits, but it also has the drawbacks as well as the issues or sub problems that applying that pattern then creates, right? So, in any given context, there could be multiple solutions, and each one has its own distinct consequences. And so, in order to enable you to pick the right solution, you actually have to think about stuff, to go back to your point, right?

Rob Zuber: I was going to ask you something else. I don’t know how to not end on you actually have to think about stuff. I feel like we’ll just summarize 45 minutes and you actually have to think about stuff. I said that was my final question, though I did actually want to ask one thing. Is there something that you’re working on now or that you see coming up that you’re really excited about that you want to share?

Chris Richardson: Oh, can we finish on you have to think about stuff? What do I do? These days, it’s funny, right, with COVID and the past however many months. I used to just travel endlessly and just be working with clients. And so, the past eight, or however many months, I’ve just been working with clients via Zoom, but it’s meant that I’ve not been jet lagged for the first time in about eight years. And it’s given me a lot of time to contemplate stuff. And in particular, one of the things I spend a lot of time thinking about is a framework for deciding how to choose between the monolithic and microservice architecture, right, which in my mind is just architectural patterns. And each one has consequences. Neither is an anti pattern, despite what you read on Twitter, right? And then also, if you pick the microservice architecture pattern, how do you take a pile of requirements and turn them into a set of service definitions? So, I’m working on, you could say, a methodology for doing that. Which is the most important decision that you make if the problem that you have to solve in the microservice architecture, but it’s also the most nebulous.

Rob Zuber: Right, right.

Chris Richardson: And it’s all to do with balancing conflicting concerns about, well, we want to have services that are team sized according to Team Topologies, yet at the same time, we have to take into account design time coupling, and also, where we got to minimize that, we have to minimize runtime coupling. So, there’s all of these conflicting forces that you have to balance when you design your microservice architecture.

Rob Zuber: Got it.

Chris Richardson: But you have to think. That’s the key takeaway, yeah.

Rob Zuber: I love it. I love it. I think that’s going to be the coda on every statement. It’s perfect. You actually have to think about it. Love it. Well, thank you so much, Chris. This was brilliant. It was just as great as I anticipated to have a chance to chat with you. I appreciate you taking the time. And thanks to everybody who’s tuning in and listening. If you enjoyed this, feel free to subscribe on any of your standard podcasting services. And if there’s something you want us to talk about on the podcast, hit us up on Twitter, @CircleCI. Thanks again, Chris, for joining me today.

Chris Richardson: Thanks. It was fun.