{
    "byline": "Ian Miell\n   \n\n\n March 11, 2025\n 10 minutes Read",
    "charset": "UTF-8",
    "dir": null,
    "excerpt": "It happened again last week. I was at an architecture review meeting when a fellow architect eagerly started another debate about *microservices*. Within minutes, eyes glazed over and we were knee-deep in an absurd discussion about something that should have been a means to an end, but had morphed into the end itself. At that moment, I realized: I\u2019m done. I\u2019ve finally sworn off talking to architects about microservices. Why? Because these conversations usually go nowhere productive.\nI\u2019ve boiled my frustration down to three problems:\n\nNo one agrees on what \"microservice\" means.\nMicroservices conversations are abstract, with little tie-in to real business goals\nAdopting microservices without changing your organisation is pointless.\n\nProblem One: No One Knows What a Microservice Is\nThis is the most obvious problem. There\u2019s no formal definition of what a microservice is, so when people talk about them, they often end up talking at cross purposes.\nHere are some definitions out there:\n\nA service with a low number of lines of code:\n\n'They are very, very small. I mean 100 lines of code is probably a big service these days.' Fred George, Barcelona Ruby Conference\n\n\nThe \u2018two-pizza\u2019 team\n\nTechnically not a definition of microservices, but often used as a rule of thumb for the prescribed size of team required for it, and implies that a microservice requires its own team.\n\n\nRequires only one programmer to build and maintain:\n\n'If its more than one programmer to develop & design and maintain it, it\u2019s not a microservice' Fred George, GOTO 2016\n\n\nAutonomous, self-contained and unique processes\n\n'Each service is autonomous and self-contained and runs a unique process.'\u00a0\n\n\nA container/pod\n\n'Each microservice is packaged as a Docker container to enable deployment to a Kubernetes cluster for application orchestration.'\n\n\nA service with its own data store\n\nThis was my personal rule of thumb for a long time, and is also implied here\n\n\n\u2018Independently replaceable and upgradeable\u2019\n\nIan Cooper, after Yourdon, Edward; Constantine, Larry Structured Design, 1975\n\n\nA 'little computer' that operates on *a model of* the business concepts that are relevant to its operation.\u00a0 Daniel Terhorst-North\n\nWhile some of these overlap significantly with one another, the differences of emphasis combined with the loose way we discuss them, we end up with the \"blind men and the elephant\" scenario: everyone\u2019s correctly describing something slightly differently, so no-one is \u2018wrong\u2019, but we\u2019re certainly not aligned.\n(I discussed this confusion about what a microservice is here when talking about Amazon Video\u2019s so-called microservices to monolith move.)\nAfter enough of these debates, I\u2019ve found it simpler to ban the term \u201cmicroservices\u201d altogether. If a term causes this much confusion, maybe it\u2019s outlived its usefulness.\nInstead of arguing about what to call our architecture, we could be talking about concrete challenges, or specific trade-offs: how to deploy new features faster, how to reduce coupling, how to scale parts of the system. In other words, microservices (whatever you decide they are) are not an end in themselves, but a by-product of achieving some other goal.\nProblem One (b): The Lack of Discipline in Software Terminology\nThis isn\u2019t just a microservices issue: it\u2019s a broader problem in our industry. We throw around big words that sound impressive but mean wildly different things to different people. Consider these terms, and their histories:\n\nDevOps\n\nOriginally a rejection of the standard separation of development and operation teams, it became perfectly normal to talk about separate and centralised \u2018DevOps teams\u2019 centred around deployment tooling\n\n\nAgile\n\nOriginally a rejection of software methodologies and behaviours popularly associated with waterfall software development and an embracement of dynamic and context-specific methodologies and behaviours, the term became associated with heavily bureaucratised and ritualised behaviours\n\n\nSRE\n\nOriginally a discipline introduced by Google to bring software engineering practices to operations, emphasising reliability, automation, and service-level objectives (SLOs), it morphed into a rebranded operations function, usually without the cultural shift towards automation and shared ownership that it originally advocated\n\n\nObservability\n\nOriginally a concept from control theory applied to software systems, focusing on the ability to understand internal states from external outputs, it was embraced by modern infrastructure teams to move beyond traditional monitoring. However, as vendors pushed commercial observability solutions, it became increasingly synonymous with expensive dashboards, metrics overload, and tool sprawl, often obscuring rather than clarifying system health\n\n\n\nEach started with a well-defined intent, but over time they\u2019ve been stretched and contorted to mean whatever the speaker wants to advocate or criticise. With such sloppy definitions, is it any wonder our conversations go in circles?\n(As an aside, I\u2019d like to give props to GitOps. This term has been relatively stably used, thanks mainly to a clear original definition (now, sadly, gone from the internet along with the term\u2019s creators, Weaveworks) that was not easily perverted for commercial purposes.)\nProblem Two: Microservices Conversations Are Abstract and Unrelated from Business Goals\nClosely related to the first problem, discussions about microservices are often detached from any tangible business goals. If you ask \"What business problem are we actually solving?\" you\u2019re often met with vague responses like:\n\nMicroservices improve scalability. (Scalability of what? Where is the current bottleneck?)\nMicroservices make teams more agile. (How? Are deployments slow because of the architecture, or are they slow because of process constraints?)\nMicroservices allow independent deployments. (Is that actually a requirement for your team, or just a nice-to-have?)\nMicroservices reduce cognitive load. (For whom? Do they really, or are we just moving complexity around?)\n\nIf you listen closely, many of these conversations about microservices are not actually about architecture, but about wanting to work for a different company, where technology is cutting-edge and problems are theoretically interesting, rather than legacy-ridden and constrained by real-world trade-offs.\nThe sad reality is that many teams embarking on a microservices migration would be better off staying with a well-structured monolith until their scaling needs genuinely demand a different approach. Sam Newman, author of Building Microservices, frequently warns that most organizations should not start with microservices unless they have a compelling reason.\nAgain, it would be far better to stop talking about microservices. Start talking about reducing cycle time, improving reliability, and solving concrete business bottlenecks. If breaking up a system into smaller services is the best way to achieve those outcomes, fine, but angels on a pinhead discussions among architects about microservices are not the way to get there.\nProblem Three: Microservices Without Organizational Change Is Pointless\nAnother critical consequence of engineers discussing microservices in isolation from the business context is that they more often than not ignore the organisational changes required to make microservices work.\nMicroservices don\u2019t work in a vacuum. They require teams to be structured in a way that supports them. That means:\n\nCross-functional, autonomous teams that own services end-to-end. If teams still depend on centralised bottlenecks (e.g., a single DBA team), microservices won\u2019t deliver the promised benefits\nDecentralized decision-making to avoid coordination overhead. If releases still require lengthy approval processes, the independence of services is an illusion\nA mature DevOps culture with CI/CD, monitoring, and incident management practices that can handle the complexity of distributed systems\n\nIf your organisation isn\u2019t willing to make these changes, microservices will only make things worse. Adding technical complexity while keeping all the old organizational inefficiencies. In short, tech should follow business needs, not the other way around.\nMost people that discuss microservices either don\u2019t appreciate this, or don\u2019t appreciate how hard this is. Changing your organisational structure is far harder than changing your software architecture when your business is over a trivial size. This is why small startups can \u2018pivot\u2019, and change their software architecture so quickly: their organisation structure can be changed as soon as everyone agrees on the architectural changes.\nThe Next Time Someone Mentions Microservices\u2026\nI\u2019m well aware of the irony here: I\u2019ve talked about how I\u2019m not talking about microservices anymore. And with that, I'll shut up, and never speak of it again.",
    "lang": null,
    "length": 8874,
    "publishedTime": null,
    "siteName": null,
    "title": "Why I'm No Longer Talking to Architects About Microservices"
}