{ "archive_path": "archive/1742916984.406596", "base_url": "blog.container-solutions.com/why-im-no-longer-talking-to-architects-about-microservices", "basename": "why-im-no-longer-talking-to-architects-about-microservices", "bookmarked_date": "2025-03-25 15:36", "canonical": { "archive_org_path": "https://web.archive.org/web/blog.container-solutions.com/why-im-no-longer-talking-to-architects-about-microservices", "dom_path": "output.html", "favicon_path": "favicon.ico", "git_path": "git/", "google_favicon_path": "https://www.google.com/s2/favicons?domain=blog.container-solutions.com", "headers_path": "headers.json", "htmltotext_path": "htmltotext.txt", "index_path": "index.html", "media_path": "media/", "mercury_path": "mercury/content.html", "pdf_path": "output.pdf", "readability_path": "readability/content.html", "screenshot_path": "screenshot.png", "singlefile_path": "singlefile.html", "warc_path": "warc/", "wget_path": null }, "domain": "blog.container-solutions.com", "downloaded_at": "2025-03-25T15:36:30.732879+00:00", "downloaded_datestr": "2025-03-25 15:36", "extension": "", "hash": "MS39BY80DV88NWQZBZJ4", "history": { "archive_org": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--head", "--max-time", "60", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://web.archive.org/save/https://blog.container-solutions.com/why-im-no-longer-talking-to-architects-about-microservices" ], "cmd_version": "8.10.1", "end_ts": "2025-03-25T15:38:10.144830+00:00", "index_texts": null, "output": "https://web.archive.org/web/20250325153748/https://blog.container-solutions.com/why-im-no-longer-talking-to-architects-about-microservices", "pwd": "/data/archive/1742916984.406596", "schema": "ArchiveResult", "start_ts": "2025-03-25T15:37:44.197896+00:00", "status": "succeeded" } ], "dom": [ { "cmd": [ "/usr/bin/chromium-browser", "--proxy-server=socks5://tor-socks-proxy:9150", "--disable-features=DarkMode", "--run-all-compositor-stages-before-draw", "--hide-scrollbars", "--autoplay-policy=no-user-gesture-required", "--no-first-run", "--use-fake-ui-for-media-stream", "--use-fake-device-for-media-stream", "--simulate-outdated-no-au='Tue, 31 Dec 2099 23:59:59 GMT'", "--headless=new", "--no-sandbox", "--no-zygote", "--disable-dev-shm-usage", "--disable-software-rasterizer", "--disable-sync", "--window-size=1440,2000", "--user-agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "--user-data-dir=/data/personas/Default/chrome_profile", "--profile-directory=Default", "--dump-dom", "https://blog.container-solutions.com/why-im-no-longer-talking-to-architects-about-microservices" ], "cmd_version": "131.0.6778", "end_ts": "2025-03-25T15:37:01.336044+00:00", "index_texts": null, "output": "output.html", "pwd": "/data/archive/1742916984.406596", "schema": "ArchiveResult", "start_ts": "2025-03-25T15:36:42.135101+00:00", "status": "succeeded" } ], "favicon": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--max-time", "60", "--output", "favicon.ico", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://www.google.com/s2/favicons?domain=blog.container-solutions.com" ], "cmd_version": "8.10.1", "end_ts": "2025-03-25T15:36:33.883400+00:00", "index_texts": null, "output": "favicon.ico", "pwd": "/data/archive/1742916984.406596", "schema": "ArchiveResult", "start_ts": "2025-03-25T15:36:31.128707+00:00", "status": "succeeded" } ], "git": [], "headers": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--head", "--max-time", "60", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://blog.container-solutions.com/why-im-no-longer-talking-to-architects-about-microservices" ], "cmd_version": "8.10.1", "end_ts": "2025-03-25T15:36:34.078935+00:00", "index_texts": null, "output": "headers.json", "pwd": "/data/archive/1742916984.406596", "schema": "ArchiveResult", "start_ts": "2025-03-25T15:36:33.926248+00:00", "status": "succeeded" } ], "htmltotext": [ { "cmd": [ "(internal) archivebox.extractors.htmltotext", "./{singlefile,dom}.html" ], "cmd_version": "0.8.5rc51", "end_ts": "2025-03-25T15:37:36.174341+00:00", "index_texts": [ "Why I'm No Longer Talking to Architects About Microservices (https://blog.container-solutions.com/hubfs/favicon.ico) (https://blog.container-solutions.com/hs-fs/hub/2252258/hub_generated/module_assets/9848497348/1583840075583/module_9848497348_image--logo.min.css) (https://blog.container-solutions.com/hs-fs/hub/2252258/hub_generated/template_assets/29086683658/1689240292920/CS_Theme/CS--Stylesheets/CS--megamenu.css) (https://blog.container-solutions.com/hs-fs/hub/2252258/hub_generated/module_assets/29104102065/1621606050404/module_29104102065_CS--Megamenu__helper.min.css) (https://blog.container-solutions.com/hs-fs/hub/2252258/hub_generated/module_assets/29544378357/1589895084042/module_29544378357_Blog2_Normal_Sidebar_Topic_Post.min.css) (/hs/hsstatic/AsyncSupport/static-1.122/sass/comments_listing_asset.css) (https://blog.container-solutions.com/hs-fs/hub/2252258/hub_generated/module_assets/29544595978/1656510507698/module_29544595978_Footer_Social_Icon_CM_copy.min.css) (https://blog.container-solutions.com/why-im-no-longer-talking-to-architects-about-microservices?hs_amp=true) (https://blog.container-solutions.com/why-im-no-longer-talking-to-architects-about-microservices) (https://blog.container-solutions.com/hubfs/Blog-Assets/prismCS.css) (https://blog.container-solutions.com/rss.xml) (//7052064.fs1.hubspotusercontent-na1.net/hubfs/7052064/hub_generated/template_assets/DEFAULT_ASSET/1742393150721/template_layout.min.css) (https://blog.container-solutions.com/hs-fs/hub/2252258/hub_generated/template_assets/29544378321/1689350603969/Marketplace/wowdesign/360_template_pack_by_wowdesign/Coded_Files/360_Design_Style.css) (https://use.fontawesome.com/releases/v5.8.2/css/all.css) Our website uses cookies to distinguish you from other users of our website. This helps us to provide you with a good experience when you browse our website and also allows us to improve our site. You can read more in our (https://container-solutions.com/privacy-policy) Privacy Policy . Settings Accept Decline Check out our (https://www.container-solutions.com/services) Cloud Native Services and book a call with one of our experts today! (http://container-solutions.com) (Container Solutions) (Container Solutions) (https://www.container-solutions.com) Home (https://www.container-solutions.com/services) Services (https://www.container-solutions.com/case-studies) Case Studies (https://www.container-solutions.com/events) Events Content (https://blog.container-solutions.com) Blogs (https://www.container-solutions.com/wtf-is-cloud-native/collections) WTF is Cloud Native Collections (https://www.container-solutions.com/careers) Careers (https://www.container-solutions.com/about-us) About us (https://www.container-solutions.com/talk-to-us) Talk to us (https://www.container-solutions.com/oreilly-cloud-native-transformation-ebook-chat) Talk to our ChatBot share: (https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fblog.container-solutions.com%2Fwhy-im-no-longer-talking-to-architects-about-microservices) (https://www.twitter.com/share?url=https%3A%2F%2Fblog.container-solutions.com%2Fwhy-im-no-longer-talking-to-architects-about-microservices) (http://www.linkedin.com/shareArticle?mini=true&url=https://blog.container-solutions.com/why-im-no-longer-talking-to-architects-about-microservices) (https://blog.container-solutions.com/why-im-no-longer-talking-to-architects-about-microservices) () () (https://blog.container-solutions.com/tag/cloud-native) Cloud native , (https://blog.container-solutions.com/tag/microservices) Microservices , (https://blog.container-solutions.com/tag/architecture) Architecture Why I'm No Longer Talking to Architects About Microservices (https://blog.container-solutions.com/author/ian-miell) Ian Miell (Ian Miell) March 11, 2025 10 minutes Read 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. I\u2019ve boiled my frustration down to three problems: No one agrees on what \"microservice\" means. Microservices conversations are abstract, with little tie-in to real business goals Adopting microservices without changing your organisation is pointless. Problem One: No One Knows What a Microservice Is This 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. Here are some definitions out there: A service with a low number of lines of code: 'They are very, very small. I mean 100 lines of code is probably a big service these days.' Fred George, Barcelona Ruby Conference The(https://aws.amazon.com/executive-insights/content/amazon-two-pizza-team/) \u2018two-pizza\u2019 team Technically 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. Requires only one programmer to build and maintain: 'If its more than one programmer to develop & design and maintain it, it\u2019s not a microservice' Fred George, GOTO 2016 (https://www.paloaltonetworks.co.uk/cyberpedia/what-are-microservices#:~:text=Each%20service%20is%20autonomous%20and%20self%2Dcontained%20and%20runs%20a%20unique%20process) Autonomous, self-contained and unique processes 'Each service is autonomous and self-contained and runs a unique process.' A container/pod (https://ThinkMicroservices.com) 'Each microservice is packaged as a Docker container to enable deployment to a Kubernetes cluster for application orchestration.' A service with its own data store This was my personal rule of thumb for a long time, and is also implied (https://www.paloaltonetworks.co.uk/cyberpedia/what-are-microservices#:~:text=began%20adopting%20this-,architecture,-) here (https://www.paloaltonetworks.co.uk/cyberpedia/what-are-microservices#:~:text=began%20adopting%20this-,architecture,-) \u2018Independently replaceable and upgradeable\u2019 (https://www.youtube.com/watch?v=j2AQ9eTZ3-0) Ian Cooper , after Yourdon, Edward; Constantine, Larry Structured Design , 1975 (https://www.linkedin.com/posts/tastapod_the-idea-of-microservices-having-or-wanting-activity-7304921317139464192-NOLu/) A 'little computer' that operates on *a model of* the business concepts that are relevant to its operation. Daniel Terhorst-North While 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 (https://www.peacecorps.gov/educators-and-students/educators/resources/blind-men-and-elephant/story-blind-men-and-elephant/) \"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. (I discussed this confusion about what a microservice is (/reflections-on-amazon-prime-videos-monolith-move#:~:text=isn%E2%80%99t%20a%20monolith%E2%80%99.-,The%20Semantics,-At%20this%20point) here when talking about Amazon Video\u2019s so-called microservices to monolith move.) After 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. Instead 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 . Problem One (b): The Lack of Discipline in Software Terminology This 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: DevOps Originally 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 Agile Originally 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 SRE Originally 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 Observability Originally 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 Each 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? (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.) Problem Two: Microservices Conversations Are Abstract and Unrelated from Business Goals Closely 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: Microservices improve scalability. (Scalability of what? Where is the current bottleneck?) Microservices make teams more agile. (How? Are deployments slow because of the architecture, or are they slow because of process constraints?) Microservices allow independent deployments. (Is that actually a requirement for your team, or just a nice-to-have?) Microservices reduce cognitive load. (For whom? Do they really, or are we just moving complexity around?) If 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. The 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. Again, 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. Problem Three: Microservices Without Organizational Change Is Pointless Another 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. Microservices don\u2019t work in a vacuum. They require teams to be structured in a way that supports them. That means: Cross-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 Decentralized decision-making to avoid coordination overhead. If releases still require lengthy approval processes, the independence of services is an illusion A mature DevOps culture with CI/CD, monitoring, and incident management practices that can handle the complexity of distributed systems If 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. Most 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. The Next Time Someone Mentions Microservices\u2026 I\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. (/exploring-oscal-using-neo4j) Exploring OSCAL Using Neo4J (/exploring-oscal-using-neo4j) (prev-arrow) Previous article Comments Leave your Comment (Enter your Your name) Your name () () (Enter your Your email address) Your email address () () (Enter your Your website (optional)) Your website (optional) () () (Enter your Your comment) Your comment () Container Solutions needs the contact information you provide to us to contact you about our products and services. You may unsubscribe from these communications at any time. For information on how to unsubscribe, as well as our privacy practices and commitment to protecting your privacy, please review our (https://container-solutions.com/privacy-policy/) Privacy Policy . (Post your comment) ({\"embedAtTimestamp\":\"1742917013607\",\"formDefinitionUpdatedAt\":\"1633072582200\",\"legalConsentOptions\":\"{\\\"legitimateInterestSubscriptionTypes\\\":[2763645],\\\"communicationConsentCheckboxes\\\":[{\\\"communicationTypeId\\\":2763645,\\\"label\\\":\\\"I agree to receive other communications from Container Solutions.\\\",\\\"required\\\":false}],\\\"legitimateInterestLegalBasis\\\":\\\"LEGITIMATE_INTEREST_PQL\\\",\\\"communicationConsentText\\\":\\\"Container Solutions is committed to protecting and respecting your privacy, and we\u2019ll only use your personal information to administer your account and to provide the products and services you requested from us. From time to time, we would like to contact you about our products and services, as well as other content that may be of interest to you. If you consent to us contacting you for this purpose, please tick below to say how you would like us to contact you:\\\",\\\"processingConsentType\\\":\\\"IMPLICIT\\\",\\\"processingConsentText\\\":\\\"In order to provide you the content requested, we need to store and process your personal data. If you consent to us storing your personal data for this purpose, please tick the checkbox below.\\\",\\\"processingConsentCheckboxLabel\\\":\\\"I agree to allow Container Solutions to store and process my personal data.\\\",\\\"privacyPolicyText\\\":\\\"

Container Solutions needs the contact information you provide to us to contact you about our products and services. You may unsubscribe from these communications at any time. For information on how to unsubscribe, as well as our privacy practices and commitment to protecting your privacy, please review our Privacy Policy.

\\\",\\\"isLegitimateInterest\\\":true}\",\"isLegacyThemeAllowed\":\"true\",\"userAgent\":\"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)\",\"pageTitle\":\"Why I'm No Longer Talking to Architects About Microservices\",\"pageUrl\":\"https://blog.container-solutions.com/why-im-no-longer-talking-to-architects-about-microservices\",\"pageId\":\"187168043885\",\"isHubSpotCmsGeneratedPage\":true,\"canonicalUrl\":\"https://blog.container-solutions.com/why-im-no-longer-talking-to-architects-about-microservices\",\"contentType\":\"blog-post\",\"hutk\":\"06337e271bb25002486ec93b19f24209\",\"__hsfp\":2697388967,\"__hssc\":\"137489263.1.1742917019299\",\"__hstc\":\"137489263.06337e271bb25002486ec93b19f24209.1742917019299.1742917019299.1742917019299.1\",\"formTarget\":\"#hs_form_target_e5ba3739-20e2-48cd-8272-c926646d555c\",\"formInstanceId\":\"1248\",\"pageName\":\"Why I'm No Longer Talking to Architects About Microservices\",\"rumScriptExecuteTime\":5716.600000023842,\"rumTotalRequestTime\":6421.600000023842,\"rumTotalRenderTime\":6740.5,\"rumServiceResponseTime\":705,\"rumFormRenderTime\":318.89999997615814,\"connectionType\":\"3g\",\"firstContentfulPaint\":0,\"largestContentfulPaint\":0,\"locale\":\"en\",\"timestamp\":1742917019365,\"originalEmbedContext\":{\"portalId\":\"2252258\",\"formId\":\"e5ba3739-20e2-48cd-8272-c926646d555c\",\"region\":\"na1\",\"target\":\"#hs_form_target_e5ba3739-20e2-48cd-8272-c926646d555c\",\"isBuilder\":false,\"isTestPage\":false,\"isPreview\":false,\"formInstanceId\":\"1248\",\"formsBaseUrl\":\"/_hcms/forms\",\"css\":\"\",\"submitButtonClass\":\"hs-button primary\",\"isMobileResponsive\":true,\"pageName\":\"Why I'm No Longer Talking to Architects About Microservices\",\"pageId\":\"187168043885\",\"contentType\":\"blog-post\",\"isCMSModuleEmbed\":true,\"type\":\"BLOG_COMMENT\"},\"correlationId\":\"0b1082e2-b02d-40a0-a5d6-0eea3cb58958\",\"renderedFieldsIds\":[\"firstname\",\"email\",\"website\",\"comment\"],\"captchaStatus\":\"NOT_APPLICABLE\",\"emailResubscribeStatus\":\"NOT_APPLICABLE\",\"isInsideCrossOriginFrame\":false,\"source\":\"forms-embed-1.8109\",\"sourceName\":\"forms-embed\",\"sourceVersion\":\"1.8109\",\"sourceVersionMajor\":\"1\",\"sourceVersionMinor\":\"8109\",\"allPageIds\":{\"embedContextPageId\":\"187168043885\",\"analyticsPageId\":\"187168043885\",\"contentPageId\":187168043885,\"contentAnalyticsPageId\":\"187168043885\"},\"_debug_embedLogLines\":[{\"clientTimestamp\":1742917013883,\"level\":\"INFO\",\"message\":\"Retrieved customer callbacks used on embed context: [\\\"getExtraMetaDataBeforeSubmit\\\"]\"},{\"clientTimestamp\":1742917013895,\"level\":\"INFO\",\"message\":\"Retrieved pageContext values which may be overriden by the embed context: {\\\"pageTitle\\\":\\\"Why I'm No Longer Talking to Architects About Microservices\\\",\\\"pageUrl\\\":\\\"https://blog.container-solutions.com/why-im-no-longer-talking-to-architects-about-microservices\\\",\\\"userAgent\\\":\\\"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)\\\",\\\"pageId\\\":\\\"187168043885\\\",\\\"contentAnalyticsPageId\\\":\\\"187168043885\\\",\\\"contentPageId\\\":187168043885,\\\"isHubSpotCmsGeneratedPage\\\":true}\"},{\"clientTimestamp\":1742917013911,\"level\":\"INFO\",\"message\":\"Retrieved countryCode property from normalized embed definition response: \\\"NL\\\"\"},{\"clientTimestamp\":1742917019322,\"level\":\"INFO\",\"message\":\"Retrieved analytics values from API response which may be overriden by the embed context: {\\\"hutk\\\":\\\"06337e271bb25002486ec93b19f24209\\\",\\\"canonicalUrl\\\":\\\"https://blog.container-solutions.com/why-im-no-longer-talking-to-architects-about-microservices\\\",\\\"contentType\\\":\\\"blog-post\\\",\\\"pageId\\\":\\\"187168043885\\\"}\"}]}) (cs-logo-white) (cs-logo-white) (https://www.container-solutions.com) Home (https://www.container-solutions.com/events) Events (https://www.container-solutions.com/services) Services (https://www.container-solutions.com/latest-news) Latest News (https://blog.container-solutions.com) Blog (https://www.container-solutions.com/careers) Careers (https://www.container-solutions.com/talk-to-us) Talk to us (https://www.container-solutions.com/wtf-is-cloud-native) WTF is Cloud Native (https://www.container-solutions.com/website-terms-of-use) Website terms of use (https://www.container-solutions.com/privacy-policy) Privacy policy (https://www.container-solutions.com/sexual-harassment-policy) Sexual Harassment Policy (https://www.container-solutions.com/data-privacy-notice-for-job-applicants) Data Privacy for Job Seekers (https://www.container-solutions.com/cookie-notice) Cookie Notice (https://www.container-solutions.com/events-code-of-conduct) Events Code of Conduct Talk to sales (mailto:info@container-Solutions.com) info@container-solutions.com (https://use.fontawesome.com/releases/v5.5.0/css/all.css) Stay In Touch (https://www.linkedin.com/company/container-solutions/) (https://twitter.com/containersoluti) \u00a9 2024 Container Solutions (Twitter settings iframe) (archetype) (Twitter analytics iframe) " ], "output": "htmltotext.txt", "pwd": "/data/archive/1742916984.406596", "schema": "ArchiveResult", "start_ts": "2025-03-25T15:37:36.102168+00:00", "status": "succeeded" } ], "media": [ { "cmd": [ "/usr/local/bin/yt-dlp", "--restrict-filenames", "--trim-filenames", "128", "--write-description", "--write-info-json", "--write-annotations", "--write-thumbnail", "--no-call-home", "--write-sub", "--write-auto-subs", "--convert-subs=srt", "--yes-playlist", "--continue", "--no-abort-on-error", "--ignore-errors", "--geo-bypass", "--add-metadata", "--format=(bv*+ba/b)[filesize<=750m][filesize_approx<=?750m]/(bv*+ba/b)", "--skip-download", "--cache-dir=/data/yt-dlp-cache/", "--cookies=/data/yt-dlp-cache/cookies.txt", "--proxy=socks5://tor-socks-proxy:9150", "--no-playlist", "https://blog.container-solutions.com/why-im-no-longer-talking-to-architects-about-microservices" ], "cmd_version": "2024.10.7", "end_ts": "2025-03-25T15:37:44.131305+00:00", "index_texts": [], "output": "media/", "pwd": "/data/archive/1742916984.406596", "schema": "ArchiveResult", "start_ts": "2025-03-25T15:37:39.159271+00:00", "status": "succeeded" } ], "mercury": [ { "cmd": [ "/home/archivebox/.npm/bin/postlight-parser", "https://blog.container-solutions.com/why-im-no-longer-talking-to-architects-about-microservices" ], "cmd_version": "2.2.3", "end_ts": "2025-03-25T15:37:36.043107+00:00", "index_texts": null, "output": "mercury/", "pwd": "/data/archive/1742916984.406596", "schema": "ArchiveResult", "start_ts": "2025-03-25T15:37:30.391283+00:00", "status": "succeeded" } ], "pdf": [], "readability": [ { "cmd": [ "/home/archivebox/.npm/bin/readability-extractor", "/tmp/tmpcw7zvy5k", "https://blog.container-solutions.com/why-im-no-longer-talking-to-architects-about-microservices" ], "cmd_version": "0.0.11", "end_ts": "2025-03-25T15:37:12.468085+00:00", "index_texts": [ "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." ], "output": "readability/", "pwd": "/data/archive/1742916984.406596", "schema": "ArchiveResult", "start_ts": "2025-03-25T15:37:04.881058+00:00", "status": "succeeded" } ], "screenshot": [], "singlefile": [], "title": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--max-time", "60", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://blog.container-solutions.com/why-im-no-longer-talking-to-architects-about-microservices" ], "cmd_version": "8.10.1", "end_ts": "2025-03-25T15:37:02.011280+00:00", "index_texts": null, "output": "Why I'm No Longer Talking to Architects About Microservices", "pwd": "/data/archive/1742916984.406596", "schema": "ArchiveResult", "start_ts": "2025-03-25T15:37:01.763561+00:00", "status": "succeeded" } ], "wget": [] }, "icons": null, "is_archived": true, "is_static": false, "latest": { "archive_org": "https://web.archive.org/web/20250325153748/https://blog.container-solutions.com/why-im-no-longer-talking-to-architects-about-microservices", "dom": "output.html", "favicon": "favicon.ico", "git": null, "media": "media/", "pdf": null, "screenshot": null, "singlefile": null, "title": "Why I'm No Longer Talking to Architects About Microservices", "warc": null, "wget": null }, "link_dir": "/data/archive/1742916984.406596", "newest_archive_date": "2025-03-25T15:37:44.197896+00:00", "num_failures": 0, "num_outputs": 9, "oldest_archive_date": "2025-03-25T15:36:31.128707+00:00", "path": "/why-im-no-longer-talking-to-architects-about-microservices", "schema": "Link", "scheme": "https", "snapshot_abid": "snp_01JQ6Z57MQ3E302851011KV6JH", "snapshot_id": "4fa13a23-8b8a-47d9-9438-ddc0c33d9a51", "sources": [ "/data/sources/1742916983-import.txt" ], "tags": null, "tags_str": "", "timestamp": "1742916984.406596", "title": "Why I'm No Longer Talking to Architects About Microservices", "url": "https://blog.container-solutions.com/why-im-no-longer-talking-to-architects-about-microservices" }