InfoQ Software Architecture & Design Trends 2023

Transcript

Introduction [00:17]

Thomas Betts: Hello and welcome to The InfoQ Podcast. I'm Thomas Betts, and today, members of the InfoQ editorial staff and I will be discussing the current trends in software architecture and design. I'll let each of them introduce themselves and we'll start with Eran Stiller.

Eran Stiller: Hi, so everyone, my name is Eran Stiller. I'm the Principal Software Architect for Luxury Escapes. I'm also an editor on architecture and design in InfoQ, I've been doing it for several years now and I'm enjoying every minute. I can't wait for this discussion, which is always very interesting.

Thomas Betts: Great. We'll move over to Vasco.

Vasco Veloso: Hello, thank you for listening. My name is Vasco Veloso. I am currently working for ING Netherlands on a role connected to software design and architecture with a few interests along the way, but an all-encompassing and generic role at the moment.

Thomas Betts: I think we can all say that. Moving on to Tanmay.

Tanmay Desphande: Hello, everyone. This is my very first time on this podcast, I've been working as Operations Data Platform Architect for SLB. My main work goes towards architecting systems for production optimizations and well constructions in the oil and gas domain, using the latest technology that we are using and while you're also making sure that we are reducing carbon or using the carbon-neutral technologies to do so. Pretty excited to be here.

Thomas Betts: We'll wrap up with Daniel Bryant.

Daniel Bryant: Hey, everyone. Good to see everyone again. Daniel Bryant here. I run DevRel at Ambassador Labs, but a long career in software architecture and I do moonlight as a Solution Architect at Ambassador Labs, as well. You may recognize the voice. I do a few podcasts alongside Thomas and also do the news management here at InfoQ, too, so looking forward to this discussion.

Thomas Betts: So as I said today we'll be discussing the current trends in architecture and design as part of the process to create our annual Trends Report for InfoQ. Those reports provide the InfoQ readers with a high level overview of the topics to pay attention to and also help us, the editorial team, focus on innovative technologies for our reporting. In addition to the report and the trends graph that are available on infoq.com, this podcast is a chance to hear our conversation and some of the stories that our expert practitioners have observed.

Design for Portability [02:21]

Thomas Betts: I think we want to start the conversation today with design for portability and the concept of cloud-bound applications, which has been gaining adoption. One of the popular frameworks for this is Dapr, that's D-A-P-R, not confused with dapper, D-A-P-P-E-R, the Distributed Application Runtime, but that's just one implementation of this idea of designing for portability.

Vasco, can you kick us off? What do you think of the idea of designing for portability and how's it being used today?

Vasco Veloso: Well, from what I have seen, most of the usages of these tools and these patterns, they are going back, if I may say so, to the old paradigm of build once, run everywhere that we have been hearing about for a long time. Except that this time, instead of being on different machines, the everywhere is, well, every cloud, still chasing the vendor independence dream and it is quite good to see that there are choices of frameworks to accomplish that goal.

Personally, I believe that when the framework is good and has quite a reasonable amount of choices of platforms, it also means that whoever is designing and building the system can focus on what brings value, instead of having to worry too much with the platform details that they are going to be running on.

Server-Side WebAssembly [03:44]

Thomas Betts: Then one of the other ideas that falls into this bucket sometimes talked about is WebAssembly and there's also the clarification of client-side WebAssembly versus server-side WebAssembly.

I know, Eran, this is saying you called out earlier in our pre-discussion. Can you elaborate on that? What's the server-side WebAssembly integration with or thinking about for design for portability?

Eran Stiller: A lot of time when we think about WebAssembly, as we've said, it's about running things in the browser, it's in the name "Web" Assembly.

But I think a large benefit of it is running it on the server side because there's an ongoing effort for integrating a WebAssembly-based runtime, instead of let's say Docker. Let's say you want to run in Kubernetes or another orchestrator, you want to run your software, then instead of compiling it to a Docker container and then need to spin up an entire system inside that container on your orchestrator, you compile to WebAssembly and that allows the container to be much more lightweight because it has security baked in because it's meant to run the browser and it can run anywhere in any cloud, on any CPU, for that matter. So it doesn't matter if it's an ARM CPU or an x86 CPU and basically just abstracts away all the details. So we don't really need to care about them. It makes it everything work more lightweight and in a more performant manner. I think that's the key benefit there that we'll see now as we progress.

Thomas Betts: Daniel, I can see you nodding your head along. You have anything to add to that?

Daniel Bryant: Yes, it totally makes sense. As you mentioned Eran, I can see the Docker folks leaning heavily into this as well, right? They've totally recognized exactly this.

I think there's a lot of interesting connections around security. Because as Vasco mentioned, I'm old enough to remember Java. "Write once, debug everywhere," was the phrase I think we often used to say, right?

So I really as the abstractions are going up through the chain, JVM to you implied there, Vasco, vascular really were at the cloud abstraction layer now. I think things like Dapr combining with Wasm, it's all about finding the right abstractions where we can get that reusability, that high cohesion, low coupling from whatever level you are operating at.

So many of us architects are more thinking about the Dapr- level stuff, but I think the Wasm stuff really has an impact. You hinted at it, Eran, on security, for example, if I choose to run a super lightweight container, I'm sure many of us are using Go and Scratch containers, same deal. It gets rid of a whole attack vector potentially. I know we're going to look at software supply chain later on, but really I love the ideas that the different levels of abstraction here.

Thomas Betts: I can't remember who said it one time, "Every problem being solved with one more layer of abstraction and indirection."

Daniel Bryant: Totally.

Thomas Betts: But the idea behind that joke is, "I want to reduce the cognitive load. I don't want to have to think about the whole tech stack. How do I get closer to thinking about my business problem, my business logic, my domain?" If I have to think about, "How do I deploy this in Kubernetes?" all the time, that's one more thing that my developers have to think about.

I think Dapr is one framework that says, "Hey, we're going to take care of all of the deployment problems. We know the shapes of the things we want to deploy, the things we want to build with. We've now given you the right size Lego bricks to build what you need."

Server-Driven UI [06:48]

Thomas Betts: Tanmay, you had an idea that I wanted to bring up that's, again, somewhat related, server-driven UI. Can you tell us more about what you think that is?

Tanmay Desphande: It's a concept that people started talking about a couple of years back but then didn't really understand where to use those correctly. Any public applications that we see, any mobile-native applications that all of us need to develop, has to go through quite a lot of, let's say, scrutinies when you get published on the app stores and the Google stores, you need to continuously deploy. When you're an era of, let's say, every day 100 production check-ins that you're making and continuous deployments, it's very hard to see that your code is not getting deployed unless somebody from Google and Apple is going to approve your applications, et cetera.

So I think that's where the benefit of server-driven UIs are getting popular among quite lot of cloud-native or, let's say, mobile native application developers, where they want to do server-driven UI development for native applications so that they can continue to improve their applications, not even bothering about if all of my users are on the latest versions or do I need to continue to keep the backups in general for the backward compatibilities, as well. So that's where I see this trend going to get kicked in again and see a lot of those people will continue to follow on that route, as well.

Thomas Betts: It's some of that cyclical nature of software that we tend to see these patterns going back and forth. We had mainframes that were very client-server and they're like, "Oh, well now we can have the client be smarter. We can put the code over there," and everything moves over.

Then we got into the web era and it's like, "Oh, the website does everything and we just serve up simple HTML." Then HTML had all this JavaScript and all the app runs in the browser.

So we keep going back and forth trying to find the right balance and now we have a lot of options and people can choose based on the latest technology, what's the right solution for you.

Tanmay Desphande: The very first time I mentioned this to somebody, it's like, "Isn't that something JSP used to do?"

Daniel Bryant: Nice. It's that cliché of, "History doesn't repeat, but it rhymes." But I think in software development it's poetic, you just constantly see the same thing over and over again and hopefully we make improvements, to your point, Thomas.

Thomas Betts: Hopefully.

Eran Stiller: Just something to clarify that. When we say design for portability, it's not necessarily about, as Daniel said, "Writing once, running everywhere" because we were there before with Java .NET and whatever.

It's more about the fact that all the details are abstracted, you don't necessarily need to care about them. Because let's say someone mentioned vendor lock in want to avoid vendor lock-in. It's not about the fact that tomorrow we can take our entire application, move it on another cloud, it will still work because it won't. There are always details that are abstracted away. If we change the database, we change the platform, something will break, something will need to change.

It's more about the fact that we don't care about those details as we develop things. It makes it much easier for us as developers and as architects when we design our systems, and then later on once the need arises and we want to change something, we'll still need to work but then it'll be easier. But I think the focus is less about that and more about the abstraction side of things.

Thomas Betts: Yes, I think portability is, like you said not the, "I need to be able to move it," but it's, "I don't have to think about how it's anchored to the ground. My code is directly tied to this." And if you see the evolution of... I used to write build scripts and it was an idea of let's have our infrastructure as code. Well, now we're a few layers abstracted from the infrastructure as code. I don't need to talk about deploy this VM. I just say, "I need some compute that does this," and we think about compute as the unit that I need or, "I need some data storage," just stick my data somewhere and handle it and I'm further removed. And whatever's underneath that could vary. Like you said, if I deployed the same thing to AWS or Azure, maybe the underlying stuff is the same but my abstraction looks identical.

Tanmay Desphande: I just wanted to add a different perspective in that portability section, as well. I mean, the industry that I come into the picture, I mean quite a lot of companies which are, let's say, national companies in general, they're very particular about where their data resides and the Googles and the Microsofts of the world are not available in every single region itself. So building applications which are portable to run in every single data center, whether they're GCPs or the Azures or the AWS of the world, it's quite important, as well. Same goes for the WebAssembly area, as well. Imagine, let's say, all sort of application, the Adobes and the Siemens of the world, when they used to build heavy desktop applications and with the cloud, they had no answer about, "How do I provide this heavy desktop applications as a service to my customers?" Web-based assembly has been now coming to be a really true place in the sense so that people are able to stream heavy applications via process itself, as well, for sure.

Daniel Bryant: Can I just put a pin, as well. I've hear a few folks say that, Eran, Tanmay, there. It's really all about the APIs. As in, cause if we anchor ourself to a vendor-specific API, it's really hard to move away. I think that's the secret of Dapr, if I'm being honest. It's all about the APIs and they abstract without doing the lowest common denominator. I think that's one of the dangers, you always code to, "It's got to be MySQL" or whatever, but I can't take advantage of Cloud spanner or Redshift or whatever kind of thing. I think the APIs are the key and that's where I can see Dapr, if we can all collect around this CNCF project and go, "Hey, let's all agree," exactly what Eran said we're building for the future. It's still painful to change but it's not impossible to change. Right?

Tanmay Desphande: Absolutely, I agree.

Large Language Models [11:53]

Thomas Betts: So I want to move us on because otherwise we'll be talking about this for the entire afternoon.

Large language models is I think the next thing I want to talk about. It seems lately there's a new product announcement–I think there were three this morning. Well, here's a new thing that just came out. GPT-3 is now old and GPT-4 is out. We've got ChatGPT, Bing, Bard. Who's going to be the best chat bot to talk to?

If you look at it, the people who are in the know have seen that we've been building to this slowly for years, but it seems like it's just suddenly got upon us in the last few months.

Are we at some major inflection point? Is this all just hype or is there something there that we really need to consider? That's my hot take. Who wants to take that and run with it?

Tanmay Desphande: I think I'm pretty excited about the advancement of all those applications from my personal space, but I'm equally worried about my enterprise architect hat, as well. Because I'm not sure in terms of what sort of data is being used to train those models, et cetera. When I'm using it in my personal space, I'm very happy to use those applications. But when I start wearing my enterprise architect hat, I'm equally worried about what are the challenges it's going to bring to my enterprise if some of my developers are going to use ChatGPT to build applications and deploy that, as well. So that's where I'm now very excited to see how this evolves, as well, for sure.

Eran Stiller: Yes, I think we're seeing a revolution at the moment. Because while the ideas are not new, so GPT-3 has been around for a while and it's been used in various places, but we've seen lately we've seen GPT-3.5 with the ChatGPT and now GPT-4 and there are other models around, it's not only one. But I think we're seeing a large, major improvements happening all the time and the speed and velocity at which things happening just keeps getting faster. I think we're at a point where the model is good enough, it's not perfect, there are always issues, but it's good enough to employ to various scenarios that we never fought of using it for before.

So for example, I see people, the company where I work, some of them like to hack things and they use ChatGPT. They actually took one of our React components and they took our coding conventions at the company and they fed into ChatGPT or GPT-4. They fed it with the coding convention, they fed it with the code for the React component, go, "What are the bugs here, what are we doing wrong?"

It actually found things and it's amazing. It actually found things that the developers never thought of. So that's only one way to try neutral, utilize this new thing that we're still don't know what we're going to do with, exactly. But I think the possibilities are endless and I, for one, am very excited for all the new things we're going to see around and all the new APIs that were laid on top of ChatGPT. Because ChatGPT and GPT-4, they're very broad, you can just input some text, get some text back. But I think the innovation here, once it will be integrated as part of other systems using the API layers and we'll adapt it to specific fields, that's when I think we'll see even more innovation coming.

Vasco Veloso: I was hearing you speaking and also looking at the amount of products that have appeared in the past couple of weeks. It almost feels like we got ChatGPT and then everybody else who was working on large language models looked at it and said, "Oh my God, we need to productize this, we are going to miss the train." And that's actually good because, in a sense, it feels like that we may be looking at the start of a new AI summer or AI spring maybe, where the pressure of getting a product out there may actually produce something quite useful, and everybody's trying to see what the model can do. Well, I am indeed looking forward to what's coming out of it.

Daniel Bryant: Perfectly said, and I'm a big fan of Simon Wardley, so Wardley Mapping, if folks have bumped into it. He talks about punctuated equilibrium, like a big disrupter, paradigm shift, exactly what you've all mentioned.

I like what you saying, Vasco. One thing I'm hearing the productization, a lot of it's around the UX and I'm thinking back to, we mentioned Docker earlier on. Containers were not new, but Docker put a fantastic UX on them and a centralized repository, Docker Hub, that was a game changer.

I'm seeing just to your point, Thomas, this morning there was a news drop on, I think it was the GitHub what they're doing and there's the voice control with ChatGPT and so forth. The UX is what it's about. We as developers would love to be able to chat to our pair program out or pair architect and then get that feedback.

But there's always that thing you mentioned Tanmay of, "I want feedback and input, but I want to make the choices." Because I remember when RPA, was it robotic process automation, came out, UiPath, all that stuff. I remember going to a conference, an O'Reilly Software Architecture conference and everyone was super nervous, quite rightly, about this. Because they were like, "My finance team is creating this RPA thing. I've got no idea what security they put on it! I've got no idea what auth they're using!" I'm totally seeing that could be a potential with the output of these kind of frameworks now, right?

Thomas Betts: Yes. I think you start opening it up from ... Professional developers are not always thinking about security, but the citizen developers really don't think about it because they assume it's just baked in, because everyone picks up their iPhone and they think it's as secure as it needs to be and they don't think about, "What are the ramifications if I connect to this site and connect to that site? It's like it's all fine, right?" Then there's a breach and you find out, "Oh, this could have been maintained."

When we lower the bar of who can write the code, and I think that's good in a lot of ways, we have to acknowledge we have to build better security by default and not so much that it prevents its use.

Low-Code and No-Code Integration [17:21]

Thomas Betts: That does get to the idea of, how is this one more way that, I said citizen developers, would use it and how does it integrate with low-code and no-code. I think, Eran, this was your idea, you wanted to tie in.

Eran Stiller: Yes, so there's a lot of talk about low-code and no-code systems for a while. Seems for years it was on the InfoQ Trends Report. I don't remember when we added it, but it was there before. I think that all of these language models are going to be a huge enabler for low-code/no-code systems.

I remember a few days ago I saw on Twitter, I don't remember who posted it, I saw an example of someone who integrated ChatGPT with the Unity platform and they had this prompt where you can say, "Add 100 cubes. Add 3 resources of light." It just did because behind the scenes it took the prompts, it translated them into code, and then you just ran them.

We all saw examples of how ChatGPT and GPT-4 can actually create usable code. ChatGPT could only create components, one file, et cetera, simple things. GPT-4 is much more improved. You can actually generate entire simple websites, but still. I think once we take that, this could actually be a new abstraction of programming languages. Because we started from Assembly and then we got C and C++ and then we got into all kinds of Java and .NET and higher level languages.

I think you think about this as a new programming language, which is much more abstract and I don't know if you can do anything with it, maybe not now, maybe it'll come in the future, but I think it's inevitable that as citizen developers but also as professional developers, much more efficient and it's another tool that we can use and we should learn how to utilize it.

Thomas Betts: Yes, I think the example someone cited to me is a lot of people's first programming language is Microsoft Excel. Maybe they don't they don't think about it-

Vasco Veloso: And it's Turing Complete.

Thomas Betts: But when you're saying, "This cell equals this plus that" or, "Sum up these numbers," you're writing code. It's not just type in text, it is actual code there and you don't think about it. You don't think about it as programming, but in a sense, that's what you're doing.

I see these large language models as that enabler that gives ordinary people the ability to do a lot more, without having to know how it all works. That's, again, that force multiplier of having an abstraction layer that's so powerful.

I think someone pointed out it can create a full website. I saw the demo of, let me sketch out the website, take a picture, and then it generates the HTML for you.

Vasco Veloso: A wireframe, yes.

Thomas Betts: That goes to the, it's the UX that we need to figure out. If I can take a picture of something and get a working system or I can talk to it, as opposed to I'm sitting there for an hour typing out code, that just saves me time. It's not doing anything that I couldn't do or some programmer couldn't do. It's doing the thing that's really easy so I can work on the thing that's really hard.

Eran Stiller: I think also a lot of people think, "Well, will this get developers out of work? Will we need any more developers?" I think that's not the case. I think we'll still need developers, they'll just be more efficient and do more things. Because I think Vasco mentioned earlier, we're still the one making the decisions. For example, all these model, like GPT-3 I think was already integrated in GitHub Co-Pilot for example, which I think was based on top of it and could generate test cases. I assume at some point it will be updated to GPT-4 and will provide better results.

But still, even when GPT-4 other models they generate code, you could still look at the code quality, it's not what we expect in quality conventions. Maybe there's some hidden bugs in there that we don't know about, maybe some security flaws. Of course, with time it'll get better, it will give out better results and we could go on faster, but I think we'll still be the drivers. It's just that the building blocks will be much bigger.

Daniel Bryant: That's an interesting point, Eran. It does point to different skillsets we might need to learn as developers or architects. Because I think more product-minded developers will excel in this; to your point, Thomas, I sketch out a wire frame, happy days. For some folks, really like writing code, sometimes I want to write the code. So that's going to be really interesting, that thing we have to learn, and as architects that the way we phrase the problems like typing is no longer the bottleneck by ourselves, by our teams. How's that going to change our jobs? Quite a lot I think.

Thomas Betts: Yes. I think it's going to put Stack Overflow out of business before it kicks me out.

Daniel Bryant: Yes, super interesting.

Thomas Betts: But Stack Overflow is probably feeding half of what my questions are answered by, it's just saving me the work of finding the answer.

Software Supply Chain Security [21:48]

Thomas Betts: I wanted to move us on, again. We don't talk about security a lot on the Trends Report, but I wanted to bring it up this year because it's been an interesting last few years with global supply chains being disrupted and the talk of the software supply chain and how that comes into play. We're not moving molecules around, it's just electrons. But those bits that we're downloading for the hundreds or thousands of packages that my code depends on, we're now getting into this question of trust.

How do I know what the code is that I'm using? Are we just trusting the commons that we've got? "Oh, it's out on NPM or NuGet, so it's got to be safe?" And how do we verify that the code I run is safe for what I need it to do?

Tanmay Desphande: Every time anyone start talking about the software supply chain security, a meme pops up into my head where there's a bunch of great things that I've developed and it says that it's based on a very tiny bit of JavaScript that somebody's maintaining in some corner of the world that I'm not aware about. So I think that says a lot about the supply chain software security.

Starting from 2021, we started seeing quite a lot of buzz around that because there was some incidents that proved us to make an conscious effort in that direction. I've seen quite a lot of, let's say, open frameworks that are available from Googles and the Microsofts of the world, where they're making it available for everyone so that everyone start understanding what level of software supply chain security that you are into and what else can be done, as well. So I think it's going to be quite evident as we continue to move ahead in this journey to keep stressing more and more on that, for sure, as well.

Thomas Betts: It's certainly something we might not be thinking about every day, but there needs to be something that the architects looking at the big picture of the system have to consider, "What is the foundation that we're building on? Is it all just a house of cards to level down?"

Daniel Bryant: Getting visibility is a key thing, as Thomas was saying. I think a lot of us here work in, say SBOMs, that kind of stuff. First thing is actually knowing where there is a problem, and I think the Log4J stuff really triggered a lot of architects to realize, "This is everywhere in my system. I didn't even realize there was Java running there." Do you know what I mean? So having that SBOM and you mentioned that SLSA, Tanmay, as a bunch of frameworks popping up, open source frameworks. I think they're super smart. I'd definitely encourage architects to check these things out. Visibility is the first stage to their problem solving.

Design for Sustainability [23:58]

Thomas Betts: What about the idea of designing for sustainability? Vasco, I think you mentioned this a little bit. Are there new trends or new ways that people are thinking about making their software system sustainable or measuring it?

Vasco Veloso: Indeed, I have noticed that there is more talk about sustainability these days. Let's be honest that probably half of it is because, well, energy is just more expensive and everybody wants to reduce OPEX. But, it also means that there are new challenges.

Let's look at a data center, for example. I am absolutely not an expert in data centers. I know they exist, I can understand them, but please don't ask me to optimize their footprint, way out of my league. However, a data center is just at a level of abstraction that is just too high and there are limits to what can be done to reduce the footprint at that level. Initiatives such as the Green Software Foundation, for example, that is part of the Linux Foundation, they are trying to come up with a methodology that people, developers, architects, can use to measure the footprint of a software system. And that, depending on the boundaries that you choose, can actually allow you to measure the footprint of individual systems within a large boundary, such as a data center. Going from there, well, the sky's a limit, I think.

Thomas Betts: Yes, I think the measurement problem is the thing that we're working on most right now. Because we say we want to reduce our carbon footprint, "What's my carbon footprint?" And if you don't have a way to tell, the best guess we've had is, "Well, let me look at what my cloud spend cost because that's probably directly correlated to how much the servers are costing to run, which is based off the electricity and let's assume the electricity is not green." But that's going to be wrong in a lot of cases. And it's going to be very different. If I deploy to US East, which runs mostly on coal, that's going to be different than a data center that runs on renewable energy, so you have to factor that in. I think that's what the Green Software Foundation is trying to help do is not just, what is your code doing, how much does it run? Where is it and how is it run?

Vasco Veloso: Indeed. Also taking into consideration that the energy is cleaner at some points during the day and is dirtier at others, as well. So that is still yet another factor.

Thomas Betts: So you can change when your software runs. Tanmay, you had something to add?

Tanmay Desphande: Well, yes, and I can relate more to that. I mean, I breathe and breathe out all of those things every day as a part of my job. So for sure, I feel that the way we are talking about the software develop material, we also going to start and seeing every single software provider is expected to provide their carbon emissions as a part of the services that they're providing, the way we provide liabilities, the we provide availabilities, et cetera. I feel that that's going to be a trend that we're going to see in next few years for sure, as well. Then what's going to drive that trend is the way that we do today our financial accounting as a public-listed company, we're expected to do the carbon accountings, as well, sooner. So it's going to be quite evident that I may start choosing a vendor that does a greener energy emissions than the other one in some context, as well, for sure. So it's going to be quite an interesting trend to watch our product, for sure.

Thomas Betts: I know a lot of companies, at least in the US, they said, "Oh, we've gone carbon-neutral." Well, they just waited until 2020 happened and they sent everybody home and they stopped having to pay for the electricity in their building. I'm like, "Are you counting everyone running at home and everyone's internet connection to connect back into the data centers?"

Eran, did you have a last comment about this?

Eran Stiller: So you mentioned earlier where the software is going to run and how it's going to operate. But it's also about when and how we time things.

For example, today, and I think the key here is accountability, I think we start going to that. Because right now as developers we have FinOps running all the time and it's getting more traction. We're actually being measured on how much money we spend on the cloud because a developer it's his decision, her decision, they can just spin up a large instance and create $10,000 bill out of nowhere.

But no one's measuring our emissions right now and there isn't really a good way of doing it. Also, I know the large providers are working on all kinds of calculators to help you estimate your carbon footprint, but it's still not there and no one's holding us accountable for it. I think once we get to that stage where we'll be held accountable both as developers, but more importantly as architects, then we need to take those decisions into account.

Because right now, as an architect I design a system, I'm well aware of how much containers am I using, am I using this database or that database, because of cost. But when we factor in carbon emission and those calculations, and I might decide, "Well, I can run this calculation at night," not because it's cheaper, it might be cheaper because things like spot instances and stuff, but it also produces less emissions because of the way the power for that data center is generated and so on.

So I think right now we're at the start of it. It's still an innovator's market, but I think it'll progress as accountability comes to mind, when the calculators become better, and it might even become a regulation thing, but who knows.

Decentralized Apps (dApps) [29:16]

Thomas Betts: So I'm going to throw out a topic that I didn't mention earlier that I was going to bring up: Blockchain and decentralized apps. Blockchain has sat on the innovator section of the trends graph I think since it showed up and we haven't moved it because it is only applied to crypto and NFTs and that just didn't seem interesting.

Well, partially because Twitter was supposed to implode this year, Mastodon took off, and I think that's maybe the first time that people saw an actual decentralized app in production and they used it. Is that enough to say it's moved over to early adopter or is blockchain and dApp still one of those innovator hasn't really caught on stages?

Daniel Bryant: Shall I be controversial and say I still think it's niche or niche, depending on how you want to phrase it? I think there is something interesting there, but there's a lot of like, "That's almost like a house of cards built on top of it," in terms of it's very easy. We saw most folks, I think Meta pulling back from NFTs. There's been all the SVB bank and a lot of crypto stuff related to that, as well. So I think there's distrust in the market.

When we have the zero interest rates, I think everyone was just like, "Build all the things!" and clearly not think about carbon emissions and related to that, as well. But now I think the fact that we do have high interest rates and we are being more conscious of some of these environmental factors, I don't see blockchains. To do with proof of work, I don't see it being a thing, proof of stake maybe or proof of some other things. But the way it's originally architected, I don't see that happening in the current macroeconomic climate.

Eran Stiller: Yes, I think when we prepared for this podcast, someone mentioned that it just doesn't align with consumer demands or consumer requirements. You mentioned Mastodon earlier.

It's decentralized and as a techie, as a technologist, I really like it. I think it's cool. I think the way a server shuts down, you can just move your stuff over and continues working and no one can shut it down and there's no censorship in it. And these are very good ideas. But when you look at the average consumer, they really don't care about it. "I just want it to work. I want to go to a certain website, to type something in the browser, open an account, log in. I don't care if there's censorship or there isn't censorship," most people. Again, some people who live in certain countries care about this very much, but I'm talking about the most of the population that uses this tech, and decentralized software is still not there, it still doesn't offer ...

I think the only case that I can think of that a decentralized app was actually successful was around file sharing and torrents and stuff like that. The reason why that was successful because the consumer requirement actually aligns with the nature of decentralized app, "I don't want to get caught. I don't want anyone to be able to block me and I wanted it work fast," so decentralized was doing it much better. So the requirements aligned with the technology there, but I don't think there is another case of that that was very successful.

Thomas Betts: I think you hit it on the head. There's no consumer need for that as a top level feature and so why add the complexity if we don't need it?

Socio-Technical Architecture Trends [32:12]

Thomas Betts: So I wanted to wrap up the discussion talking about the socio-technical issues, the ways that architects are working. I think we took it off the trend chart last year, but the "architect as technical leader," the "What role do you have as an architect?" How do you lead, and also, how are we doing with remote and hybrid work, all of that stuff about how are we doing architecture.

Just general thoughts that people have on that concept. Vasco, you want to kick that off?

Vasco Veloso: Well, I can get started by sharing my personal view, which is that regardless of whether we are designing a piece of software or an enterprise architecture at a 30,000 feet view, it is always important to, and this sounds like a cliche, but not to lose touch with reality. That is when expressions such as having one foot in the engine room or always messing around with tech, even if you don't write code or build a system on your free time, just ensuring that there are still lines of communication open with the people who are actually building and troubleshooting and debugging and involved in those calls at 3:00 in the morning. That is the only way how we can really understand whether what we are designing works and has value and then take those lessons to the next project. That's my take.

Thomas Betts: Tanmay?

Tanmay Desphande: I like the idea always about documenting your architecture. I mean, if you just Google around the word, I mean, "How do I document an architecture?," there's not really good answers or a very strict or very popular answers to that. Then I always get that question with some junior people that I'm currently working with.

There are quite a lot of good things available. I mean people generally start talking about ADRs, but then they only record the decisions part. I'm not going to give the full view of architecture how it is there right now. So I'm right now struggling to have a very good standard around that part. The way I personally try to use it is obviously with a combination of C4, ADR, and something like r42s is the way for me, it is the correct answer so far for me right now. But then I certainly feel that there has to be something revolutionary here to happen, considering the fact that software architecture is such an old in a sense, that age-old practice that we have been practicing all across and there's still no good answer to document a very good soft architecture in a sense, right?

Daniel Bryant: Can I just add, great answers already, but I think to lead, coming almost full circle with LLMs and ChatGPT, the what now is going to be easier. We can feed something into our systems and go, "What's going on there?," and it'll spit back and we can have a conversation.

As you alluded to Tanmay, the why is not going to be there, and that's ADRs. Thomas, you've talked fantastic on previous podcasts around the value of ADRs.

But I almost envision talking about UX again, but the ability to scrub the timeline. Do you know what I mean? I do it sometimes in Google Docs and things and, "Why did we get to this point?" I can go back in the version history, Git, Google Docs, choose your poison. But I think the why is going to be the real thing. The what, ChatGPT is just going to rock that better than we can. Feed the code in, give us an answer. But why? Because there's always good intentions, good information at the right time, but then imperfect world, and you're like, "What idiot put this code there? Oh, it was me two years ago," is the classic. I love to be able to scrub that timeline and go, "Why did I do it at the time? Oh, these constraints were there, which have changed. Now I can make different decisions," right?

Eran Stiller: Daniel, you've just blown my mind. As you were talking, I started thinking, "Well, if we feed ChatGPT, we give it our code and we also provided our ADRs along with it and they'll all be timed and it will have access to the Git commit history, I can ask some complex questions around why we've done some stuff and who's at fault at something." That's an interesting concept, I wonder who's going to turn into a product.

Daniel Bryant: We need to patent this, Eran. I think this is the five of us here could make some serious money, right?

Eran Stiller: Yes, indeed.

Thomas Betts: I want the GPT-enabled forensic auditor that comes in and says, "What did it look like at this time and why did you do it that way on December of 2022?" I don't remember, but all the data should be there if you had it captured.

I personally have found that if I am writing an ADR, using ChatGPT or Bing to ask it the questions help me understand the trade-offs. That's a surprising thing that a year ago I would not have considered having that as my virtual assistant, my pair programming assistant.

I work in a different time zone than most of my team so they're not always on when I'm working late and having that person that's always available to ask a question. Then if I get lazy, "Please just write the ADR for me" and then I compare it to I would've done. So that's a new way of working that I think gets to, we have to constantly be looking as architects of what the new technology trends are, how can we incorporate them, should we incorporate them, and how can we make our process better? And how can we get that to our developers and engineers and everyone else we work with and make their lives better?

Tanmay Desphande: I think in the old remote world, I mean, we worried about asynchronous communication is the key. ADRs and C4s and all of those things that we keep talking about are the best means to communicate your architecture if you're working in a remote setup, for sure, as well. These are the tools probably all to create personal communications, as well.

Closing [37:25]

Thomas Betts: I want to thank everybody for joining me and participating in this discussion of architecture and design trends for the InfoQ Trends Report. We hope you all enjoyed this and please go to the infoq.com site and download the report that'll be available the same day this podcast comes out.

So thank you again, Vasco Veloso, Eran Stiller, Tanmay Deshpande, and Daniel Bryant.

I hope you join us again soon for another episode of the InfoQ podcast.