InfoQ Architecture and Design Trends in 2024

Introduction [00:58]

Thomas Betts: Hello, and welcome to the InfoQ podcast. I'm Thomas Betts, and today we'll be discussing the current trends in software architecture and design for 2024. The InfoQ editors on today's panel are Eran Stiller, Rafal Gancarz, Daniel Bryant, and our special guest is Blanca Garcia-Gil, a member of QCon London Programming Committee. Let's go around to quick introductions and that way our listeners can recognize your voices. I'm going to start with Eran.

Eran Stiller: Hi everyone. My name is Eran Stiller. I'm a principal software architect at Luxury Escapes, and I'm an editor on architecture and design on InfoQ I think for the last three or four years. I've been enjoying quite a lot. I've been in architecture and design issues for 20 years. This podcast is one of my highlights of the year, so I'm looking forward to it.

Thomas Betts: Rafal?

Rafal Gancarz: Hi everybody, my name is Rafal Gancarz, and I've become an InfoQ editor only last year, so I'm reasonably new to this group of people. It's my first podcast as well, so thanks for having me. I'm working as a principal engineer at Starbucks, and have been a user of InfoQ for many, many years.

Thomas Betts: Daniel?

Daniel Bryant : Hi, everyone. Daniel Bryant, a fellow co-host of the InfoQ podcast along with Thomas and several other folks too. My day job, I'm an independent tech consultant, longtime architect, part-time platform engineer, bit of devrel in the mix too, and I also manage the news at InfoQ.

Thomas Betts: And last, Blanca.

Blanca Garcia-Gil: Hi everyone, my name is Blanca Garcia-Gil. I currently work as an independent data consultant, but I have a background in software and data engineering. I'm also a programming committee member for QCon London, and I'm very excited to be here today.

Thomas Betts: Thanks, and since I guess I haven't done my introduction in a while, my day job, I'm a principal architect at Blackbaud, which is the largest software provider for the social good community. Been an InfoQ editor and now the lead editor at InfoQ for architecture design for seven or eight years I think. Been the cohost for the podcast for a little while, and also do a lot of stuff with various QCons in London and San Francisco. So I meet a lot of these people in real life on a regular basis.

All right, so today's discussion is a component of the 2024 Architecture and Designs Trends Report. One of the regular features of InfoQ are these trend reports, and each one focused on a different aspect of software development. The reports provide InfoQ readers with a high level overview of the topics you should be paying attention to that year, and also help the editorial team focus on innovative technologies across all the content on InfoQ. This conversation is just that one half, so please go and check out the report that'll be available the same day that this podcast is online.

Data-driven architectures [03:17]

Thomas Betts: I'm going to start our discussion talking about data driven architectures, because one of the things we've noticed a lot in the last few months especially is InfoQ news items that talk about architecture also talk a lot about data. These big data systems are becoming more and more important for architects to be considering as we're designing them we have to consider whether it's ML models or analytic models or just all the big data we have. So it's that big bucket, and it's been a topic we've covered in different ways, and I just wanted us to have a discussion today about how the different ways that data is affecting architecture decisions. Blanca essentially mentions your data in your bio, I'm going to start with you.

Blanca Garcia-Gil: Thank you, Thomas. Because in the past in my career I started actually working in software engineer and then I moved into data. It felt like there were two different worlds, and almost software principles that I learned in my career. When I started working in data architecture, I was thinking, well a lot of these things are really the same, but then people were coming from a very different place working in data, because data systems used to be handled completely separately in organizations. So nowadays, architects are thinking more about these things that are actually going through the pipelines, going through the microservices, which is the data points and thinking what are the things that I need to think about this data? So things such as how do we keep this data secure? How do we make sure this data has a certain quality so then downstream systems can consume it, and more on the topic later, what is consuming this data points?

There are all these concerns about data that they used to be handled by separate teams or separate systems altogether, and now being handled by the architects. I think this is really good because there's a lot of learning both ways and there's also expectations for the data to be to a certain standard, whereas before maybe we tolerated the data not being so good, but now we want to make really good decisions with it. And also, there's expectation that the systems that hold data for business consumption, they almost have this resiliency to them. They're always available, and a lot of the things that before were not as important when coming up with data solutions.

Thomas Betts: I think the fact that it's part of the main workflow and main pipeline, it's been slowly progressing that way. But it used to be, oh, that report runs once a night. If it didn't run that one night, well, it'll run tomorrow and it's fine, or it'll take two hours to run, and now you need that to be instantaneous, always on, and always resilient so that if it goes down, it comes back up.

So has everyone else seen similar trends of how what you need in your main system, your operation system is now affecting how you have to maintain your data architecture?

Rafal Gancarz: I have to say that I've certainly observed more emphasis on data architectures or architectures that support machine learning or close. That's not only to provide training, but also be able to serve data, serve models, to model versioning, and basically be able to support the entire life cycle of delivering training and then serving models. Those systems are getting more and more sophisticated, and we can certainly observe that there is much more attention to various architectural qualities including the way that those systems are composed, the resiliency, observability, and obviously performance among other things.

Eran Stiller: I think as architects, we always need to know quite a lot of things about various areas. This is quite a big one that we need to know today. We have all these tools and concepts like data lakes, data warehouses, ETL tools, data quality tools, you name it. It's an entire area that we really need to be aware of. Some of us deal with it more in our day-to-day works. Some of us deal with it less, but it's something we can't just ignore. We really need to be aware of it and we need to integrate into our system. For example, you mentioned Thomas, today, we can't get our data once a day, get a report on ETL pipeline, that's it.

Let's say we're running some microservices system and we have a lot of databases. How do we get the data from the databases to where that report is generated? We can use ETL pipelines, and then we have a direct dependency on the database. We can use something like event-based architecture and have a application layer. Each architecture has its pros and cons, but it's all tied up together and really taken into account when we build our systems.

Daniel Bryant: What I'm hearing, what I'm seeing as well is to mangle the William Gibson quote, architecture's here, it's just unevenly distributed, you know what I mean? As in I remember just we figured out architecture for software applications like we had mentioned earlier domain driven design, microservices. Now, we're struggling with data, right? Maybe we'll touch about platforms later on.

I think that's one of the key things that architecture flows through all the things in our systems, but to varying degrees of maturity. I think that's the biggest thing for the trends report as well. The biggest challenge is identifying the thing you are working on. Where is it in the maturity level? Do you know what I mean? We're pretty good at architecture and software I think now, right? But data, as to Blanca's point, the quality and the reliability and all the -ilities, we're not so good with, right? I think that's what I'm seeing the shift in focus now.

Thomas Betts: Yes, architects are always concerned with those quality attributes and it used to be these are the quality attributes of my software system and that big data stuff is off to the side and so it's allowed to have different quality attributes, and as it gets more and more incorporated into my primary workflow, part of that is it has to come up to the same level of quality. It has to have the resiliency, it has to have the uptime and the SLAs.

And so I like the idea that those terms you have to know about, I think Eran mentioned you need to know more stuff. Well, I didn't have to be concerned with those things, but as they get pulled in, now it's all in your domain, so architects have to be concerned with a little bit more knowledge about everything.

Large language models [09:00]

Thomas Betts: I think that's going to be a nice segue because we have to talk about large language models. I think it's required now on every podcast to talk about AI and ML and LLMs. Where does that fit in with architecture? Is there a big trend around LLMs for architects to be concerned with, or is it all just hype?

Eran Stiller: I don't think it's just hype. Last year, if I remember our podcast, it was the main theme of the podcast because it's brand new at the time and I think we all learned a lot and grew up over the past year. I think everyone's using it as in it's another tool that we can use. If you have a component or some functionality that you build, you can leverage gen AI if that's what we're talking about in that context, to generate some result to build some new functionality that you couldn't do before, it was much harder to do before.

But I think it's another tool. It doesn't change necessarily the way we do architecture unless you take into account that for some AI models, that's not necessarily gen AI, but more general ML, AI models that fits into the data thing we discussed before when you need to collect the data, not just to report on it but to train and serve models. That's where it all fits in my view.

Rafal Gancarz: Yes, and I think there will be certainly more and more integration happening between the AI enabled driven components and other components within architectures. Obviously at the moment we are still I would imagine in the experimental phase, but a lot of these things will get productionized or are being productionized, and this is where the architecture of focus I think is going to come into play.

Blanca Garcia-Gil: I agree with Rafal. I think organizations and engineers and architects, it's vital that we get to grips with the possibilities of this and gaining understanding of what we can do. I expect more and more companies to come up with their own custom LLMs to solve their own problems because even the open source frameworks are out there, so you can do some of the training yourself and just play with things. It's very low friction.

Thomas Betts: Yes, I think that's where you're going to see once we'll figure out how to make it easy for their own specific custom implementation. How do I train an LLM on my data so it understands what I need? We've seen a few uses of, I can point something else at your document history or whatever, and I can find the PDF that's applicable. Microsoft Copilot is one of those things. There's others out there.

Here's how to scan just your data as opposed to look at the internet. I think we're going to see those things get more tailored, and so the LLM will just be one more tool that you can then say, "I'm going to plug this in as part of my system," but I don't think it's going to become our entire system is an LLM and an AI and we don't know how it works. I don't think that's going to happen.

I also appreciate, Eran, you mentioned this is a tool for the architects because architects do two things. We design the systems, but we actually also practice architecture. So there's what we draw as the boxes and arrows and the decisions we make, and then it's how do we make the decisions and finding the ChatGPTs and other things as the rubber duck. I'm going to have one more person to ask questions and bounce ideas off of. Don't turn your designs entirely over to it, but it's one more person you can ask rather than I can get on a phone call with you all and say, "What are we going to talk about?"

Eran Stiller: Last year, I think one of the discussions we had was, or everyone had basically will it replace developers? Will it take all of our jobs? And I think that discussion died in the past year since we all learned that, like you said, Thomas, this is a tool. I think actually Microsoft's name for it, Copilot is good. That's the Copilot, we're still the pilots.

It's another tool and I love using ChatGPT and Copilot to write some code that let's say I need to write some bash script that does something and I don't remember bash syntax by heart, but I can let it write the code for me. It does 90% of the job, and then you just need to fine tune it and fix the things that I need. The same thing for architecture. It won't come up the architecture, but if we come up with some designs and ideas, it can be a good idea, good way to validate them.

Rafal Gancarz: But also, I think maybe by extension I would say that since we are in the business of essentially broadcasting, sharing knowledge to other people who are perhaps looking to InfoQ for inspiration and learning new techniques or new tools, new technologies.

AI in the context of architecture and engineering in general, I think has got a potential to be the enabler I guess for learning in a sense that as we are trying to compile the experience of our people and present it to others, I think to certain extent, AI might actually do a reasonably good job at either applying well-known or established patterns to certain problems without actually having a human to try to figure out how to apply a pattern or a design style. And similarly, I think in sense of capturing, categorizing, analyzing and devising insight from knowledge that is available out there.

Daniel Bryant: I'm looking forward to the explainability, Rafal, to that point as well. I think we talked about this on the podcast last year, but combining the ability to look at your Git history, your ADR, your architecture decision records, and just the code base in general. I've played around a little bit on my very small code bases. I imagine the big banks and other financial institutions and just big institutions in general, you can't replace that code overnight. It's going to be decades probably in the migration.

So the ability to say, "Hey, Copilot," as Eran said, "please analyze this part of the code base, tell me where this change will need to be enacted," or, "explain to me the structure used." Because honestly, when I was doing Java projects, half the battle was understanding the models in the code and the person before me or even me at times, what I'd written at that point a year ago and it's like explain it back to me like I'm five. I'm really looking forward to that proper explainability. I think that's the next gen for me in terms of that Copilot for architects.

Blanca Garcia-Gil: I'd like to add one more thing to that explainability, and it's we need to be able to trust these models. That's the key foundation that you build everything on, because otherwise you don't really know if you're going in the direction you want to go, or the model is just basically saying something, and then you need to be able to question it and wonder, is this really what I need?

Rafal Gancarz: I think this is a general caveat I guess, and challenge with AI, obviously depending on what you feed it, you get the different outputs and there are all sorts of biases. I mean, humans have biases, artificial intelligence will have lots of biases, even more so I think. So yes, everything has to be taken with a pinch of salt. It's just an advice like any other. Let's say we're not supposed to stop thinking particularly architects that I think pride ourselves about thinking and maybe overthinking things as we go about our work.

Thomas Betts: I think the Copilot versus the pilot, you're still in charge, remember that. It might look like it knows what it's talking about. It's just guessing the next word in the sentence. You go back to what does it actually do? It doesn't know anything, but it really appears like it does and that gives that false sense of, well, it sure seems confident. I like the "trust but verify," is that a good idea? But how do I actually know? Just like if I asked another person, but I'm still the one responsible for making the decision. I'm just getting other input and other ideas I have to make the decision. It's my name going down there. I'm not signing off the ADR, well, ChatGPT said so. Mind me.

Cell-based architecture [16:17]

Thomas Betts: So let's move on to a different topic. Cell-based architecture. We had a couple different articles I think Eran and Rafal both wrote on InfoQ just in the last month or two. And Daniel, you found one, a presentation or an article from 2019. So I guess what is cell-based architecture? Why is it making a resurgence if we've had it for so long, what is it and why are people using it? Why is it important right now? Eran?

Eran Stiller: Maybe let's explain first. So cell-based architecture, basically a concept where you take a running system, you basically pull it apart into components or cells as they're called, and each cell can operate independently. So once a request goes into the system, it gets routed into one of these cells. You could think of it as an availability zone on the cloud, or it could be a data center or something else.

But once the request gets in, it gets entirely served from that cell. Now, even if other cells drop off, they have issues, whatever, the cell is independent, can keep running and it can return response to that request. Now the reason that's important is that when we're building cloud-based system, cloud native microservices, right-sized services, whatever we call it, we have a lot of dependencies, we have a lot of moving parts.

And when a request comes in, it can travel through many, many, many components in this way. The more components we have, the more probability that something will fail. Once we model it as a cell, and we know that either a cell is working and then gets requests or we identified it doesn't, don't write any more requests so it really lowers the probability of any errors happening.

Now, this is not a new concept. We used to call it bulkhead pattern before, so you could think of it as a rebranded thing, but I think with the resurgence of cloud native and more complex architecture, this is making a comeback to reduce the probability of errors, and improving user experience eventually.

Rafal Gancarz: Well, yes, I think I've actually linked to an article from 2012, so the actual first mention of it, I think it's much older than even we think. It's interesting because it has researched in the context of the cloud obviously since a lot of companies are running their workloads on the cloud.

And I think there are specific challenges regarding for instance, gray failures where you have your various layers of your services let's say. It's supposedly a bad pattern to have services call other services in layers, but people still do it. And obviously, we have databases, we have infrastructure-level services. All of that turns into a lot of interactions usually spanning multiple data centers, which is all great for resiliency, but it's difficult to detect if networking issues for instance, between those data centers or zones.

This is one of the elements where companies and particularly large companies that cannot afford to experience partial failures and obviously detecting and addressing those is quite challenging. Those companies have, I think, brought this concept up from the archive so to speak, and started adopting in the context of cloud-based workloads.

Another element which I think drives this quite a lot is the fact that I think on most public cloud providers, you usually get charged for any traffic between availability zones or the data centers. Actually, constructing your traffic or the interactions between services and other architecture components, a single cell that is co-located in a single DC saves you some money as well so that's another element around cost-effectiveness and sustainability.

Thomas Betts: In the cloud, you can easily spin up more and more servers and services, and you can spin them up in other availability zones, other data centers, it gets relatively easy to just write the script to just do that. And there's been that thought that if I have more, I'm more resilient, right? And we've seen many cases where that doesn't prove out to be true, and you have one little failure and because you didn't write good isolation and good fault tolerance and bulkheads and follow those patterns, that one little thing just spills out and goes past that availability center and goes into another data center.

So the idea was if Amazon east goes out, I'm still up on the west coast, but that's an Amazon problem, that's an AWS problem. Your problem is your code took down all of your servers and your services. Amazon's still up and they're fine, but your code had this little bug and it spread out and you had the "query of death" scenario.

I think that also gets to your point about cost. We didn't need to spend all the money, it didn't actually buy us anything, and we're sending traffic back and forth. It doesn't need to be there. I can isolate it, save some money, make my systems more resilient, but I do have to think about it. It doesn't come for free. And that's where all this comes in is I'm going to call it a cell-based architecture, call it a bulkhead pattern, but I'm going to specifically put that into my architecture. Eran, you have something to add?

Eran Stiller: Yes, so Rafal mentioned the data saving aspect and there's also the resilience aspect. Now when you think about resiliency, we had tools in the past to do this. You think about the circuit breaker pattern, that's exactly what it's meant to do. If you have a failure in specific service, you want to stop it from cascading to the rest of your system.

Cell based architecture another way of doing it. It has other advantages, but you really have to think about the way you lay out your architecture and how you define the boundaries and how do you enforce them. So it's not easy, but it has its advantages and I suspect we'll see more and more companies do it over time.

Rafal Gancarz: One thing to add to that is that you have to ensure that you have good way of routing your requests to cells. This is where the complexity comes in. I think once you are in the cell, everything is simple, quite isolated, but you need to make sure that you have a consistent way of routing and obviously detecting cell failures to avoid drafting being sent there.

Thomas Betts: Nothing comes for free, but if you do it right, you can save some money.

Microservices vs. monoliths [22:20]

Thomas Betts: I think the other thing that this related to, in my head at least, was the general idea of where are we on the monolith to microservices and back again. We're going to go full Lambdas, we're going to go serverless, we're going to go back to servers in EC2.

There's been a few stories of this, it keeps coming up. It's an interesting thing for the trends report because everything that people are going back to isn't a new idea, but I think there's still something to be said about the company is still constantly reevaluating your architecture and having that continuous architecture mindset of whatever decision we make might be good right now, but we have to constantly come back and evaluate it.

Maybe we need to go to a cell-based architecture. Maybe we need to do monoliths instead of too many microservices or Lambda functions. I think somebody, was it Rafal, you were going to mention the modern architecture book by Nick Tune? Was that in the same vein of? Architecture Modernization.

Rafal Gancarz: Somewhat related I think, although I think what I like about it is the fact that it actually expands system architecture into what I think Nick calls a corporate architecture. I think for me it's a natural progression I think that started with the agile movement and maybe it then turned into DevOps and now I think inevitably obviously we want or companies want better services, better products.

The best way to do it is to align what you do with the outcomes you are hoping to achieve, and that's usually being competitive in the marketplace. The same way that Agile and DevOps I think enable teams to pursue their goals within the, I would say the restrictions of the specific areas that they're operating.

What I like about the approach that has been promoted by Team Topologies book, a good one, well recommended, and now I think Nick who is with his Architecture Modernization book is expanding beyond that, combining it with a lot of data during design and other concepts that I think have been maturing up over the years to provide essentially a framework that allows to bring together product development architecture as well as organizational structuring or creating technology organizations.

I think that's going to have quite a profound impact on the industry because it actually provides good patterns to follow. Like we talked about maybe doing DevOps between, it was actually called DevOps. I'm sensing that we are in one of those moments where something that is being called and maybe there's going to be a better name for it because obviously we are constantly modernizing our architectures, but I think a path or the drive towards unification and alignment between the technology and business, I think it's what drives that. Nick provides good patterns and good way of going about implementing something like that at the level of companies and business units.

Thomas Betts: You're bringing up a good point about getting all the different viewpoints together. Architects always have to talk to all the different stakeholders. So when we start incorporating all that into our products, well, that was what Agile was. It was have more communication, don't just write it down and throw it over the wall. DevOps, don't just write the code and throw it over the wall, get together and talk with the people. That leads to when we have that mindset, it leads to better software.

Platform architecture [25:50]

Thomas Betts: I think you started to talk about that gets to how do we deploy and integrate our software. And so I'm going to use that as a nice softball over to Daniel to talk about where we at with platform engineering because I feel like that is a thing that architects need to be considering is how are we going to build the software, how are we going to deploy the software, how are we going to run the software? And that's where the platform becomes a key factor, right?

Daniel Bryant: Hey, Thomas indeed. Rafal, you've queued me up perfectly with the mention of Team Topologies, right? We should mention Matthew, Manuel, our friends of InfoQ and they are awesome. And that book has just done so well. It's super happy for them. It was like I saw it being birthed and it was just really nice combination of all the patterns coming together and fantastic work.

I think two things, the platform engineering, I see the platform you build influences the architecture you choose. If it's really hard to spin up new services, or you're bumping into incidents all the time, you're incentivized perhaps not to create new services, so you just jam the code in existing services or you go back to the monolith. I'm not saying it's bad or good, but the platform is a symbiotic vibe with the architecture, the application, the infrastructure itself.

The way I'm looking at things at the moment is that there's the application layer, there's the platform layer and the infrastructure layer. Not everyone likes that pitch. I'm working with the CNCF and a bunch of other folks trying to understand how to build better platforms, but that's coming full circle.

And as much as the platforms influence the architecture, a lot to learn I think from architecture, all the good stuff we've been talking about into platforms like the layering, the abstractions. We've hinted at it several times in the call, classic stuff like things like coupling and cohesion that's just universal, whether we call it, label it something or whatever. So many times in my career, whether it's testing, whether it's infrastructure, whether it's design applications, I'm like, "Ah, coupling and cohesion here." And I just think like I mentioned earlier on, the architecture is here but not evenly distributed. Same vibe with the platforms.

I think there's a lot of things me as my software engineering background can share with the platform folks. Definitely a lot I can learn from the platform folks back to software application design as well, but that's I think where we're at the moment in terms of on this curve of diffusion of innovation that we constantly talk about. Platform engineering is still quite early days, particularly in relation to architecture, so probably the innovators kind of thing. I think everyone's adopting a platform or a portal probably.

I see a lot of people doing backstage and other things like that. That's not necessarily a platform, I like backstage. I think it's really good tech, but I think it's different than platforms, but I think early days for us getting our head around how to build platforms and how the platform influences architecture too.

Rafal Gancarz: Yes, I think I would agree with that. You can certainly see a lot of thinking and a lot of effort going into building those systems. I mean these are systems like any other systems, it just happens that they're supporting building the actual systems that the clients or customers are using, but they are, well, actually in that regard that perhaps even more important than what your product might be because they have a multiplying effect.

If you have a bad platform to contend with, like you said Daniel, you will end up perhaps sacrificing your architectural options, because you might not be able to support your chosen architecture in terms of the ease of deployments for instance, and the resiliency of all other options and so on, or observability, which is a must in the era of microservices for instance.

What I'm observing certainly, and it's interesting and it's been going for years and years, we just didn't have a name for it again because obviously there was some sort of CI/CD or maybe CI at the time and then throwing it over the fence. But then CI/CD and things are obviously getting better and more sophisticated, and now we are looking at essentially complete pipelines and life cycles for software delivery that combine a lot of maybe lower level products because everything is API-driven or has some sort of interface.

A lot of folks, ops and dev alike end up being essentially both designers and architects of those systems. So certainly architecture principles, I guess you name coupling and cohesion and all manners of naming things and structuring composition and so on are good things to bear in mind.

Eran Stiller: About what Rafal mentioned, he mentioned that everything has an API. I'd like us to look at another take on this where everything is becoming code. We heard about infrastructure as code for a while and have multiple Terraform Pulumi, various platforms that do it. We now have CI/CD as code with things like Dagger, although again the concept existed before. We configured CI/CD pipelines in code for a long time. Once everything becomes code, software architecture principles start applying on it.

So for example, if you look at your deployment pipelines or your deployment methodology, let's say you build a microservices system. The deployment itself can be a monolith, it can be in a mono repo, it can be multiple repos, it can be distributed so every part of the system gets deployed and tested independently. There's a lot of decisions to be made here, and I think this is another area that architects should be aware of. They can't completely ignore it, say, "Oh, this is the DevOps. This is the platform engineering. That's their problem." No, it's our problem as well.

Daniel Bryant: I think the same goes to the data as well. I was just going to say, you've got Blanca, as in the data here right is really key as in not quite data as code, but as in data mesh we've talked about off mic, that kind of thing. I was curious what your experience is like. Are the CI/CD pipelines, are the platforms in the data space as good as the other platforms?

Blanca Garcia-Gil: I think it's coming a long way. My most recent experience has been working in teams that are made up of people with very different backgrounds so people who come from long time working in data, also people coming long time working in software architecture. When you get all those people working together is when you can achieve the best of both worlds. I think there's still organizations that these things are still a bit separate, but I think the trend is more coming together.

Thomas Betts: That's where I go back to, we need a name for it, everything works better when we have a name. Before it was called DevOps, they were just high-performing teams. The teams just talk to each other. I worked in organizations where you only had a few people and you had to be the chief cook and bottle washer, you did everything. I became really good at running the server and writing the code because no one else was around. And now you get to bigger companies and you had these silos, and you look at Team Topologies and it's ideas like you got to break down the silos.

Eran, I love the comment that everything is code and so platform is just one more piece of code and treat it like code. That was when DevOps became useful. The software engineers talked to the operations people and they said, "Well, if I could solve your operations problems with code, I'd do this," well, why don't we do that? And they just started working together, get the people together, solve the problems together, it's going to lead to a better outcome. I think I said that 10 minutes ago in the podcast.

Classic software concepts [32:34]

Thomas Betts: I'm going to get us to a wrap up topic because I think we've hinted at it a few times the idea of these classic concepts in software engineering, software architecture that just keep coming back. We mentioned it with the cell-based architecture, not a new idea, but we're using it domain-driven design, you called out was a good thing for teams to start using, the book's 20 years old. Let's start following those ideas.

People came up with some great ideas in the '70s that we're finally able to implement because we have the infrastructure and the tools and the cloud and whatever else available. I'd love to hear some thoughts about that. Blanca, you can go first. What do you see as some ideas that have been around forever that people are finally latching onto?

Blanca Garcia-Gil: I think for me, it's been going to microservices, then going the other way back, and now I think what we were calling right-sized services because in a time that hey companies are ever more conscious about the costs of the tech that we run, architecting things thinking of the now and near future but not thinking of scaling for the next few years. I think that has been the bigger thing for me and how that is also applied in data where data workloads can vary enormously. How can you build those data architectures in a way they can scale without spending too much money? So you can maybe cater for some big days, but you are basically paying with your wallet upfront too much.

Thomas Betts: Rafal, what do you think?

Rafal Gancarz: I think it's good that we are talking about it, because it's certainly a recurring thing. Obviously, as architects we've been experiencing the evolution of the IT industry, I think. Things come and go, but the fundamentals remain the same. I guess this is important to understand whatever we are doing is actually perhaps more important to work out what it is we are trying to achieve first in terms of the actors maybe and interactions between those actors in the system on paper really without referring to any technology choices.

I think people always have been and are still quite drawn towards jumping into what we call solutioning, and trying to apply a well-known pattern or maybe popular pattern to a problem without necessarily considering what is the end goal of the initiative or the exercise we are trying to achieve. I think it's always important to make sure that we cover the basics, and we get the foundational elements right before talking technology choices.

Thomas Betts: Eran, your thoughts?

Eran Stiller: I think it all comes down then to what Daniel mentioned earlier and probably everybody else coupling and cohesion. So basically how you decouple your systems, what are the boundaries of responsibility and so on. I think my greatest lesson from all this journey to microservices and back is don't design by hype. Always know what's new, know what's modern, know all the new stuff, new technologies can make your life much easier, but don't design by them. Always think of these basic principles, and design according to your non-functional requirements or quality attributes, things that you need to achieve now, with an eye on the future.

Maybe you'll have 10 million customers in a few years from now, don't design for that if right now you may be maybe 100, 1000 customers on a good day, don't go with all the complex technology, do something simple. Make it so that you can evolve your architecture and modernize it over time and pay the price for it whenever the price is justified. I think we always need to keep those basic principles in mind, and then look at all the new stuff that's coming out all the time.

Thomas Betts: Daniel, you're up.

Daniel Bryant: Yes, fantastic comments by everyone. I think as I've got older and hopefully a little bit wiser, I have two tracks to my learning. There is, as Eran mentioned, the latest hotness. I just love learning as again Rafael mentioned, Blanca mentioned because we're part of this QCon/InfoQ community, naturally we love learning, we have the growth mindset, right? So we are just constantly like what's the latest hotness? But I think there's another dual track to that. I'm always trying to refine the classics, the timeless patterns, and particularly in my consulting career, I really find myself falling back onto models, onto patterns and all these kinds of things.

I definitely think a whole bunch of stuff we've talked about today is around David Parnas' stuff, which I think is '60s, '70s. Information hiding. Again, coupling and cohesion. I've had some really interesting conversations with a couple of folks of late and they're like, "Stuff from the '70s, that's really old." I'm like, "It's classic," right? As in we are building on all this stuff. I like to think we are making progress, but I think someone said it to me, it's almost like a spiral we're going around, do you know what I mean?

Maybe actually you said this, Thomas, we had a private conversation or whatever, and it's not a perfect up and to the right situation, but we are spiraling in the right direction if that makes sense. I hope it works for the podcast, but we are continually building upon what we've learned, but it's not always in the straight line direction. So for me, it's always that learning the latest hotness. Looking back, I really enjoy reading the classic books and I've already taken a couple of notes to that. I've not heard that book you mentioned, Rafal, which is fantastic, but building on the classic patterns as much as keeping up to date with the latest hotness too.

Thomas Betts: Yes, I think one of the topics we didn't get to in today's discussion but was on our list was edge computing. We were talking about this again before we started recording off mic, the idea of run your code where it makes sense, push it to the edge. I think, Blanca, you were going to say that way, save costs. People are finding these ways, it's not just about distributing the resources, it's running the right place. Well, that's not a new idea.

We had mainframes because that was where the server was when you had a dumb terminal, and then everybody got PCs and all of a sudden we pushed all the code to the PCs, and then well, let's put it back on the servers and we're going to go back to these web-based machines. And the web interface was just straight HTML, all the processing on the server. Oh, well now we can run JavaScript and it won't crash my browser, put the code back on the client. It continually goes back and forth and back and forth in that spiral.

And I think I saw that slide at a conference in 2005. That's a 20-year-old idea of that spiral of going back and forth, and we're still talking about it today, so keep reevaluating. The reason we have those swings is because we keep finding new ways to do it because our requirements change. Some of the reason for distributed as a smart client web app or whatever you're going to do is how do I deploy my code? And this gets to the idea of platform engineering. How do I get my code to the customer who needs to use it?

Those are the things we always have to think about. What's the new technology that's going to make it easier for me to get my code out faster to market faster to the customer, more useful, less latency? All those things, keep going back to the classic, basic understanding of what makes good architecture. What are your quality attributes, what are you trying to achieve? What you may have used five years ago probably isn't the right decision today. What might be the right decision today may have been closer to what you did 10 years ago. So don't throw it out just because it's old, sometimes it's classic.

Final wrap-up [39:29]

Thomas Betts: Any final thoughts people want to throw in before we just wrap it up? Anything we didn't talk about? A thing I'm looking forward to in 2024?

Daniel Bryant: I do think to Blanca's point off mic, the sustainability in green revolution is really important. We talk a lot about ethics. I think it's really important for AI, but we've got that covered in another podcast. I know Shane and the team on culture methods have looked into a lot of that. But I do think we're seeing, I've got a shout-out a few folks like the QCon.

I think we've got a track this year in QCon London focusing on sustainability run by Anne Currie, and Anne's awesome has been banging that drum for a long time, and Adrian Cockcroft jumped in the mix. A whole bunch of folks are looking at that so Blanca, I don't know if you're involved in that track or you looked at that track, but I do think the green software push is really important, right?

Blanca Garcia-Gil: Absolutely. I am not directly involved in that track, but I am part of another architecture track and we're also going to be touching on green software because it's such a big topic and I know there's some books, one from Anne Currie that are coming up soon so I'm looking forward to that.

Thomas Betts: Rafal, anything that you're really looking forward to? New stuff in 2024?

Rafal Gancarz: Well, I think it certainly is quite exciting in AI space. I think there is fair amount of hype. I just want to see, I think more of applied uses of AI beyond generating things from other things I guess. I think we touched a little bit about it, more customized or tuned applications of AI, and AI based products that are addressing specific needs. I think this is happening obviously partially through the automotive industry. I think there is a lot of investment, a lot of research in that space, and some other areas as well.

So inevitably, it will be happening. I'm pretty sure that it's going to be impacting us more and more. I'm certainly suspecting that the trend I guess, or the evolution that for instance machine learning has been going through and what we call MLOps these days. I think maybe in a year or two, we'll be probably talking about AIOps because there will be products and architectures that are either driven or powered by AI, or certainly AI-enabled so we'll be concerning more and more about how best to incorporate AI into things that we are building.

Thomas Betts: Eran, final thoughts for what's coming forward in 2024 for you?

Eran Stiller: I think we've pretty much covered everything, but to add one more thing that we didn't touch, which I'd like to look at is the concept of privacy engineering, which we didn't get to discuss today. But basically it's the idea of how do I incorporate our user's privacy into the architecture of the system. So it could be simple things like don't log personal information of your users into your log which is kept for, I don't know how much time. Or don't store information that you don't really need. Ask yourself, do I really need to store this information? And the best way to protect it is not to keep it.

But it could be more complex topics like if we have users' data and we need it for analytics, how can we protect the user's privacy by it could be by anonymizing it, it could be by aggregating it, it could be by removing some of the data. And like I mentioned earlier, data is part of things that architect needs to do and needs to be aware of things. It's one of those things that we see more and more, especially as regulation keeps piling up across the world to handle all kinds of topics around that area.

Thomas Betts: You guys covered everything that was on my list we didn't talk about, so I'm not going to add anything. I'm going to say thank you to everyone for joining us today on the podcast, contributing to this discussion, and a reminder to the readers that this is just half of the InfoQ Architecture and Design Trends Report for 2024. The other part, the printed report, the written report, including the fabulous trends graph, will be available on infoq.com the same day that you can hear this podcast. So we hope you go download that, check it out, and share with your friends. And we hope to see you again on the future episode of the InfoQ podcast.