7 ms·

> Microservices only pay off when you have real scaling bottlenecks, large teams, or independently evolving domains. Before that? You’re paying the price withou

• candiddevmike 1y ago
  Some resume driven developers will choose microservices for startups as a way to LARP a future megacorp job. Startup may fail, but they at least got some distributed system experience. It takes extremely savvy technical leadership to prevent this.
  • MDGeist 1y ago
    I've also seen the top down version where senior leadership like a CIO/CTO wants to put a huge "modernization" project on their resume and they don't care if it is impossible to maintain or falls over after they move on.
    • ang_cire 1y ago
      "Cloud Migration"
      • gpi 1y ago
        "Digital transformation"
    • jamesfinlayson 1y ago
      Oh yeah, I've come to realise that the people at the top are just as bad. I was at a place where "consultants decided" that the company's two backbone systems should be replaced with off-the-shelf solutions. Very obviously a resume-padding project from the CIO who was in their first large company job, but which would have almost certainly crippled the company if it went ahead. Thankfully the business and finance people at the company decided it would be an expensive and stupid idea it was shut down.
  • devin 1y ago
    In my experience, it seems the majority of folks know the pitfalls of microservices, and have since like... 2016? Maybe I'm just blessed to have been at places with good engineering, technical leadership, and places that took my advice seriously, but I feel like the majority of folks I've interacted with all have experienced some horror story with microservices that they don't want to repeat.
    • Espressosaurus 1y ago
      I feel like it's only in the last 5 years in the tech publicity sphere that I've seen pushback against microservices, only it feels like only the last year or two where I see it to the exclusion of influencers pushing microservices. Things are different in the embedded space so I don't have personal experience with any of it.
      • speed_spread 1y ago
        Pushback was always there from the start. The first edition of O'Reilly's "Building microservices" recommended _against_ microservices, unless you absolutely tried scaling your monolith and team beforehand. Any organization stuck in microservice hell fully deserves the punishment.
    • westurner 1y ago
      Does [self-hosted, multi-tenant] serverless achieve similar separation of concerns in comparison to microservices? Should the URLs contain a version; like /api/v1/ ? FWIU OpenAPI API schema enable e.g. MCP service discovery, but not multi-API workflows or orchestrations. (Edit: "The Arazzo Specification - A Tapestry for Deterministic API Workflows" by OpenAPI; src: https://github.com/OAI/Arazzo-Specification https://github.com/OAI/Arazzo-Specification .. spec: https://spec.openapis.org/arazzo/latest.html https://spec.openapis.org/arazzo/latest.html (TIL by using this comment as a prompt))
    • jamesfinlayson 1y ago
      > In my experience, it seems the majority of folks know the pitfalls of microservices, and have since like... 2016? Majority maybe, but not everyone. I was at a place in 2018 where a guy turned up declaring that microservices would solve all of the company's performance issues (he'd heard that AWS S3 was made up of over 500 microservices so we must do the same, but he obviously had no idea about the depth of features in S3 so hit take was more is better). So we got like 30 microservices in the space of year which gave the company 10x complexity, complicated and fragile local development and... dubious wins like faster email sending, but no improvements to true bottle-necks of the system.
  • alaithea 1y ago
    And when it's your technical leadership leveraging buzzword-driven development to rise to the top, you're screwed.
    • wpollock 1y ago
      So true. It was in March that I saw on HN an advertisement for a vibe coder with 3 years experience. I believe the term "vibe coding" was invented a month before! Buzzword hiring is as bad as resume driven development.
  • hnthrow90348765 1y ago
    Hiring will need to change to stop resume-driven development (can't eliminate it completely though), because you're likely to only get monolith roles if you only work on monoliths. Only being able to speak about microservices puts you in the "talk the talk, not walk the walk" category. It would also nice to have less fear-driven career advice like "your skills go out of date" which drives people to try adopting the latest things.
    • Mountain_Skies 1y ago
      Keyword driven and filtered application processes also heavily incentivize adding into projects whatever is being posted on jobs sites. If microservices are part of a company's standard template for developer postings, people who want to work at that company will find a way to get it on their resume.
  • bityard 1y ago
    It could also just be plain old overengineering. Like using Django and leaning on all of the magic contained within it just to implement a simple API that could instead be a very small Flask or FastAPI app.
    • about3fitty 1y ago
      Unforeseen scope creep is the reason to utilise Django over Flask, I feel. Also, you can pick and choose what to use in Django similarly to Flask - it just has a higher initial learning curve. Once you get to sufficient levels of complicated, leaning on established, documented, community supported design patterns and abstractions helps vs. sorting out your imports, making bespoke design choices, and doing a bunch of non-core value producing work.
      • 0cf8612b2e1e 1y ago
        I will forever beat the Django over Flask drum. Nothing ever stays simple. Maybe today it is one single view function, but tomorrow someone is going to want to add authentication, emails, whatever. Django might have features you do not need, but it would be an unusual situation where Django is holding you back vs Flask.
• singron 1y ago
  > You'll have a monolith, it might break out into frontend, backend and a separate service for async background jobs And when you break these out, you don't actually have to split your code at all. You can deploy your normal monolith with a flag telling it what role to play. The background worker can still run a webserver since it's useful for healthchecks and metrics and the loadbalancer will decide what "roles" get real traffic.
  • elevatedastalt 1y ago
    If you are building the same binary for all microservices you lose the dependency-reduction benefit microservices provide, since your build will still break because of some completely unrelated team's code.
    • roguecoder 1y ago
      If it is possible for that other team to merge a broken build, you are doing it wrong. If you are concerned about someone else breaking your thing, good! You were going to eventually break it yourself. Write whatever testing gives you confidence that someone else's changes won't break your code, and, bonus, now you can make changes without breaking your code.
      • tuckerman 1y ago
        Even if it builds successfully, I've never worked anywhere where automated tests prevented 100% of problems and I doubt I ever will. For most systems of sufficient complexity you are testing in prod, even if you did a lot of testing before prod as well.
        • roguecoder 1y ago
          That's even more true for microservices, though, since I have yet to see a microservice architecture that automatically runs end to end tests before deploying. The post I was replying to said "your build will still break": that's what I was taking issue with. In this day and age there is no reason our trunk build should ever be broken.
• jayd16 1y ago
  it's weird that the your quote and your own explanation offer technical reasons for separate services but then you say it's not a technical pattern. You'll need services. They're hard. If something is hard but it needs to be done, you should get good at it. Like every fad, there a backlash from people seeing the fad fall apart when used poorly. Services are a good pattern with trade offs. Weigh the trade offs, just don't do things to do them.
• fallingknife 1y ago
  There are plenty of tech reasons for microservices. e.g. scaling high traffic services separately and separating low priority functionality from critical paths. I would agree that this is usually not a smart thing to do in a small org, but I have seen times where splitting out a high load path into a microservice has been very much worth it at a startup.
  • bluefirebrand 1y ago
    > scaling high traffic services separately This is a great optimization once you have high traffic services Building this way before you have any traffic at all is a great way to build the wrong abstractions because your assumptions about where your load will be might be wrong
    • gopher_space 1y ago
      Microservices are a technical solution to regional availability and pairing problems, and they start with a spreadsheet telling you when to make them based on requirements vs. cost. They're slow, expensive threads you should have a really good reason to use. > Building this way before you have any traffic at all is a great way to build the wrong abstractions These services only make sense to think about within specific traffic contexts. It'd be impossible to build the right abstraction.
• dimal 1y ago
  I saw one startup with about fifty engineers, and dozens of services. They had all of the problems that the post describes. Getting anything done was nearly impossible until you were in the system for at least six months and knew how to work around all the issues. Here’s the kicker: They only had a few hundred MAUs. Not hundreds of thousands. Hundreds of users. So all this complexity was for nothing. They burned through $50M in VC money then went under. It’s a shame because their core product was very innovative and well architected, but it didn’t matter.
  • jghn 1y ago
    > They only had a few hundred MAUs Way too many companies believe they're really just temporarily embarrassed BigTech.
    • danielscrubs 1y ago
      Bad software dev. degrees that focus on fancy architecture that brings nothing to the table except overhead.
      • betterThanTexas 1y ago
        I don't think I learned basically anything about "fancy architecture" from my undergraduate courses except, ironically, reasoning about coupling and overhead.
      • ang_cire 1y ago
        I don't remember one solitary lecture on CI/CD, microservices, or even just deployment in general, in Uni. The closest that our comp. sci. classes ever came to touching on anything but the code itself was making us use SVN.
        • danielscrubs 1y ago
          The difference between a software dev degree and a comp. sci degree.
• jimbokun 1y ago
  I thought the linked article about how Khan Academy eventually migrated to multiple services was a good example of when introducing micro services is a good idea: https://blog.khanacademy.org/go-services-one-goliath-project/ https://blog.khanacademy.org/go-services-one-goliath-project... They had already scaled the mono service about as far as it could go and had a good sense of what the service boundaries should be based on experience.
• motorest 1y ago
  > Microservices only pay off when you have (...) independently evolving domains. I don't see any major epiphany in this. In fact, it reads like a tautology. The very definition of microservice is that it's an independently evolving domain. That's a basic requirement.
• tstrimple 1y ago
  I put my team through this as an inexperienced lead about 15 years ago. We were a team of less than a dozen who had a nice single solution file that you could build and run the entire stack from. At the end we were looking at roughly a dozen services all which required orchestration to get them running and working together. First hand lessons in YAGNI and "do the simplest thing that works" which have stuck with me the rest of my career.
• 9rx 1y ago
  > Sounds wrong Sounds right, no? Service is what people provide, implied in the scope of a macro economy. Microservice then implies the same type of service, but within the micro economy of a single business.
• PaulHoule 1y ago
  I've tended to use microservices in limited cases where the system had to serve a few requests that had radically different performance requirements, particularly memory utilization. I had a PHP server for instance that served exactly one URL for which PHP was not a good fit and a specialized server in another language for that one URL gave like 1000x better performance and money savings in terms of not needing a much bigger PHP server. Using Spring or Guava in the Java world it is frequent that people write "services" that are simply objects that implement some interface which are injected by the framework. In a case like that you can imagine a service could have either an in-process implementation or an out-of-process implementation (e.g. via a web endpoint or some RPC.) Frameworks like that normally are thinking at the level of "let's initialize one application in one address space at a time" but it would be nice to see something oriented towards managing applications that live in various address spaces. Trouble is that some people get this squee when they hear they can use JDK 9 for this project and JDK 10 for another project and JDK 11 for another project and they'd rather die than eschew the badly broken Python 3.5 for something better. If you standardized absolutely everything I think you could be highly productive with microservices because you wouldn't have to face gear switching or deal with teams who just don't know that XML serialization worked completely differently in JDK 7 vs JDK 8 thus the services they make don't quite communicate properly, etc.
• asdf6969 1y ago
  > Microservices are a design pattern for organisations as opposed to technology Very true in my experience. The main benefit is letting small groups of people work independently without stepping on each other’s toes. Although I’ve worked on a project where multiple teams owned micro services that were supposed to be standardized with each other, and it just lead to endless meetings and requirements churn since nobody was willing to work on the other teams service but everyone had an opinion on what the cross-team standard should be. Learning the diplomatic way to say “mind your own business” was more important than any technical skills for getting code merged.
• grg0 1y ago
  > sounds wrong It's not wrong at all, literally Conway's law: https://en.wikipedia.org/wiki/Conway's_law https://en.wikipedia.org/wiki/Conway's_law
• stephen 1y ago
  > Microservices are a design pattern for organisations as opposed > to technology ... breakout into multiple teams I agree, but just saying "multiple teams" has led many eng directors to think "I have two squads now --> omg they cannot both be in the same monolith". When both squads are 5 people each. And the squads re-org (or "right size") every 9 months to re-prioritize on the latest features. Five years go by, 7 team/re-org changes, all of which made sense, but thank god we didn't microservice on the 2nd/3rd/4th/5th/6th team boundaries. :grimmacing: We should stay "stable, long-lived teams" -- like you need to have a team that exists with the same ownership and mandate for ~18 months to prove its a stable entity worth forming your architecture around.