The InfoQ Podcast: Software Architecture and Design InfoQ Trends Report—April 2021

Introduction [01:17]

Thomas: Hello and welcome to the InfoQ podcast. I'm Thomas Betts, the lead editor for software architecture design at InfoQ on today's special episode, we have a panel to discuss this year's architecture and design trends. If my voice sounds unfamiliar to regular listeners to the podcast, have no fear because the first panelist is Daniel Bryant, news manager at InfoQ, and regular host of this podcast.

Hello, Daniel.

Daniel: Hey, Thomas. Good to be here.

Thomas: Next is another InfoQ editor, Eran Stiller. Eran,  welcome to the podcast. Please take a minute to introduce yourself.

Eran: Hi everyone. So my name is Eran Stiller. I am a CTO at a software services company based in Israel. I work for other customers or help them design their systems, architect their systems, moving to the cloud and all kinds of interesting things. I joined InfoQ a few months ago as an editor in architecture and design, and this is my first time contributing to the architecture and design trends report. So I'm really excited. Thanks for having me here.

Thomas: Thanks for joining us Eran. Finally, I'm excited to announce something new that we're adding to our annual trends report, which is contributions from the community. In past years, the various InfoQ trends reports were all created solely by the InfoQ editorial team. And today I'm very pleased to introduce Holly Cummins.

Welcome to the InfoQ podcast, Holly, and please tell the audience a little bit about yourself.

Holly: I'm really glad to be here. I have almost the same job description as Eran, but just working for a different company. So I work for IBM. And my official title is that I'm an innovation leader. But I've spent a lot of time in the IBM Garage and we're a consultancy organization and we do almost exactly the same things of working with clients, helping them move to the cloud, helping them get the most out of the cloud.

And then along the way, of course, we see lots of things that we think, "Oh, I guess I wouldn't have done it quite that way with the cloud." So we learn a lot as well.

Designing for ___  [01:47] 

Thomas: Great. Well, I'm looking forward to fantastic discussion. So architects in general are always trying to solve cross-cutting concerns. Usually people think of these as the "-ilities," like reliability. And in our discussion ahead of time, we came up with a short list, we think architects right now are trying to address when they're designing for cloud-native, distributed systems.

That shortlist is they're designing for resilience; designing for observability; designing for portability, whether that's multi-cloud or hybrid cloud; and also designing for sustainability. So the first one on that list was designing for resilience. So I'm just going to ask Daniel first. How do you see that people are focusing on resilience and what are they doing and why is it a priority right now?

Daniel: Great question Thomas. And I think, you know, over the last few years we've seen a definite march towards modular architectures. Now this, you know, we all know it's not new, right? David Parnass 1970s talking about all this good stuff, but the latest incantation around microservices and serverless means that all what was old is now new. And because we're distributing over the wire, typically we're building services and they are communicating over the wire. Now, when something goes wrong, not only does you know that part of the system go wrong, but you have the knock-on in terms of other dependent parts on it. And you've got the network in the mix as well, which can add just extra kind of problems. 

So I think a lot of folks are looking at resilience now are answered a sensible fault tolerant design patterns, a classic Mike Nygaard book, Release It. I've always got a massive hat tip to Mike Nygaard, like bulkheads, circuit breakers, timeouts, retries, all those good things.

And I think all of us now are realizing the importance of those things. Whereas when you built the monolith, maybe you could get away with not being quite so aware of that stuff.

Eran: I think I can add to that. Sense many times in the past, we had to build these things ourselves and it was very complicated, but as we progress, we get to more and more technologies that handle these things for us. For example, if we look at all kinds of service meshes, or Dapr, which we're going to talk about later, and they really take all of the burden from us needing to think about these things.

Obviously, we do need to think about them. We need to plan them in, but we don't need to get into the nitty-gritty details of how to implement them. And that can really save us as architects, as developers, a lot of time going to makes it easier as the technology matures.

Holly: Yes, and there's the time aspect, but then there's also just the getting it right aspect. Because otherwise without that assistance, it's such a minefield and you sort of go in and you think I'm designing this resilient system and then you actually run it and you realize you did the opposite.

Eran: Also, in addition to all of these patterns, I see that, in a lot of systems, people are starting to use queues and asynchronous communication. Now we had queues for a long time; they're not really new, but think patterns such as event-driven architectures, which I think become more and more prevalent, they didn't make building a resilient system much easier.

And I think it's propagating to additional systems, where we start thinking that well, if I use these patterns, I don't need to think about all these circuit breakers and, automatic scaling with load balancers and all those hard things. This is another something that will help us build more resilient systems.

Thomas: That's an interesting idea that some of the concepts like event driven architecture, that, again, isn't new, but one of the benefits that people are realizing now is, "Oh, it helps with this resilience need that I have." And I think the resilience ties into, a little bit, that next step of observability, because when you do have asynchronous communication, you might not need the circuit breaker to say, "Oh, it's not responding," because I can always throw another message on the queue. But now I have to watch and see, am I meeting my SLAs and SLOs? Is that message sitting there too long? And do I have to worry about my system getting slow and just slowly becoming you know, it's eventually consistent. It's not down, but it's just slightly wrong.

So that resilience, the system stays up is also tied into that observability. Like "Is the system still working?"

Holly: I was just thinking about the event driven architecture and I feel like we're, we haven't quite got there yet, but I think we're getting, we've been knocking on the door for so long. And I think maybe we're closer of, can I write an asynchronous system in a way that I can reason about it, even if I'm a mere mortal because that's the problem that we've always had with asynchronous is it looks beautiful.

And then you look at your system and you just go, it maybe made sense on paper and I have no idea what's going on.

And those developers just messed it up completely by actually writing code against my designs. And can I just go back to synchronous and you know, we're almost almost having the patterns that allow us to hold it in our head and have it actually makes sense and then be able to translate what's in our head to what we see at runtime.

Eran: I think that systems for observability actually help us build these resilient systems because, like Holly said, reasoning about what happened is so hard and that's where all kinds of systems for distributed tracing come in. And we start adding all kinds of headers and correlation IDs across the system. And once we have that running, reasoning about what just happened becomes so much easier.

Daniel: One thing I'll just chuck in the mix there is, I think, closer to what you were saying, Thomas, as well, backing up, everyone's saying here really is for me, observability and understandability are key, right? So a bit of a quite, you know, we've heard some folks that were understandability for many times, but me that observability is probably more of a runtime thing at the moment. And understandability, maybe more design time thing, because to your point, Holly, I've worked on some amazing like reactive systems, but understanding them even at design time was super hard. Right? And then I actually had to run the system, observe it and build a mental model that way.

So I think this sort of notion for me, I'm still chewing this I'm still having lots of interesting conversations, but understandability and observability are two sides of the same coin, maybe at runtime versus design time.

Holly: Yes, that's really nice.

Thomas: I think observability there's that spectrum of I'm collecting all the metrics and I need to be able to say, Oh, the server's under load, we need to scale out, and how do I automatically provision that. That's one level, one end of the spectrum. And then the other side is something went wrong and I need to be able to troubleshoot it and dive in deep, because we're always having to look at the details and you need to handle both cases at once. You need to have a system that allows you to do both of those things, that it's not just about scaling out. But also someone can reason about the system. So how do architects put that in from day one?

How do they build a system that provides all those things. And looking at the tools, and I think Eran, you mentioned open telemetry and other CNCF standards. Like here's the way people are doing these things. There are tools that can help us but, you still have to have that idea in your head of this is what I'm trying to accomplish and what are all those goals?

Holly: I think we're making more progress as well on the resiliency of our observability, by which I mean, does your observability solution actually survive contact with reality? Because I think in the, in the past, we've had so many that relied just on manual instrumentation and so they were there on paper, but then developers would forget to instrument one thing. And that was of course where the bug was. And so then we sort of ended up having to go back and retroactively, try and beat people up to, to make it work because it was too manual.

Eran: And I think once the system is totally observable, it becomes the best architecture documentation that you can have about your system. You can actually see which service is talking to which service; watch which operation goes, where, and in opposed to the, all the architecture diagrams that everybody forgets like a month after production, this one actually stays alive in someone comes in and can actually see what's happening in the system and understand it, like Daniel said.

Thomas: Right, and the system can evolve naturally, because if you're just publishing messages and people start subscribing to it, you don't have to go and update your document. You can just now see, these are all the subscribers.

Daniel: I've got to do a shout out to John Allspaw's work. He often says standing on the shoulders of giants and he talks a lot about the above and below the line mental models. Like the above the line is going to be boxes and arrows. But you need some way of actually poking below the line to test those kinds of things, asking ad hoc queries, for example, things like that, of your observability systems and, and going, is this mental model I've got correct. No, it's not. 

I've learned a lot from like John Allspaw, Jessica DeVita, Nora Jones, there's lots of amazing people in that space that we can perhaps put some links to. But for me, like mental models is really key as an architect, building them, sharing them really, really key.

Thomas: I do want to get to a couple more of these aspects. I think we could talk about this topic for an entire episode would be great, I do want to delve into the, the portability. I think. People talk about multi-cloud, and it's probably those things that CTOs, like the idea of, I want to be multi-cloud because I want to have that safety bucket, but are people really doing that?

Hybrid cloud seems more relatable that I have stuff that is still on prem and we're pushing up to cloud and it's nice to have like run Kubernetes the same way on both of those, those types of things. But we are seeing tools that help us get to the point where I can get to multi-cloud and maybe it's not  full high availability -- I can fail over from AWS to Azure, to GCP at the switch of a button. 

But, what are the use cases? Why are people focusing on this? What are the architects trying to solve?

Holly: It's something that I, I do see a lot in my conversations with clients and there's. For me, there's a few reasons that are coming up. One is the kind of the theoretical one of, as you say, I want to avoid lock-in or particularly for financial institutions, there's actually a regulatory reason to say, look, you just can't be too dependent on one provider because you're providing an important service to lots of people, so you have to have some kind of mechanism for fail over.

But then as well, I think there's, again, that sort of reality. One of there's always some reason why, someone you acquired is on one cloud provider, even though you've made the strategic decision to go to another provider or in this one region, for some reason their data center doesn't do what you need or their data center is missing.

So then you have to go to another cloud provider. So it just does end up always being a patchwork. Even if you had a vision of it being a bit more monolithic.

Eran: In the past, I've seen many customers want to have multi-cloud because they were afraid of vendor lock-in. And, at least personally, I always told them you ain't going to need it. I mean, you're not going to move cloud just because you're there because your data is there, your DevOps process is there. You're not going to flip a switch and move to another cloud.

But I think in the past year, or maybe even two, a lot of CTOs, it became more pragmatic and practical say, well, if I needed some services or another cloud, then I'll use it because it's a it's there, why not? And if I need a specific region for my data to reside in, then I'll use that because that's available.

And I really like the patchwork analogy because we use whatever we can, then we make it work together. And that's in a position to where we, you know, a lot of people will use the term cloud native to describe something that, you know, runs on every cloud. You know, we use Kubernetes, and it runs on every cloud in the world.

And personally, I think it's sometimes it's a bit overrated because I don't know a lot of companies who run really the same system on multiple clouds, but ironically, I think it's most suitable when you have to run your workload on prem, because when you have to run your workload on prem, then you can't rely on any cloud service. And then moving into the clouds, if you're running on things like Kubernetes and cloud native software, then it's much easier.

Daniel: Can I just chuck in the mix, like something you said in there Eran, made me think. So my background is Java development, and I remember like about ten years ago, when I was really the thick of it, you always wrote a DAO abstraction layer, but the idea being, you swap out your database, right? I've got mySQL in there, but I might want Postgres.

I must've wrote 20 of those layers. and Spring, made it a lot easier for me. But I think I swapped the database out once and that was a trivial use case. 20 implementations, swapped it out once.

I see folks doing that with cloud. Common denominator, often the lowest common denominator, and they're never going to swap it out.

For me, and it's going to bias the work I'm doing at Ambassador Labs, but where you want to standardize actually workflow. There's lots of tools. You know, we've got them, HashiCorp got them, lots of awesome companies. IBM. Everyone's got them, right? But that is actually more important, I think from the developer point of view, standardizing how you build the code, how you release the code, how you observe the code.

The cloud, like if you look a lot of HashiCorp tools in particular, the cloud you're running on the stands is the config is different, but the workflow is what's consistent. And that is where you spend a lot of your time, I think. 

So I would say to folks, if you are going to standardize pick the right battles.

Thomas: And I think the idea of, you know, Kubernetes is like one unit of work. If I have a Docker container, I can move that. It can be hosted wherever. It's when you get into the service offerings. Like if you're going to go serverless functions and you're gonna use Lambda, you're not just going to swap that out to Azure functions, right?

Maybe the code kind of looks the same, but you start using more of the provided services. It's what level of unit you want to move at. And that might be your architectural decision is we won't use those because we have this use case. 

Holly, I love the comment you made about people were trying, they had the vision of being more monolithic that the monolith is now your cloud provider, that AWS is your monolith, as opposed to, and so looking at multi-cloud as the new distributed system, it's just which utility service are you signing up for?

Holly, I think you're the point person for this one, but I want to talk a little bit about designing for sustainability. So, what does that really mean? Why are people focusing on sustainability and why is it important now?

Holly: I think this is an emerging one. Like we're, I think we're just starting to work out the best practices for, for this, but just like the rest of the world where we're looking at our industry and we're realizing, Oh, actually our industry is responsible for quite a bit of carbon. It's comparable to aviation, which, we sort of think of aviation as like the poster child for climate irresponsibility and actually we're about the same.

And then there's a whole bunch of conversations that flow from that. So part of it is. Is some of what I'm doing waste. And if, if we identify waste in the system, I saw it described today as a quadruple win because we usually waste causes our systems to go slower. So, we have too many layers of obstruction going back to your example, Daniel, or we just have bad code that's running cycles that it doesn't need to. So we get rid of that. Our users are happier because things are running faster. Our costs are lower because we're using less electricity, we're using less cloud providers. And by the way, we're saving the world, which is something that probably most of us, fringe benefit.

So then that sort of, I think it's becoming increasingly important that we should be looking for the waste and driving out the waste. But then once we've done that, then there's some, sort of, harder conversations, which follow on from that of, well, now that I've got rid of all the easy waste, is there anything more that I should be doing?

Should I be making a call about, is this worth doing so for example, with AI, there's a lot of conversation about how incredibly energy hungry AI is, are all of the applications of AI actually justifying that environmental impact. Some of them almost certainly are. Some of them, maybe not. And then once you've done that, then you can sort of go around to the waste to gain.

Because the thing about waste is it always creeps in, so you do one pass and you get rid of the waste and then just inches back in. So then, it's a bit like technical debt of any kind that you do a pass and you get really nice and clean, but then it comes back in. So then you have to make a call to say, well, how often am I going to look at this?

Am I going to have a really clean code base? Am I going to have a really environmentally clean code base or actually. Am I going to be more pragmatic and every now and then look at it.

Thomas: I think that ties back into the observability requirements that having your, your energy consumption be, you know, something visible. A lot of people think about the dollar amount. Like you get your report at the end of the month. Like here's how much you spent and here's your bill, but it'd be nice to say, "And here was your, you know, your carbon footprint," and you can see, oh, this service that was running it, wasn't the, we're going to turn it off for 10 hours a day. Because no one's using it because we'll save money, but we should turn off for 10 hours a day because we're just wasting, you know, we're leaving lights on an empty room and having that as part of your, your system.

Would just be a good thing to build a report. I think you're going to start seeing companies have that as one of their goals and a lot companies do have sustainability goals now. And so this is one of those ways that the software could help them achieve that.

Eran: Yes, but I think that one of the key factors here for success is that one we're talking about the cloud, there's a pretty high correlation between carbon emission and cost.

So the more you spend, the more you waste money, the more carbon emission you cause. And if you save money, you save on carbon emission. So I think the cloud actually makes it much easier to design for sustainability and it gives you that incentive to invest in it.

Thomas: Right. So even if we don't have a specific metric, it does have that secondary effect. Like you can say, Oh, we're saving money. So we're saving it because so much of it is compute-driven.

Holly: You get that sort of easy first order metric, which is the cost, which you're so right. You know, and it's really visible. And then there's kind of a second order metric, which is. I think at the moment, we're not really doing a good job of getting surfaced. Then that goes back to the observability question of depending where I run my workload, it could be actually running on a hundred percent green energy, or it could be running in Virginia, on coal, and that's going to be really, really different.

And so how do I know? And then once we've sorted out the observability, then it goes back to the hybrid cloud multi-cloud portability, which is, well, actually, could I take my workload and could I move it from Virginia to Iceland because there's no reason for it to be in Virginia.

Daniel: To that point, Holly, I've heard you say this, and also Anne Currie is, a lot of the cloud vendors are very customer focused one in particular who shall remain nameless, right, its customer obsession. Ask for it, as a customer. If you care about this stuff, if you're caring. Well, I think care about the future, right?

Like ask your vendor, say, Hey, how much of this stuff is running on clean energy? When you break it down, Amazon have got better at this, for example. I know Azure published some stats, GCP, I think a lot of the cloud vendors do, but if you care, I would say to folks raise it as an issue when you're having your technical account manager chats say, Hey, we care about this kind of stuff, can you give me some insight into how your services are powered?

Holly: Yes, for sure.

Correctly-built Distributed Systems [20:40]

Thomas: I want to move us to the next category of topics and this, there's a banner of what I would call correctly-built distributed systems. I think distributed systems, microservices are not exciting anymore in and of themselves. Like that's so far down the spectrum of across the chasm on the architecture trends report.

But we've seen that pushback when we saw, you know, one of the big articles last year was about a conference presentation of our journey to microservices, and back again. Like companies have gone all the way, had enough pushback and said they didn't solve our problem because they're meant to solve a different problem or they cause these other problems that we weren't ready to handle.

And that's led to a few different design options surfacing. One of them was the modular monolith that you can get a well-designed monolith. Self-contained systems that you don't think about individual microservices so much, you start packing them together into units of work that teams can manage.

Serverless, I think falls into that. Like where does it play a role? And then obviously tools like service mesh and other, platform level features that are helping us build distributed systems. What are the things you guys are seeing as big trends around the banner of how to correctly build a distributed system in 2021?

Eran: So microservice is, like I said, definitely not an exciting topic anymore. I mean, a lot of customers, they come to me and they want, they start saying they want to build microservices and people do still come and say they want to build microservices because it's cool because it's hard because everyone's talking about it.

And usually the first question I ask them, when they tell me that is why, why do you want to build microservices. And some of them give better answers. Some of them give worse answers, but always I get down to the fact that they need to consider all the bad effects that this will cause. For example, if you're a team, if you're a startup and you have a team of five members and you want to get to the market very fast, don't do microservices.

Don't build a system with 20 microservices on five developers. That's not going to work. That's not the way to get to market. And more and more I see use of the modern monolith pattern that I promote with my customers a lot, especially when there is this, the only starting they're a startup. They're very smart.

Okay. Keep the benefits of being able to split it up later into different deployment units. If you'll have to and try to avoid big couplings that become the big monolith. For example, don't have a single database schema with all the references between all the entities in the system. You won't be able to break it up later.

So do think about it in advance, but. At least don't pay the costs upfront. And that's where the modern, modular monolith pattern comes in and I see more and more developers and architects use it and employ it.

Holly: I was going to say one of our IBM fellows has a rule for the why question, which I love, which is he asks why. And if they start talking about coupling and cohesion, then he knows they're on the right track. If they just say Netflix and then say Netflix again, he knows that maybe he needs to do some coaching.

Thomas: I think the, the way I think about the modular monolith, I came up from, you know, N-tier architecture, you have your data layer, you have your business layer, you have your UI, and those were your, your separations. And once those all spread out and everything gets wider, it is impossible to then separate it out.

So it's really just that take the design step up front. We know what good reliable systems are. We know you might want to get to microservice. You might want this little bit to scale out differently. You can design that in now, so that that little piece can be easily carved out as opposed to, that's gonna take us six months to a year to just do it, and then it never gets off your to-do list.

Daniel: I think to Holly's point. I always like coupling and cohesion are always on my lips, regardless of it's testing. If it's building whatever I've got to think. I think a lot of this comes down to just good fundamental architecture principles, but I often recommend to folks that if you haven't bumped into domain-driven design, check it out.

If you haven't bumped into context mapping, in there, check it out. And then to your point Eran, and it's just building. Well architected systems, right? Encapsulation, information, hiding, clear interfaces, abstractions, facades, all these kind of good stuff that I'm being there back when I was just at a college or at a university, I obviously read Head First Design Patterns, which is still a fantastic book, recommend it to everyone, but it was more approachable than the kind of gang of four thing. But it really taught me that a lot of this stuff is just, yes, fundamentally good design is taking a moment, recognizing your goals, recognizing your constraints. There is a series of best practices that like are almost, that can be used regardless of technologies and just taking a pause. And I really liked your pitch there, Holly, because I definitely bump into people that just say Netflix, Netflix, Uber, Netflix.

It's just like, "Hang on. Do you know what coupling and cohesion is?" And if they say no, I'm like, right. That's that's the season, not everyone can know it's fair. We all start from a point of not knowing things and I'm like, let's break it down. Let me teach you this stuff first. And then we'll look at what Netflix are doing.

Holly: I think we sometimes assume, or people sometimes assume that the microservices are going to enforce the good design and that, because it's distributed, then once you're distributed then you're automatically going to be decoupled. And of course, it's just, you know, if you didn't know how to decouple it before you distributed your system, being distributed is going to make the coupling more painful, but it's not going to make the coupling any less.

Thomas: Right. I'm glad you brought up DDD, Daniel, because I think DDD saw this resurgence about four or five years ago. There's now, you know, there were like two or three big conferences around the world just on DDD. And it really was this book that was written 17 years ago, I guess, 18. And, and it was like, okay, here's how you handle complexity in very large software systems and it took microservices to become the thing. And if you're like, Oh, but my microservices don't work well, did you do it right? Well, how do I do it? Here's the one example of how to just again, do context mapping. Here's how you break down and think about where you're bounded context in your system.

If you get that right. It doesn't say it has to be microservices. DDD was written decades before microservices became a thing. So it's just saying, here's how you encapsulate your system. And that leads to a good distributed system. 

And going back to earlier point, if you want to do event-driven architecture or just have more queues and more asynchronous processing, you can look at that and say these services, these are our boundaries.

Here's how they should communicate. It doesn't enforce good practices to Holly's point it, but it allows you to take advantage of good practices. If you have the things broken out correctly.

Eran: Right. And I think that for many decades really all want to achieve as architects is high cohesion and low coupling, and we did it with classes and then components and then with assemblies. And I think we have the pedulum swings, all the way to microservices, where we have a lot of small components.

And I think the pendulum is swinging back at the moment. We'll go to less components. Each component is bigger, but we'll learning from things we've done in the past and the platforms are catching up on what we can do with them. And I think we'll probably find a balance there. Something, of course, every system has its own needs and an enterprise is not like a startup.

But we're starting to understand, well, what we did wrong with microservices and the problems they introduce. And we start going back into a more, let's call it a sane approach for most systems.

Daniel: Can I just chuck in on something you said there and really resonated me in that. I just want to share like the C4 model. So Simon Brown's C4 model is something I recommend every time along with like DDD and so forth, but something I heard you say there was around sort of it's like turtles all the way down, right?

It's cohesion at system level cohesion at the application level, at the service level, at the module level, you know, these kind of things. And if you learn good practices are often applied down the stack and. Lucky enough to know Simon quite well. But when I met him like 10 or more years ago, now I remember him explaining that to me.

And I was like, "Oh yes", and the C4 model is a really nice vehicle for understanding like the four Cs. And I'm probably going to mangle them. So apologies Simon, if you're listening, but it's like context. Oh, I'm not going to go there, but there's four Cs. And, I have to look at the diagram, but I show folks every time it's fantastic for building that mental model around it's turtles all the way down, but it's exactly what you said Eran, it's always high cohesion, low coupling.

Data Architecture [29:05]

Thomas: I think that kind of wraps up the distributed systems. One thing that's at least I've seen a lot of stuff on InfoQ that I've been working with lately is how data architecture has been flowing into the domain of just software architecture. And I think some ways this was one of those, Oh, well, we'll let the data architects sit over there, and they'll handle reporting or ETL or whatever it is. And we're having to do that shift left. Like we have to start thinking about how does all of our data work within the system. And it's given rise to some of the same terms you see for other software patterns, but now with data thrown in front. So we've got a data mesh instead of to go with a service mesh.

We've got data gateways to go with a service gateway. We've got data ops to handle it. But I think it is influencing design. What have you guys seen where data architecture has kind of taken a more front seat to how people are designing their systems?

Daniel: I think one person I'll shout out straight away is Zhamak Dehghani, like with the data mesh paradigm, and then she's standing again on the shoulders of giants, but we've had her on the podcast. Zhamak's talked at QCon as well, and she's bringing a lot of well-established principles into the ETL, the extract, transform load, and data modeling and, and all the other good things associated with that.

Things like design thinking. Empathizing with your users, that to your point, Thomas, I've seen many systems, I've worked on many teams building systems that data was just the thing you collected. And it was there. Like it didn't, there was no like, "Hey, how are we going to use this stuff? It was put in the corner, it will be fine."

And put it in the data warehouse. Whereas Zhamak and the team at ThoughtWorks are really saying, no, no, you just empathize with your user needs. And then that often leads onto ownership or who's best to own this data. Then they can make the best decisions on where to store it or things like that. So a lot of it, for me, it's actually cultural sort of like more, the people level.

We've gotten a lot of great practices from the architectural point of view, but it's recognizing all the good things we think about sort of in terms of the "-ilities" perhaps at the architecture level, but now for data and I definitely read, we should put in the show notes, a bunch of links to Zhamak and the team's work, but it's just a gold mine of being able to change the way you think about architecting data systems.

Thomas: I think it's some of the stuff about data mesh is also into that vein of high cohesion. Like you want the data to flow through for the needs that it needs rather than, well, we have this big pipeline in the middle and everything has to fit into it or come out of it. And then it naturally creates a bottleneck.

It's the same problem that we were using microservices to solve the, we only deploy every three months. Well now we can only upgrade our ETL pipeline every three months because it takes, 27 people to get involved and so many meetings. So having smaller teams that focus on specific use cases and having a platform that solves that. 

Data gateways are the same way that you provide interfaces that get to the, the needs that you have for your specific use case. And I think again, high cohesion for data is specifically around that rather than it's just that thing that's down at the lowest level of your system. It's more important. That's kind of why some of these systems exist to begin with. 

Daniel: I think on that note almost. And Bilgin, one of your colleagues, Holly, Bilgin Ibryam, fantastic article on InfoQ around data gateways, because it is tempting, you alluded to Thomas that almost sort of the data mesh data gateways. Someone just, you know, DevOps washing something, cloud washing something.

But, naming's hard. Right? A lot of these things, the concepts are really key. So, we're obviously biased, but they are InfoQ leanings, but Bilgin is a deep thinker in this space. And that data gateway article, I was like, "Oh yes, all the stuff I'm doing day in, day out my day job with API gateways totally makes sense in the context of data."

And I thoroughly encourage everyone to read the article. Because it's not just API gateways for data, it's something different.

The Role of the Architect [32:49]

Thomas: I think that's actually a good slide into the next thing I wanted to talk about, which is what is the role of the architect? I think Daniel, you said earlier boxes and arrows. One idea is the ivory tower architect that just here's the design go forth and do it. And we've had on the architecture and trends report for a while, now, the architect as technical leader. That you're more engaged with the team you're leading the team you're coming up with here's how to mentor and help give the design responsibility to other people than just one person sitting by themselves.

And so Daniel, you mentioned a few times a presentation about the architect elevator, and wonder if you can expand upon that.

Daniel: Gregor Hohpe's work. And apologies, Gregor, if I've not said your name right there. And then now I had to struggle with names sometimes, but his work is fantastic. The architect elevator, a fantastic book and talk. And it's something I've definitely done in my role over the years from developer to CTO and all the roles in between, is being able to meet people where they're at.

It's the same story. Typically, whether I'm working in the trenches, coding or setting like a C-level strategy is fundamentally the same story, the same goals, but empathizing with the level of folks are at, to align everyone. And Gregor talks a lot about this architect elevator, like the classic, you know, Lift elevator, depending on your state of how you're.

So looking at these things of you need to ride that elevator so that you're comfortable talking at the board level, or the reason we've chosen this cloud strategy is because of these constraints, these goals, then you also need to be able to ride the elevator down to the engine where they kind of.

Sorry, the engine room where the work gets done and say, "Hey, we're going to be using Terraform for our workflow, because standardization of workflows is super important." But I think it's very tempting early in my career. I spoke with one voice all the time and I didn't always recognize my audience. And I think that's part of just maturing and thinking.

When you move into a leadership role, you really have to work on those listening skills, those empathy skills. Meeting folks where they're at and that Gregor's work for me, it's just a timeless classic of realizing that as an architect, these days, you are going to have those C-level conversations. You're accountable, but you're also accountable to your team that are doing the work at the, at the, sort of the face of the actual code.

Eran: And I also think that as an architect, we need to work with the team members and understand what they're doing and understand where their pains are. Because if you don't understand it and you come up with designs that no one can implement, or they're going to have a hard time doing it, then eventually these developers, they won't come and talk to you.

They won't come and ask you questions. They won't listen to what you have to say. So you always have to keep your foot on the ground and understand technology, understand where are the problems. And even, I 100% believe that the architects need to do some of it themselves. To understand the issues to understand the problems.

And like you said, being able to go up to the C-level strategy and explain why we're doing some things. And part of these explanations come from things that come from the, from the developers themselves.

Holly: I think there's sort of a few options for, for team structures. So, one is the one that you sort of described, Thomas, in terms of you have an architect and they, I was going to say outsource, and that's not the right word, but you know that a lot of the design decisions are actually handled by the developers because it's a fairly flat team.

And then there's the other option, which is maybe the one that we're sort of more used to classically, which is the ivory tower. And, the developers are very junior and the architect is sat much closer to the central strategy team and they're paid a lot more and they have a much better understanding of the strategy and, each of those models has different advantages and disadvantages in terms of how you're able to do your hiring and that kind of thing.

But I think going back to what you were saying around, in both of those models, you do need that feedback between the developers and the architects. And even if the architect has paid way more than the developers, the developers are going to know things about what works and what doesn't work and what worked really well on that piece of paper and is actually a nightmare to implement because the API just doesn't make sense and that kind of thing.

Thomas: I think one of the things that architects are always known for is the diagrams. Like you create the diagrams, and we've had articles on InfoQ about how do you create good architecture diagrams? What does it mean to actually have stuff? And one of the things that surfaces is that they need to be constantly updated.

Well, somebody can't sit around and just be watching the system. We talked about the observability being one way to have the system kind of design that. But one thing I liked was the idea that the boxes and arrows weren't a Vizio diagram that was shared around it was the whiteboard in the conference room that everyone could point at every day for standup and say, I'm working on this part of the system and we're editing this.

Maybe the architect of the first draft, but then the whole team can get around it. And that's just a collaboration point. It's just one more tool that you're using. And that's where the architect can come in and say, I'm going to help start the conversation so that it's not the blank slate, a blank whiteboard.

And then as it evolves, then the people who say this didn't work because of this reason they can edit the diagram, they can edit it. And it's not that the diagram itself is important. It's that tool for communication. How does the design get better? Because people can talk about the design and what's not working.

Daniel: I like that a lot. Let's just very quickly say ambassador lamps. We use the Shape Up process, which came from Basecamp and 37signals, those folks and sort of role as the architect in that domain is very much communicating the business goals and we say, Hey, these are the constraints is the business goals.

And we let the developers, we hire smart people and let them do their thing with the constraints. So I found that really interesting journey because the role that that architect has to do is probably more people and business than actual technologies. But it also means that everyone owns a stake in the architecture.

As you said, I've seen this with like other teams I've worked on too. Whereas the developers, if they're, if the architecture responsibility is taken away from them, they don't. Buy into it as much then for, I don't care as much. So I really like this Shape Up processes, a little book. You can download it from like Jason Friedman and the 37signals crew.

It's a really nice way of like understanding how to structure autonomous teams with architectural guidance and something you touched on that early on Eran, if you haven't got product market fit, I found Shape Up a great way to get product market fit really well. Cause you're just exploring your domain. You don't know the domain that well, so the architect role is very much like just, "Here's the constraints. Here's the goals.

Holly: One of the other ways that you can slice it, that, which I think is probably closely related as we sometimes say the architect is responsible for the "-ilities." So again, going back to that, sustainability, going back to that security, that portability, they're going to own the choices at that level, and then everything else, the developers, again, you hire smart people that are going to be able to figure it out.

Thomas: That's a good segue into, I wanted to briefly talk about, this is after 2020, we've been in a pandemic. We've had shutdown. We've had everybody's working from home. It has to get discussed. I don't know if it's really influenced architecture so much directly. But I think this is the point where it has had an influence, is that because everyone is remote, it has made that communication much more difficult, and we're trying to find ways to communicate the problem. 

I can't just go into my conference room and point to the whiteboard every morning. It's not available. I can point to my whiteboard, but no one else is going to see it. 

Holly: And they definitely can't update it. We can't come in and cross it off and go, never use this tool again.

Thomas: Yes, if you show up in my house and start updating my whiteboard, that's a different conversation. So what other things, I mean, it's kind of a broad topic, but what have we seen just in the state of what happened in 2020 as influencing architects and, and the role of an architect and how we talk to people and how we do our jobs.

Holly: Just going back to, to what you were talking about Eran, about the communication. I think one of the good communication mechanisms for an architect is that eavesdropping, and is hearing what's going on. So if they're sat in the same room as the developers, and they can hear that the developers are having an absolute nightmare because of one of the choices that the architect made, then the developers don't need to come and complain that the architect already knows and can say, okay, let's look at this again, maybe something wasn't right. But if it's remote, then it just makes it easier to get wrong. Decision's not actually discovered until it's way too late.

Daniel: Think good, good Slack to spin or insert your IM here, Teams, other ones as well, because that's something I've definitely noticed. We've been doing a lot more than last year. Holly, we're communicating like almost eventing to some degree, I'm doing this, I'm doing that. And I haven't got a. Yes. I read every message.

I scan them and like, Oh, my team has chosen to do that for this reason. And we try and capture some of the bigger things in the architecture decision records, I think super, super useful. So the one thing I think COVID has done is if you wouldn't, if you used to run on tribal knowledge, that gets a lot harder.

Now I've seen a lot of chatter on the interwebs in general folks are being more disciplined in their communication tool. They're capturing things. Using architecture decision records, they're updating their GitHub readmes a bit more. So I think there's kind of broadcasting because I totally get what you're saying, Holly, like in an office by osmosis as an architect, that's a key skill, right?

You listen, you sort of take the pulse of the water cooler. You have to do that in Slack, now. You have to do that in Teams. You have to Zoom and I think, and also capturing some of the artifacts for async consumption too. Cause I work in a distributed team across even we asked chatting here, we're across like, four different times at three different times zones.

So yes, that's a common thing these days.

Eran: And I think also the role of tools is much more important in collaboration. So for example, Thomas mentioned the white board. That we can just come in and work on it together. We have to use something as part of Zoom or Teams or whatever, or for example, tools for design review, or code review that some suddenly much more important because these, this is my way of knowing what is happening, what is going through the system?

What are the choices that are made when I'm not there? Because, like Holly said, I'm not sitting next to the developer. I'm not in the next room. They can call me, but it's an extra step. They only do it if they really have to. 

So all of these collaboration tools and the culture around them for mainly design review or code review, I think they have a much more important place in a remote work environment.

Daniel: One thing. I'd also chuck in like shameless plug for QCon here. Many of us involved in QCon or spoken at QCon as is fantastic, is I have missed the spaces to discuss with like-minded folks, yourselves, all included. We've had to arrange the podcast to chat, whereas before I probably would have bumped into you at a conference or bumped into you to meet up, those kind of things.

So, it's not just architects it's as many folks. It's a subtle thing. I think. We're quite privileged here. We've all sort of got capital, so to speak architectural capital, but, and we're drawing down on that as the year goes on and we're doing little odd coffees with folks on Zoom and things.

But imagine if you're new to the architecture space and now you can't go to these QCons. You can't go to these other conferences to learn by osmosis from, from peers and from luminaries in the industry, right? So I think that is something we're going to see ramifications for later down the line.

It's sort of like, without getting too deep here, it is that kind of missing generation fear, right? We might have to work a bit harder with, with folks to make sure they're brought along on the journey because the stuff that we all took for granted by being again, very privileged to go to conferences and network and things, that's just not happened that much last year.

So that's something definitely on my radar as I'm helping out with QCon Plus it's coming up soon now, trying to think about how do we make sure we're covering all the things and providing spaces for folks that talk about the things that we're not covering. Or to go into more depth. So I think that it's going to be interesting the next few years.

Thomas: I think that's, that's where that "architect as technical leader" surfaces, because you have a role, you're not the only architect at your company. There's going to be someone coming behind you. And that's where mentoring comes in. Who has that little interest that says, I like thinking about those problems. I like the idea of thinking about the -ilities. How do I get more invested in that? And if you have been fortunate enough to go to a QCon and the hallway track is, a main feature and we've got it at QCon Plus and the InfoQ live. But it's still that extra step of, I have to click on the link to go into the next room and know that that's a thing. Versus at QCon, you just walk outside and people are having a conversation. You can just like stumble by, hear it, and that can be like the biggest moment you have in the week. You lose that. It's the same thing that you lost when you had the water cooler osmosis. We're not getting that, but then the next generation is also losing out a little bit.

So it's something that I think we can be cognizant of and try and address going forward. Find ways to help our teammates. 

Dapr and the Open Application Model [45:24]

So there's a few items on the architecture trends diagram that I just wanted to briefly touch on. There's a couple of new things we're adding this year that are just starting to get talked about. We don't have a whole lot of details. Maybe we go into them and then some stuff we added last year that it's just naturally progressed along.

So a couple of the new things. I wanted to talk about, I know Eran you've covered, this is Dapr. You mentioned earlier, and just open application model. So what are those and why are architects caring about it now?

Eran: Right. So Dapr and open application model are two technologies that Microsoft introduced I think about year and a half ago, maybe two years at the Build conference. And open application model. I actually, I haven't heard of it. Haven't heard of it a lot lately, but Dapr just became generally available, I think a month ago or several weeks ago.

I think Dapr's very interesting, because for those of you who don't know, Dapr, it's like an abstraction for writing distributed applications. So it abstracts away all kinds of aspects like state management and service invocation and the mess and the pub sub and message brokers. And the idea there is that it's very similar to a service mesh, where, you'll run a sidecar next to each one of your containers. It's running in Kubernetes. So on a sidecar next to each one of your containers. And you interact with it either via HTTP or grpc, and you can interact with it, either directly, via the service API, or you can use an SDK and they have SDKs for several tools.

But the nice thing about Dapr is that while service meshes, the focus on the networking aspect, maybe a circuit breaker pattern or something like that, Dapr focuses on the application aspect.

The user for Dapr is an application developer. So as an application developer, you say, well, I want to have state management. I want to install something in database so we can use Dapr's abstraction, and then via configuration, you can configure it to use, let's say one, you're on Azure. So you want to use cosmos DB, and now I'm switching to AWS and you can switch it to use Dynamo. Or you want to use one, one broker and change it to another broker. You want to add all kinds of policies regarding circuit breakers, load balancing, and such. And, what I really like about it is that since it's an application level framework, it supports me in things that service meshes can't.

We talked about observability and tracing. So once you have that infrastructure pipeline in the middle, it can really help you innovate and move your architecture forward at a greater pace. And I think it's a unique project. I know that Microsoft are working, they want to donate it. They offered to donate it to the CNCF, to the Cloud Native Foundation.

And I really think that this is a project that's it's worth looking at and seeing how it grows and how it matures.

Thomas: I haven't seen anything. That's like, this is the test case. Like this is the big system that's built on Dapr and that's what powered it. But I like the idea that it is solving, it's providing that platform. So I don't have to think about service meshes. And we've been trying to abstract that away in different ways so that every developer, every microservice doesn't have to think about, and now I have to add my service mesh, I have to have these side cars. Like we're trying to solve that class of problem. This takes it one step, a little bit above it. It'll be interesting to watch the space and see what happens in the next year or two, if it gets adopted.

Holly: I agree. And I was just going to pick up, Eran, on what you were saying about the, the policies. And I think we're going to see more and more with Dapr or, or whatever else, trying to bake those policies into the applications so that the developers don't have to be thinking about it. And so that we can change it at a higher level.

Eran: From an architecture perspective, I think Dapr is the implementation. I think the idea here is like an application-level service mesh. So if you look at existing service meshes, we'll deal with networking concerns such as Istio or one of the other service meshes around. Maybe if they start focusing more on the application developer and start going up the stack. I think, that'll be an interesting trend to watch.

Thomas: It's kind of like moving from doing your own Docker to, I now manage Kubernetes and, you hide the implementation details. 

I think it's also important. You did mention the idea of switching between Azure and AWS. Like Dapr is possibly going CNCF, but it is not Azure specific. Microsoft created it, but it's not. I also want to call out because this is a podcast and it's audio for talking about Dapr, D A P R, not to be confused with Dapper D A P P E R or any. I think there's a couple other Dappers out there, but that specifically what this is, and we'll have a link in the show notes. 

WebAssembly [50:20]

Kind of another, maybe not quite related, but another interesting idea is there anything to talk about with WebAssembly or server runtimes that we're seeing people architect applications differently because to take advantage of those technologies and not just solving it as a front end issue, but actually making it part of the architecture to have a web assembly as a main feature. 

Holly: Was there sort of silence? Because I feel like web assemblies are really cool. And when I heard about them, I was like, yes, this is very cool. And I still feel like I haven't seen, a case study come by for something really big that was built using WebAssembly. And again, I don't know whether that's a reflection of uptake or.

Eran: I think WebAssembly's still pretty young, so there's not a lot of usage around it, but I really think it's promising on the idea that it, at least on the front end side it finally gives them an alternative to using JavaScript in the browser where today we can only use JavaScript or TypeScript or whatever super set that we have on top of it.

And WebAssembly actually provides a standard way to use other languages to write web applications, whether it be Rust, or C++, or C#. And I'm sure other platforms will come along as well. And that's a really interesting approach to maybe writing web applications in maybe in a more convenient way, that performed faster.

Again, we have a lot of tools today in JavaScript, so it's not going to be let's change all of just all the JavaScript, in that system in one day, it won't happen. But the idea that if you're a Rust developer, a C# developer, and or again, another platform and you want to write a web application, it's very convenient; it's very appealing to use. 

Now, if we look at the server runtimes that are growing, such as WASM, I think WASM was one of the runtimes that we wrote about a while ago. I think that that's really still an innovative technology. I don't hear or see a lot of people using it, a lot of developers using it, but I think it's a promising technology in that, that today we use Docker for containerization because that's what we have. And it allows us to easily deploy software components and build microservices and distributed systems because we can deploy our components in a standard manner. But if we would use WebAssembly, it will give us another native way to deploy our applications, but with much less overhead than what Docker actually provides. And Docker has its limitations because Docker is an abstraction an abstraction over the operating system and there are security issues. There are all kinds of other compatibility issues between platforms. While WebAssembly was actually designed from the get-go to be cross-platform and secure because it was supposed to be held in the browser. And I think that'll be an interesting technology to watch in the server space, as it matures and gains more traction.

Holly: And just going back to what, what you were saying about the advantages of being able to run the same language in the front end and the back end are quite significant, not necessarily architecturally, but in terms of how you structure your team and how you structure your releases. Because I remember, when NodeJS first came out, I'm sorry to say that I was one of the people who sort of laughed and said, why would you want to run Node or JavaScript anywhere, but actually then I really grew to love it as a platform.

And I think one of the reasons that it's so good is partly actually the strength of JavaScript as a language. But it's also the fact that you can, it creates front-end full-stack developers, so that rather than having a front end and a backend developer and having to have this really elaborate choreography for work to say, well, the front-end developer does this, and then the backend developer does this, and then they argue about the API and then it goes to the project manager. You can actually just deliver the capability, get it out to your users faster, which is what we're all trying to do. Really.

Thomas: I think where, WebAssembly might fall down a little bit, in terms of the InfoQ trends report is that we it's an innovator trend, but I personally have seen, more people that are interested that are enterprise developers. Like I'm writing internal applications for my company. I'm not writing Netflix. I'm not doing Uber, right? I'm not doing this massive system that has to be compatible on all the mobile devices and every website. It's like we have a captive audience and that's where you may have had old internal applications that were written. And this is one way that, maybe they used component vendors to make a nice look and feel for their website.

I know Blazor has been a big adopter for getting all the component vendors to say, okay, we're going to create components and they can now use that same model of how they did development before. Those, again, keeping the, the full stack developers. I know C# and now I can write efficient web applications and it's just that distribution model has been solved.

So I think enterprise applications tend to not get the shiny luster that, that some of the public unicorns do. But there's obviously a big market for people to use those technologies. And this is one where I think it does solve that class of problem. 

Next-Generation GraphQL [55:44]

One of the things I wanted to get into a little bit, GraphQL crossed the chasm. Last year we moved over to the early majority on this side of the chasm. Because GraphQL has kind of gotten adoption. But what we've seen in the last year or so is. Almost the next level of GraphQL. 

Again, Netflix gets mentioned for this a lot, but they're doing GraphQL Federation. That we now have systems where GraphQL is a fundamental part of the architecture, and we have so much of it, we need to then federate it across and solve new levels of problems that our APIs, because we have microservices everywhere, are too complicated to understand how do we manage that problem? 

Have you guys also seen other things with GraphQL, taken to the next level.

Holly: I've been seeing a little bit of pushback on GraphQL, actually. A bit like all of these things, there's the pendulum. So now that it is in that sort of majority adopter status, I am seeing more people saying, well, actually it solves this problem really neatly, but it creates these other two. And maybe let we need to be revisiting this and having the conversation about what the trade-offs are.

And then I think that does tie into things like the Federation where we then say, okay, actually the solution to this problem is to invest in those extra layers and do the things like the Federation. Sometimes.

Eran: I think we mentioned Netflix earlier, earlier when you talked about microservices and I think Netflix is also the poster child of GraphQL and using GraphQL Federation and GraphQL microservices. And like Holly said, I really like what you said about the fact that it solves a hard problem, but it gets others.

As an architect, I believe that we should use the correct the right tool for the job. And I don't think it's necessarily, we'll use either rest API or GraphQL APIs. Sometime. Sometimes you need both. Maybe you want to create a public API that should be interoperable and you want, I want to use easily for standard mechanisms, and then you choose to have a rest API. But you also have an app that you want to innovate very quickly, and you don't want the front-end team to be reliant on the backend team creating the appropriate REST-shaped calls. So you use GraphQL for that. 

And I really think there's a future for both technologies side by side, because GraphQL really does solve a problem, which is hard to solve at first. You can really innovate on front ends very fast when you have GraphQL. But REST has its advantages. Like everything architectures it's a trade off.

And like I say, it depends a favorite sentence.

Thomas: I was amazed. We had ...

Holly: ... for you to say it depends.

Thomas: Yes, we've gotten an hour into the podcast before someone said it depends. 

I think if you're saying I'm using GraphQL, because Netflix, then you're probably doing it wrong. They do have a different class of problem. And they're solving it. And so they had to push through to the next level.

They didn't back off. They said, okay, we're committed to it. We're going to have GraphQL Microservices. We're gonna have GraphQL Federation. And I think that's where it's a good innovator trend to see, okay. It solves this class of problem. When we get to that, as that's our problem, we can follow in their path.

So it's something to watch. I think we're going to see a few more things hang off the GraphQL Christmas tree, if you will. Even if graph QL itself has gotten so far over, it's now like microservices, that developers said, Oh, we did it. We shouldn't have. We're coming back.  And you find that happy medium. And that's how systems evolve.

Eran: So, by the way, for example, one of the systems I'm personally working on currently is a modular, modular monolith. We discussed it earlier. And it exposes a GraphQL interface. And one of the things that we are considering for the future, that if in the future, we'd like to transition this modular monolith into a microservice application, then the GraphQL interface could become a federated GraphQL interface.

And so we liked the fact that we have that option. And again, we see that something that's possible for the future in a microservices architecture. But I really think the tools are not quite there yet for broad usage. If you're not Netflix.

Thomas: I think this was a great discussion. I want to thank Daniel, Eran, and Holly for all their great insights and joining me today. If you'd like to read or share the InfoQ Architecture and Designs Trend Report, going, gonna summarize everything that we've discussed today that will be available now on the InfoQ website.

And we hope you'll join us again soon for another InfoQ podcast.