--- title: Boring Stacks Quietly Won July. Fashion Stacks Quietly... description: A cultural commentary on the July 2025 Hacker News trend of praising 'boring' stacks like Rails and Postgres over fashionable microservice architectures. The... canonical: https://daily.dev/posts/boring-stacks-quietly-won-july-fashion-stacks-quietly-paid-for-on-call-s1bshrjwg twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Boring Stacks Quietly Won July. Fashion Stacks Quietly Paid for On-Call | daily.dev og:description: A cultural commentary on the July 2025 Hacker News trend of praising 'boring' stacks like Rails and Postgres over fashionable microservice architectures. The... og:url: https://daily.dev/posts/boring-stacks-quietly-won-july-fashion-stacks-quietly-paid-for-on-call-s1bshrjwg og:image: https://api.daily.dev/og/posts/S1BsHRJwg.png og:image:alt: Boring Stacks Quietly Won July. Fashion Stacks Quietly Paid for On-Call og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Boring Stacks Quietly Won July. Fashion Stacks Quietly Paid for On-Call **[Medium](https://daily.dev/sources/medium_js)** · 8 min read · 27 upvotes · 1 comments ## Summary A cultural commentary on the July 2025 Hacker News trend of praising 'boring' stacks like Rails and Postgres over fashionable microservice architectures. The piece argues that architectural choices should be evaluated by operational cost — on-call burden, incident complexity, and cognitive load — rather than resume appeal or novelty. It contrasts boring stacks (fewer failure domains, wider hiring pool, predictable incidents) with fashion stacks (distributed complexity, observability gaps, concentrated knowledge). Includes a practical decision framework for choosing between the two, four operational metrics to settle stack debates, and an honest acknowledgment that resume incentives drive over-engineering. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What are the hidden operational costs of choosing microservices over a monolith? Microservices tend to increase on-call burden through deploy coupling disguised as independence, observability gaps at service boundaries, and higher cognitive load during incidents since responders must trace failures across repos, queues, and sidecars rather than checking a single app, database, and cache. These costs often outweigh the architectural flexibility gained unless a genuine isolation, scale, or compliance need justifies them. _Weigh architecture tradeoffs like this against real incident data developers share on daily.dev._ ### How can a team decide objectively whether to choose a monolith or microservices architecture? Replace stack-preference arguments with four measurable metrics tracked over ninety days: mean time to understand a Sev-2 incident, number of people who can drive a rollback unaided, percentage of incidents crossing more than two services, and hours per week spent on non-product glue work. A more distributed architecture is only justified if it improves these numbers rather than worsening them. _Track architecture decisions against measurable outcomes discussed by engineers on daily.dev._ ## Community discussion Top comments from developers on daily.dev. **@nark3d** · 2 upvotes > Most stack debates I've sat through were really about taste. Nobody in them could say what the extra moving parts actually cost to run, so putting it in on-call hours and incident counts at least gives you something to argue about. On the resume point I think it goes both ways. Plenty of people pick the boring option because they got burned once, and then defend it on principle rather than on what it costs. Either way it's the same question, what does it cost to run. https://prickles.org/tenet/simplicity/F4 ## Similar posts on daily.dev - [My 2026 Tech Stack is Boring as Hell \(And That is the Point\)](https://daily.dev/posts/my-2026-tech-stack-is-boring-as-hell-and-that-is-the-point--zw58f0sjv) · DEV · 175 upvotes · 10 comments - [QCon London 2026: The Hidden Power of Boring Problems](https://daily.dev/posts/qcon-london-2026-the-hidden-power-of-boring-problems-u7owskcvp) · InfoQ · 0 upvotes · 0 comments - [Have less stuff](https://daily.dev/posts/have-less-stuff-llfkpnl7e) · RUBYLAND · 1 upvotes · 0 comments - [Are We Overengineering Modern Infrastructure?](https://daily.dev/posts/are-we-overengineering-modern-infrastructure--tzvs357re) · Nordic APIs · 2 upvotes · 0 comments --- Tags: [#devops](https://daily.dev/tags/devops), [#architecture](https://daily.dev/tags/architecture), [#rails](https://daily.dev/tags/rails), [#microservices](https://daily.dev/tags/microservices), [#monolith](https://daily.dev/tags/monolith) [View this post on daily.dev](https://daily.dev/posts/boring-stacks-quietly-won-july-fashion-stacks-quietly-paid-for-on-call-s1bshrjwg) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Boring Stacks Quietly Won July. Fashion Stacks Quietly Paid for On-Call","url":"https://daily.dev/posts/boring-stacks-quietly-won-july-fashion-stacks-quietly-paid-for-on-call-s1bshrjwg","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/boring-stacks-quietly-won-july-fashion-stacks-quietly-paid-for-on-call-s1bshrjwg"},"datePublished":"2026-07-15T19:31:55.265Z","dateModified":"2026-09-14T07:12:32.636Z","description":"A cultural commentary on the July 2025 Hacker News trend of praising 'boring' stacks like Rails and Postgres over fashionable microservice architectures. The...","image":"https://media.daily.dev/image/upload/s--0_ODbtD2--/f_auto/v1722860399/public/Placeholder%2008","thumbnailUrl":"https://media.daily.dev/image/upload/s--0_ODbtD2--/f_auto/v1722860399/public/Placeholder%2008","isAccessibleForFree":true,"articleSection":"Medium","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Medium","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/medium","url":"https://daily.dev/sources/medium_js"},"commentCount":1,"discussionUrl":"https://daily.dev/posts/boring-stacks-quietly-won-july-fashion-stacks-quietly-paid-for-on-call-s1bshrjwg","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":27},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":1}],"keywords":"devops,architecture,rails,microservices,monolith","timeRequired":"PT8M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Medium","item":"https://daily.dev/sources/medium_js"},{"@type":"ListItem","position":3,"name":"Boring Stacks Quietly Won July. Fashion Stacks Quietly Paid for On-Call"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/boring-stacks-quietly-won-july-fashion-stacks-quietly-paid-for-on-call-s1bshrjwg","comment":[{"@type":"Comment","text":"Most stack debates I’ve sat through were really about taste. Nobody in them could say what the extra moving parts actually cost to run, so putting it in on-call hours and incident counts at least gives you something to argue about. On the resume point I think it goes both ways. Plenty of people pick the boring option because they got burned once, and then defend it on principle rather than on what it costs. Either way it’s the same question, what does it cost to run. https://prickles.org/tenet/simplicity/F4","datePublished":"2026-07-18T12:15:29.428Z","url":"https://daily.dev/posts/S1BsHRJwg#c-YDIXZvpgG","author":{"@type":"Person","name":"Adam","url":"https://daily.dev/nark3d","image":"https://avatars.githubusercontent.com/u/2162621?v=4"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/boring-stacks-quietly-won-july-fashion-stacks-quietly-paid-for-on-call-s1bshrjwg#faq","mainEntity":[{"@type":"Question","name":"What are the hidden operational costs of choosing microservices over a monolith?","acceptedAnswer":{"@type":"Answer","text":"Microservices tend to increase on-call burden through deploy coupling disguised as independence, observability gaps at service boundaries, and higher cognitive load during incidents since responders must trace failures across repos, queues, and sidecars rather than checking a single app, database, and cache. These costs often outweigh the architectural flexibility gained unless a genuine isolation, scale, or compliance need justifies them. Weigh architecture tradeoffs like this against real incident data developers share on daily.dev."}},{"@type":"Question","name":"How can a team decide objectively whether to choose a monolith or microservices architecture?","acceptedAnswer":{"@type":"Answer","text":"Replace stack-preference arguments with four measurable metrics tracked over ninety days: mean time to understand a Sev-2 incident, number of people who can drive a rollback unaided, percentage of incidents crossing more than two services, and hours per week spent on non-product glue work. A more distributed architecture is only justified if it improves these numbers rather than worsening them. Track architecture decisions against measurable outcomes discussed by engineers on daily.dev."}}]} ```