API Evangelist Conversation with Sam Newman on Microservices, Organizational Design, and Keeping a Calm Head in the Age of AI

My name’s Sam Newman. I’m an independent consultant and author, and I focus on system architecture more broadly — but really it comes down to how I help people get their ideas into production quickly and efficiently, increasingly looking at that through the lens of architecture. My background isn’t architecture first, though. It’s in path-to-production stuff, continuous delivery, sysadmin work for quite a while — what you might call a build monkey. So I came to architecture later on, and that grounding in how software actually ships still shapes how I think about all of it.

You’ve got your whole problem, and we break it down into these independent components. That’s what a microservice is — something that runs on a computer, it has functionality and it has data. The idea with a microservice architecture is that I can change that component and deploy it whenever I want without having to touch or change other parts of my system. So the goal is twofold: I can get the scale, I can use all the computers, but I can also get the speed of change — I can change one small part without having to change everything all at once. And that’s really the pitch for microservices as a style of architecture.

Software is a sociotechnical system — it’s people and technology working together, that’s how systems get built — so like any architecture, it’s both. What gets interesting about microservices is they make the connections between components quite explicit, and those connections often end up being the connections between different parts of your organization. In a big blobby system — what we’d call a monolith — those interconnections aren’t very visible, so it’s hard to understand how things relate. With microservices they become really explicit, and you start to see the connections between the teams that own different parts of the system. In fact, the majority of enterprise clients I work with aren’t adopting microservices for technology or scale reasons — most enterprises don’t have true scale problems. They’re doing it because they want a more autonomous, more loosely coupled organization. Microservices let them change their org structure.

It’s any and all of the above — there’s no obviously right answer. The framing is really important. Organizations that say “we want our teams to have a high degree of autonomy, how do we achieve that?” are more likely to achieve the outcome. Organizations that start purely through the lens of “we’re just going to change our architecture and magically get these other benefits” — that pathway is more problematic. The most success comes whenever you’re looking to make a change to your system and your starting point is: what are we trying to achieve with this change? Teams that lead with the autonomy goal are set up to achieve it. Teams that just say “let’s use microservices” haven’t really thought through why — they’ll probably end up with microservices, but whether anyone’s happier or shipping software quicker is up for grabs. You’ll definitely spend more money that way.

Microservices have gone from being a controversial concept to being considered the default approach over the last 15 years — my book came out in 2014, and the paper by James and Martin predated that. The unfortunate thing is that “default” status is a real problem. I refer to this style as an architecture of last resort: I try to solve problems in the simplest way I can, and microservices are never the simple answer. People assume they should be doing microservices because everybody else is. I’m old enough to remember “nobody ever got fired for buying IBM” — if everyone’s doing it and it fails, it can’t be your fault. Lots of companies that should not be doing this have gone that route and then blamed the architecture. I’m not seeing everyone go back to monoliths, but my work now is having to convince people it’s not a good idea for them.

I keep going back to that Jerry Weinberg line — it’s always a people problem. By definition, if they could do this themselves, or the situation were perfect, they wouldn’t need me there. The change I’m looking at is internal, so external signals aren’t that useful — a lot of them are just marketing anyway. So I have conversations with people: why are you doing this, what are you trying to achieve? You get a sense of it fairly quickly. Some clients have absolutely done their homework, and I’m there mostly to validate them — it’s good to have someone from outside every now and then. Other engagements, it becomes clear quite quickly that a decision has already been made and the people I’m working with are dealing with the aftermath. There’s no value in me looking at the code at that stage — it’s all about the people, because they’re the ones who are going to make the change happen.

It’s taken the oxygen out of the room. It’s very difficult for anybody to do anything large-scale in their architecture that isn’t somehow related to AI. In my experience developers are actually quite positive about using these tools to help write code — they’re more negative about being told they have to put AI in the product without anyone working out how. You can’t invest anywhere unless it’s AI-related, so a lot of people are smuggling necessary initiatives through by saying they’re AI. We also don’t fully understand the architectural impact yet — security models, data models, principle of least privilege become incredibly important once you look at agentic workflows. Organizations are still looking for valid business cases underpinning all of this. The benefit of being older is I can take the long view: it’s chaos right now, but it’s not going to change the world anywhere near as quickly as people think. My favorite clients are the ones keeping a calm head — one CTO told me his mantra is he wants his developers to be more human.

The smart people around AI understand that human in the loop is still really important. The way thoughtful people think about software development with AI is that you’re treating it like a very eager intern who has no idea what good looks like — you’ve gone from writing all the code yourself to effectively managing something that writes code for you, with an acceptance that it won’t always be correct. A lot of it comes down to the interaction design around our use of AI. Those early chat interfaces are in some ways the least interesting part, but the fact that they speak with such authority leads us to believe things we shouldn’t. The best counter-example I saw was the Financial Times at LeadDev Berlin — they built and continually tuned a model to decide what subscription package to offer, and could show measurably better retention. The human in the loop there is in the training and observing the outputs, not the moment of decision. That’s a genuinely good use case — versus just slapping a chatbot interface on something and exposing a horrendous experience to your customers.

In the current moment it probably makes more sense. Look at the macroeconomic picture: there’s no real financial business model around any of the big AI companies. Their investment case requires something like two trillion dollars a year by 2030 — five times the entire current software subscription space — and that money has to come from you and me. I haven’t got that money. They’re also massively subsidized, so the price we’re paying for these models is not real. How do you work out your ROI on a product when you don’t know what you’ll be charged in the future? So it already makes sense to use smaller models as part of a workflow — think LangChain or variations thereof — because you can keep the problem space smaller, mix and match models and vendors, and reduce your exposure to a vendor going bust or jacking up prices. Fundamentally it’s modularization. There’s nothing new in microservices; it’s all old ideas from 1970s module architecture. Break the big problem into smaller pieces you can manage, address, and even repatriate. For me it’s risk management that happens to follow good modular programming.

It’s about encouraging incremental change across the board. One of the biggest pitfalls I see is organizations imagining they’ll have a thousand microservices in the future, so they make this huge upfront investment in giant tech stacks and platforms — but right now you don’t have that. So start with one change. Make it do something, see what didn’t work, get it out into production, understand the problems you have. If you want to bring in new technology, bring in a small bit and try it out. It’s about getting used to those small cycles, which is much easier on public cloud. I come back to my early ThoughtWorks days doing agile enablement — you don’t give people all twelve principles of extreme programming on day one. There’s the cost-of-change J-curve: your productivity dips when you take on something new, and the more change you buy into at once, the bigger that trough becomes. Organizations tend to swing from extreme stasis to extreme change. Resilience engineering is really about letting a system continually change and adapt — systems that don’t adapt end up brittle. It’s not rocket science; it’s putting those simple ideas into practice that’s the tricky part.