Transcript
Thomas Betts: Hello and welcome to the InfoQ podcast. I’m Thomas Betts, and today we will be discussing the current trends in software architecture and design for 2025. One of the regular features on InfoQ are the trends reports, and each one focuses on a different aspect of software development. These reports provide InfoQ readers with a high-level overview of the topics you want to pay attention to. We look at the innovator and early adopter trends to see what they’re doing and maybe it might be appropriate for you to adopt in the next year or so.
Now this conversation today is just one half of the trends report. On infoq.com, you can find the trends graph and the written report, which has a lot more information about topics we might not be able to go into detail today in this conversation. Joining me today are a panel of InfoQ editors and QCon program committee members, including Eran Stiller, Daniel Bryant and Sarah Wells. So let’s go around and do quick introductions, starting with Eran.
Eran Stiller: Hi everyone. My name is Eran Stiller. I’m a chief architect at Cartesian, which is a small startup, six people startup, which is always exciting. I’m also an InfoQ editor for the past, I don’t know how many years. And I think as every year, I always wait for this trends report. I think it’s one of the fun things they do every year. So yes, can’t wait to start.
Thomas Betts: Daniel?
Daniel Bryant: Hi everyone, Daniel Bryant. I work at Syntasso on platform engineering. Long career in development and architecture as well. And again, I’m very lucky these days I get to work with a lot of architects in my day job. Super excited to be writing for InfoQ as well, doing news management and helping out at QCon whenever I can as well.
Thomas Betts: And finally, Sarah.
Sarah Wells: Hi. Yes, I’m Sarah. I am chairing the QCon London program committee this year. I am an independent consultant, an author with O’Reilly, and my background is as a tech director and principal engineer in content API, microservices, DevOps, platform engineering, a whole bunch of areas.
Thomas Betts: A little bit of everything.
Sarah Wells: Yes.
Thomas Betts: And myself, like I said, I’m Thomas Betts. My day job, I’m a solution architect for Blackbaud, which is a software provider for Social Good. I’ve been doing this software development thing for longer than I care to admit and been an InfoQ editor for almost a decade. So like Eran said, this is one of my highlights of the year to be able to talk about these things and write up the report.
AI for software architects – LLMs, RAG, and agentic AI [02:43]
Thomas Betts: So I think to get started, it’s 2025. I think we have to call out the 800 pound artificial gorilla in the room, AI. Now there’s a separate trends report on InfoQ that’s dedicated to AI, ML and data engineering. I highly recommend it. It’s great for getting into those details of what’s underneath that AI umbrella, but this is the architecture and design trends discussion.
So I want to focus on things that architects care about and we can’t ignore AI anymore. So what are the big concepts that are bubbling up and we have to integrate into our systems? What are the trade-offs that architects need to consider regarding solutions? I know a year ago the trends report, we called out LLMs, were just brand new, but within a year they were already early adopter technology, but a lot of those cases were glorified chat bots. So Eran, I’m going to start with you. What’s changed in the past year? What are we seeing, the innovation that architects had to respond to?
Eran Stiller: Yes, I think that the landscape is just exploding. Like, in terms of architects, the amount of things that we need to know now that we didn’t need to know, I don’t know, two years ago, it’s just mind-blowing. For example, whenever I look for articles for InfoQ, like to cover in InfoQ, the amount of AI topics that I go through that are directly architecture related is amazing. You mentioned LLMs, which is the big elephant in the room. We’ve all been using it, but now it has all kinds of these satellite technologies around it that we also need to be aware of. And sometimes we use them as a service, we don’t care how it’s built, we just have an API, we just use it and that’s it. And that’s great. As an architect, you don’t need to know everything, but you need to know it exists. And sometimes you need to implement it yourself.
So some examples include RAG, retrieval-augmented generation. So basically, which is a simple way to enrich the context for an LLM. We want to use an LLM, you don’t want to train the model yourself, but you want to fine tune it to your own needs. For example, you’re in organization, you have a bunch of documents, or maybe you’re an architect, you have a bunch of ADRs, you want to ask questions about them, and you want to know why was something done two years ago, three years ago and who did it. So you can use RAG to enrich that content. Again, as I said, we’re not going to go into detail of how it’s done, but when I look at various articles that big companies, their authors write, they often use it to do various things to achieve in their systems. So RAG is one.
We’ve also recently started seeing growth in systems that are called Agentic AI. Before that it was called AI Agents. I think they changed the name to Agentic AI. Again, in a nutshell, basically what it means is you give AI a bunch of tools that it can use. So for example, it can go search the web, it can go and call some API call. And you give them, the AI, some description of these tools, what they can do, how to use them. There’s a protocol around it which Anthropic introduced. It’s called MCP, like a model context protocol, if I remember. I hope I’m not wrong in the acronym. And basically, it makes things more interoperable. It can use more stuff around it. So again, a lot of acronyms, a lot of things you need to know. As an architect, you don’t necessarily need to know the nitty-gritty of all of it, but you definitely need to know what you’re doing and you don’t want to be caught off guard.
Thomas Betts: Yes, what is the shape of the box on my diagram? Like, “Oh, here’s an LLM. Well, what is it used for? When would I use it?” And I’ve seen a lot of people thinking you can use an LLM for everything, I can put AI in anywhere. And they don’t realize, just like any software tool, there are trade-offs, right? These are non-deterministic software. If you wanted to have the ability to calculate numbers exactly, it’s not good at that. It’s great at predicting the next word, but it’s not great at doing simple math, so don’t ask it to do that. Don’t think you can replace all of your software with a bunch of AI boxes. I think the Agentic is one of those things where it goes one level higher, and this is where architects have to start thinking about, “Okay, so do I have different components in my system that I can have parts of AI operating together?” Daniel, have you seen stuff like that too?
Daniel Bryant: Yes, I mean I think the interesting thing that, to me, what you were saying there, Eran, is the MCP stuff. Because my previous space was very much focused on API’s. I think the angle I’d look at it, what I’m most interested in, is as an architect thinking about my responsibilities in relation to the API. So, I mean, it applies for whatever you’re sending over the wire to any third-party AI, but to your point, people are almost putting everything into LLMs. Before you know it you’ve got like PII, personally identifiable information, private information, stuff that shouldn’t be going over the wire.
Now we as architects need to have a handle on that, right? What’s being sent, how’s it being processed? Like in the UK and EU we have GDPR, but there’s many of the laws across all the lands around the world. But I think that’s what I’m most interested in at the moment is, as we’ve all said, they’ve taken the world by storm and we are, as architects, almost not getting time to catch up on some of the impacts and choices we are making around the security, the observability, the extensibility, the maintainability. All the other things we love as architects are kind of being thrown a little bit out of the window. So I’m encouraging folks to think good design principles, think good data hygiene, think good API design. That is really important, regardless of what you’re calling into, but very much with LLMs and this AI services.
Sarah Wells: I think that’s a really interesting challenge for architects, because every business wants to tell a story about using AI. So there’s a lot of pressure to get something out there really quickly. So you want to put in all of the -ilities, but how do you push back on someone saying, “Well, no, but I need to have it. I need to be able to tell this story next week”. So I think it’s always true that you’re balancing those as an architect, but there’s a lot of pressure on it right now.
I was talking to Hannah Foxwell earlier today. She’s going to give a talk about Agentic AI at QCon London, the closing keynote. And she mentioned just in passing about thinking of the agents like they’re microservices, because when you’ve got different agents that have different skills, so they have different things they can do, you’re composing them together to deliver some level of functionality. And I think that seems to me a really useful way for architects to think about this. How are you going to put multiple boxes together and the things around that to check whether you are actually just passing rubbish information on between agents.
Thomas Betts: Right, right. And then it goes back to some of the things Daniel was mentioning. You talked about the security aspect of it. You don’t want to send the LLM all of your personal PII data and all your customer data. How do you scrub that down so you send enough information that’s useful? And when you think about it, like microservices, I like that analogy because a well-designed microservice architecture, you have very clearly defined context boundaries, right? Like here’s the contract of how you talk to me, and here’s what I share with you. I may have a lot of private information stored in my database that I’m not going to share with you, but here’s what is in that public contract. So the thing about the agents, in that same way, really seems to mesh with my idea of how to design a system into reusable elements.
Eran Stiller: Or as an architect you can decide, “Well, I really do need to send that private information”. And then you can think, “Okay, maybe I’ll run that LLM locally”. And then you get into the big, entire world of open source LLMs and how do you run them? It goes also into the platform architecture. How do we scale them? How much would it cost to run all these LLMs? Maybe something about, “Okay, maybe..”. We haven’t mentioned, there’s also something that’s called small language models. “Maybe I’ll run this fine-tuned small thing that can do what I want”, but you really need to understand all these things in order to make these decisions.
Thomas Betts: We have a trend, I think it’s on the early adopters, the edge computing. Architects are thinking about how much more code can I put closer to the user, because then there’s no latency going over the wire. And if I can put the large language model, well that’s too big, but I can put a small language model and it can do enough, or I can make it specially trained for that use case, that’s going to run in that environment. This gets back to, we now label everything with AI and a lot of times it means LLMs, but some of this is just core machine learning. And like I said, we’re not going to go into the details, but this is… Create a small model. Maybe it’s a language model, maybe it’s some other thing. So those ideas have been around for a while. We’ve been able to distribute smaller models before, it was just when the large language models became big a few years ago that they became enormous, right?
This wasn’t saying you could run on your machine. So how do we get to the other side of the teeter totter and move the scales? So the last thing I wanted to talk about with AI was the role of the architect in an AI assisted world. Because we’ve had this topic on the trends report for… In a various form for the last, I don’t know, five, six, seven years at least. Architect is a technical leader. Socio-technical considerations, architects need to worry about. I’m not saying I need to bring the AI into my socio-technical aspect, but maybe I do. Are there things that I can design with Conway’s law around a team? And then well, is it a team that’s made up of AI programmers or software engineers who are augmented by more AI? Can I make my architecture decisions better because I’m using the AI to search my previous ADRs? Or I can ask it to review an ADR before I go and present it to someone else? Has anyone else run into people doing their job differently because this is just a new tool they have at their disposal?
Eran Stiller: I think I’ve started doing my job differently as an architect because of these tools. For example, as an architect, one of the things you’re naturally expected to do other than architecting the system is mentoring team members, deciding on coding standards, coding guidelines, code quality, and how do we do code reviews, stuff like that. And now when I have all these tools, I can actually use them as part of my job to do all these things. So for example, we have various code assisted tools like GitHub, Copilot, Cursor, whatever. There are many of them, and I know at least some of them, I don’t know all of them, but at least some of them have this mechanism where you can fine tune them, you can provide rules on how to help your developers. So for example, specifically in my company, we’re using Cursor and it has a mechanism that’s called Cursor Rules.
And what that means, you can provide the… You can tell it, “Okay, these folders are React apps and these are the best practices we implement when we write React, and these folders do that and these folders do that”. And you can provide as an architect all your guidelines there. And then when your developers use the tool to write code, because I hope they do it because it makes them much faster developers, more efficient developers, then they get all of these code guidelines already built into what they’re writing, which makes my work easier as an architect. So I think definitely there’s lots of places we can use them, we can extend it to how do we do code reviews and so on, but that’s my 2 cents.
Thomas Betts: Yes, I think we’ve had things like linters and an editor config file that says, “Oh, you need to put your curly braces at the end of the line. No, on the next line and two space tabs”, and whatever.
Eran Stiller: It’s the high level.
Thomas Betts: You can define those things, but they’re very much at the syntax level. I think what architects… Some companies have been able to introduce fitness functions and say, “Okay, this can tell that this module is adhering to our architecture guidelines”, but those are often more squishy. And so I think there’s going to be a place where we might be able to see some AI based tools be able to just analyze the code, not straight from a static analysis like, “Oh, you’re using an out-of-date library”, or “You didn’t follow this”, but does it smell right? Did you do the thing correctly? Did you follow what we’re trying to do? Help me with my pull requests before the person has 10 years of experience again, weigh in and say, “You know that’s not how we write things. You should pull this out into a separate method”, that type of stuff.
Cell-based architecture for resilience [15:31]
Thomas Betts: So last year we added cell-based architecture as an innovator trend and we’ve seen a lot more companies adopting this as a strategy to improve resiliency, but it also has potentially good cost and performance benefits. Daniel, you want to give us a quick refresher on what’s the idea behind cell-based architecture and when is that pattern appropriate?
Daniel Bryant: Yes, sure thing, Thomas. I mean, it definitely dovetails on microservices, which I’ll doff my cap to Sarah. Here you’re the expert in the room on microservices, so we definitely hear from you in a second. But Rafal Gancarz did a fantastic eMAG for us in InfoQ talking about the cell-based architecture.
For me it is an extension to microservices, and you focus a lot more on the cell as the unit of work here, and you are isolating… It’s almost like a bounded context plus plus. It’s a cell of work and you’ve got very strict guidelines around bulkheads and failure. A lot of companies… We saw great talk, I think it was QCon San Francisco by Slack who used a cell-based architecture and they’d architected these cells, so if one cell breaks, falls over, gets compromised or whatever, it doesn’t take out the whole system. So it’s microservices, but with a much stricter boundary in my mind, and the way you operationally run them is interesting from an architecture standpoint, because they have got to be isolated. But I know Thomas, you’ve done a fair bit, I think, of work with cell-based architecture as well, right?
Thomas Betts: Yes, I mean I haven’t personally implemented them, but the coverage on InfoQ definitely exposed me and we’ve seen a lot more companies writing on their own blogs of, “Here’s how we did our cell-based architecture”. So that’s how we can tell it’s being adopted more. I like that it was, “Okay, we’re going to build all these microservices”, and then things like a service mesh, because I need to do service discovery. We had all these other tools come in, but you can get to the point where if one goes down, then I don’t know how to contain the blast radius and how do you impose logical boundaries around those things? So it’s a little bit of, “I want to be deployed into multiple availability zones, but thinking about that a little bit more and sometimes bringing in the business context, not just the technology side”.
So it’s like, “I want to make sure that customers in the East Coast or Europe or wherever they are are served the closest traffic”. We’ve had those patterns for a while, but when something fails, how do we make sure that that doesn’t blow up the rest of the region or take them down entirely and they’re still able to do their work? I mentioned the cost and performance benefits. Sometimes because you start restricting the boundaries and say “You can only call somebody else in the cell”. You’re not sending that traffic over the wire, over the ocean maybe. So you’re making a lot more closer calls. So sometimes things just get faster because you’ve put these constraints around it. But Sarah, I’d love to hear your ideas, because I think this is core to things that are in your book.
Sarah Wells: So it’s really interesting because I think I was thinking about these things without knowing cell-based architecture as a term. Certainly when we were doing microservices at the FT, we had a lot of cases where we thought, “Well, how can we simplify what we’re trying to do to make it easy for us to reason about what might happen when things fail?” So for example, we had parts of our architecture where we decided we didn’t want to try… We basically were going to have databases in different regions that didn’t know anything about each other. So that in theory, the same data in both, but we’re not even attempting to double-check other than occasionally counting records, just to simplify what we’re trying to do.
We did the same thing with calls between instances. Well, do we want to call to a different availability zone to a different region? We’re not going to go across regions. So I think providing the context for how you decide the terminology for making those decisions, because people often talk about things like bulkheads, but it’s quite far down the list of things you do in a microservices architecture, because it’s confusing. Everything that you have to consider is confusing. So you’re like, until you have a massive incident, it’s normally not the top of your list. But if you can start off by thinking in terms of, “Well, which of these services hang together? How could we split them up? Where are we separating our data?” I love the idea that you can save money by deciding that you don’t make calls across availability zones. I just think, well, that seems like a really sensible idea.
Monzo Bank’s unorthodox backup strategy [19:47]
Thomas Betts: And I think there’s a parallel discussion here. Eran, you wrote the article about Monzo and their backup strategy, which is sort of related. That was their thinking of, “If something goes down, how do we have a backup?” Because an online bank, “How do we have a backup bank?” But it wasn’t as simple as like, “Oh, we have two cells that are identical”. Can you go into the details of how they thought through that problem? I think it’s an interesting one.
Eran Stiller: An interesting one, and I saw some interesting discussions about this item online after I posted it, where in that case… I think we should probably have a link to the article somewhere. Basically what they’ve done is instead of having an identical replica, which is what we usually do, we have this standby or active-active or whatever it is that we do, they follow, “Okay, in case of an outage, what from a business perspective, what are the most important things that we want to keep alive? What brings us money?” In their case, it was transactions. We want people to be able to use their credit cards and buy things, because if they can’t, it’s going to be bad for the bank obviously. And once they had that list, they architected their, how do you call it, the secondary zone or their backup deployment to only implement those things.
And that means that the environments are not identical. And that means they brought business insights into the way they implemented the backup strategy. And so what they said, “We have this main environment, it does everything, but we have this small thing here on the side that’s isolated, and that’s very much aligned to the cell-based architecture concept”, even though it’s not a cell-based architecture. But the concepts are the same. “We want to have this isolated, we want to have separate, we don’t want to have common points of failure”. So one of the things they’ve done, for example, is they didn’t take a subset of the services and just deploy it to the secondary environment. They wrote a new set of services, it’s a different code base. And I remember reading it, even when I was reading it first, I said, “But why? It’s such a waste. You’re writing all this code and how are you going to test it? It’s on backup. How do you know it’s even going to work?”
And I actually chatted dollars, I asked them a bunch of questions about it and I actually came to learn and appreciate this approach where it’s a separate call base. So if you have a bug in the main environment, that bug is not going to overflow to the secondary environment. It’s still going to be there. And then in regards to how do you test it, where you test it in production, every day, it takes some percentage of the traffic and you route it there and you see it works and you compare it at the end. So it’s not only when there’s an outage, you run it all the time just on a small subset of users who get the emergency experience. Fits well with the cell-based architecture theme of, “We want this stuff”.
Thomas Betts: And it goes back to what are the -ilities that the architects care about? In this case resiliency, the ability to survive an outage, whether that’s code that didn’t run or the availability zone goes down. Like, “We need to be able to still run the business. How do we solve that?” And it’s clearly a case of one size does not fit all. Even the cell-based architecture is not a, “I can just press this button and boom, I have a cell-based architecture”. You have to think about it. In Monzo’s case, they made a lot of decisions to implement things differently. Like you said, a different code base that seems like a waste actually provides extra reliability.
Privacy engineering and sustainability [23:20]
Thomas Betts: So those types of trade-offs show up everywhere. And I think it’s just one of those things as an architect you have to consider, “Is there some different way we want to solve this?” And that’s what I love hearing about these innovative stories. I would not have built a separate smaller backup bank, but I can definitely see the benefit of it. I think the other thing we’ve seen about, not just thinking about reliability, but some of the new trends we had were privacy engineering, and sustainability and green software came onto the list last year. Sarah, you made an interesting comment before we started recording, that we need to have a shift left mindset around these things, about the adoption. Can you tell us more about what you were thinking of when you said that?
Sarah Wells: Well, I just thought that this is the architecture equivalent of all the shift left things that were happening in software engineering where people were involving testing earlier, involving security earlier. It feels like it’s the same pattern of, “If you consider this early, it’s less costly to do it. You can build it in from the beginning”. So if you think about you’re building your architecture so that you are considering privacy, so you’re thinking carefully about where you’re putting that data. And I think there are lots of places where people suddenly go, “I have no idea where I’m exposed and where private data may be stored”. And I think with sustainability and making sure you’re not incurring too many costs, often you only look at that after you realize your bill is really high. But if you think about it early, it’s great. But I think you might face some of the same challenges, because you have to convince people that you should spend more time investing in the thing that the moment isn’t critical.
So if you’re starting to think about how do I build this so it won’t cost a lot at the point where it isn’t costing a lot, because you haven’t built that much of the system, but it’s kind of tough in the same way that it can be hard to persuade people to invest a lot of time in thinking about security when they haven’t yet built a thing that they know they can sell. So I thought that was just an interesting pattern, and I wondered what else might move earlier in the architectural thinking, other things, because obviously with shift-left in engineering, everything gradually just moved left.
Thomas Betts: The left keeps moving, right? The goalposts keep going. You just have to keep going more and more left, because who’s doing this. Daniel, you were nodding along. I know this is some of the platform thinking. I think that we’re going to get to that a little bit more, but how am I going to deploy it? How do I secure it? How do I make it sustainable or use less energy or less carbon? All those things come into play at some point. Are you seeing in your day job, or in stuff on InfoQ, people talking about these trends earlier than they were before?
Daniel Bryant: Yes, for sure. And to Sarah’s point, I definitely see a split, because I’m very lucky, I get to work with startups and then big banks and other enterprises as we call them as well. And the startups is fundamentally like, “Can I get product market fit?” So they are not even threat modeling sometimes, they’re literally just like, “Hey, I’m going to put this thing out there, if I get some customers, we’ll get some funding and then we’ll think about doing this stuff”. And more power to you if you are a startup, that’s how I like to work. Sounds like, Eran, you’re in that space too.
I like the startup vibe, but you’ve got to respect it’s a slight hustle until you get product market fit. But the big banks and so forth, they are doing what is akin to threat modeling, but more green modeling, if I’m making up the term, I’m not sure if that is a term, but you know what I mean, right? They’re doing more analysis. They realize that running things green, not only is it good for the mission, but often it’s cheaper, more cost-effective should I say. So they are spending time now. I think the shift left message has landed with a lot of architects, particularly in enterprise space.
Eran Stiller: And they even showed on the UI, they show, “Hey, you’re in this mode right now because we’re testing and they can opt out if you want”. So that’s like an innovative approach. Also, as I said-
Daniel Bryant: They have a clear line to justify it, but if we threat model now we spend a week doing this, it’s going to save us maybe six months of battle testing at the end. If we bake it in now, it’s going to cost less. Same thing with even the green modeling or thinking about your carbon footprint. It’s so much harder to get rid of that cost at the end of process than it is at the beginning.
So I’m definitely seeing folks doing that. Softly, softly. And I do think to the points we’ve made at several point in this podcast, the tools really need to help you do this, whether it’s AI powered or not, but something I talk about a lot on my team is there’s always a certain amount of cognitive load. And the danger is if you’re shifting stuff left, you often shift that load left onto other people. So it used to be the security folks, the cost, and us folks at the end of the pipeline, now it’s being shifted onto us as developers, us as architects, and without the tools, you just get cognitive overload. You just get overly burdened.
Commoditization of platform engineering [28:00]
Sarah Wells: Isn’t this an opportunity for platform architecture, for building the stuff into that platform so that people don’t have to take on that cognitive load? It’s already there in whatever you’re deploying, the tools that you’re using, everything that’s there is your foundation?
Daniel Bryant: A hundred percent agree, Sarah. This is what definitely I’m seeing in my day job. Folks are trying to feel platforms, even more so the context I’m working in with compliance in mind, “Making it easy to do the right thing”, is a phrase I find myself saying a lot. And again, I’m quoting other people standing on the shoulders of giants here, but yes, a hundred percent Sarah, to Eran’s point, they’re baking in certain rules and checks along the way, but even some guidelines and so forth in the tools early on in the process to make it easy to do the right thing.
Thomas Betts: Yes, and that’s where the architecture… And this is where platform architecture I think is the term, is the thinking about how do we make a platform that takes some of that cognitive load off the people who are going to be actually driving the carbon usage, the privacy concerns, the security concerns. If I have to have 10 teams and they all have to think about, “How do I make my data secure”, and “How do I make this call”, or whatever it is, if they all have to think about that, that’s distributing the energy and the cognitive load around versus, “Okay, we have taken the time to figure this out, solve it in the best practice way. And if you get on our paved road platform solution, maybe you could do a little better, but you’re going to do pretty good for everybody”.
And I think that’s the good enough approach that architects need to try and get to, not the, “Perfect as the enemy of good enough”, that we want to have the solution that applies to enough people. Because if you wait until the end and then you get some, “Oh, here’s a GDPR”, and pretty soon the only solution is, “Let’s just secure everything because we don’t know how to secure in just the little bits that we need to do”.
Sarah Wells: I always think that you don’t want people to have to go and read something that explains to them what they’re expected to do. You want to just make it so they can’t do it wrong. That’s an architectural thing. Make it so that people can’t shoot themselves in the foot.
Daniel Bryant: Yes, well said, Sarah.
Thomas Betts: The last thing I wanted to talk about for platforms, my sense Daniel, is in the last, say five or 10 years ago, this was much… You’d have your DevOps experts on staff and they would have to be building your paved road, your engineering system, whatever it is. A lot more of that custom code has just become commodities off the shelf software. And first two questions. One, am I correct in that assumption? And second, how do architects respond to that when we’re shifting from a build versus buy mentality for the platform?
Daniel Bryant: Yes, I’m seeing tools that a lot of the platform architecture and the software architecture is symbiotic. I’ve done a talk actually at KubeCon last year about… It was platform engineering for software architects, was my pitch, because I’m bumping into a lot of folks. I think I’m going to KubeCon soon, and the largest chunk of the audience are actually application architects going to KubeCon, which has historically been a very much Kubernetes platform shaped conference, which again, I grew up in, I know and love, but when architects started rolling in now I was like, “Oh, these conversations I’m having with folks are very different”.
But there, to Sarah’s point earlier, they’re being told that you’ve got to go Kubernetes, because some vendors are actually packaging their software as Kubernetes packages there. “If you are not running Kubernetes, you don’t get access to the latest version of the certain checking software or verification software”.
I’ve literally heard that in banks where they’re buying off the shelf components, and it’s now being packaged as Kubernetes components. And if they don’t have Kubernetes, that’s a problem. So I think the application architects are having to be much more aware of what platforms… How to define them, what they offer, these things. Now, I talk a lot about platform as a product. You have to have a platform that makes it easy to do the right thing from getting your ideas, your code tested, verified, secured, all the way through to adding value to users in production.
And as we’ve said a few times in this podcast, make that process as pain-free as possible. But as an architect, you’ve got to know all these things. It is another thing, another group of things to learn about Kubernetes, Serverless. There’s all those various vendors that Heroku and Vassal offer different forms of platform as a service and you often get them popping up a shadow IT in big enterprises. So you have to be aware of these things and offer guidance as to what is the way to do things in this company. “We lean towards this approach. We don’t go here because here’s the trade-offs and we don’t like these trade-offs”.
Thomas Betts: Yes. Yes, I made a comment, I met with some of my coworkers last week and the product manager for our platform that we build, our engineering system, I told him, “I don’t speak Kubernetes, and thank you for that”, because that’s a huge win for me when I’m doing the architecture. I know that the pods are going to get created and I can say, “Oh, I need four, I need two”. Now, there’s times when I need to know what that means underneath the covers, but most of my day I don’t need to. So it’s like when I need to dive deep, and this is the T-shaped architect, I need to be broad in a lot of topics and then be able to dive down and the things that I don’t know about, I want to know who are the experts that know that.
And so that goes back to the same ideas of compartmentalization. Put the microservices together, have these little pods, whether it’s people or servers of where’s the specialty? How do I do that? Is it an Agentic AI that I’m calling to do that, or is it the platform team or is it this very specific stream aligned development team? So being able to think in those pieces helps reduce the cognitive load on the architect, because now you don’t have to know about all the details all the time.
Eran Stiller: But I think it’s very similar to what you mentioned about the AI, that you don’t necessarily need to know the nitty-gritty, how it works and how to implement it, but you need to know it’s there and what it gives you and how you can use it to your benefit, and what are the pros and cons of each, again, at a high level. Because if you do know these things, it’ll make your job as an architect much easier, and you’ll probably be able to do a much better job with it. And that’s where I think also QCon fits in and all the other conferences that you go and learn this stuff.
Closing thoughts [34:15]
Thomas Betts: I’m going to leave it there. That was a fantastic wrap up, Eran, saying that we need to know the high level aspects of what are these things, and then if I need to dive deep, just go read Qcon.
Eran Stiller: I love that.
Thomas Betts: Go to attend Qcon. So I want to thank everyone again for attending today, Eran, Daniel and Sarah, thank you for being here.
Eran Stiller: Thanks.
Sarah Wells: Thank you.
Daniel Bryant: Thank you very much.
Thomas Betts: And we hope you’ll join us again for another episode of the InfoQ podcast.
.
From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.
