Comment by stoneman24

Comment by stoneman24 3 days ago

19 replies

View on Hacker News

I would really like to send this article out to all the developers in my small company (only 120+ people, about 40 dev & test) but the political path has been chosen and the new shiny tech has people entranced.

What we do (physics simulation software) doesn’t need all the complexity (in my option as a long time software developer & tester) and software engineering knowledge that splitting stuff into micro services require.

Only have as much complexity as you absolutely need, the old saying “Keep it simple, stupid” still has a lot of truth.

But the path is set, so I’ll just do my best as an individual contributor for the company and the clients who I work with.

echelon 3 days ago

If you have workloads with different shapes, microservices make sense.

If not, do the monolith thing as long as you can.

But if you're processing jobs that need hand off to a GPU, just carve out a service for it. Stop lamenting over microservices.

If you've got 100+ engineers and different teams own different things, try microservices. Otherwise, maybe keep doing the monolith.

If your microservice is as thin as leftpad.js and hosts only one RPC call, maybe don't do that. But if you need to carve out a thumbnailing service or authC/authZ service, that's a good boundary.

There is no "one size fits all" prescription here.

Reply View 9 replies
  • ReclusiveCoder 12 hours ago

    Indeed, that's whatthe article captures here:

    >> Microservices make sense in very specific scenarios where distinct business capabilities need independent scaling and deployment. For example, payment processing (security-critical, rarely updated) differs fundamentally from recommendation engine (memory-intensive, constantly A/B tested). These components have different scaling patterns, deployment cycles, and risk profiles, which justify separate services.

    Reply View 0 replies
  • soco 3 days ago

    I wonder, at which point is a service getting called microservice? The team-sized service advocated by the usual argument does not sound that "micro" to me - but is most of the times the right size.

    Reply View 7 replies
    • dragonwriter 2 days ago

      "Microservices" were called "microservices" because "service-oriented architecture" had devolved in practice, and even moreso in the general consciousness which had largely rejected it for this reason, into near-monoliths that supported SOAP and the WS-* series of standards for integration.

      Then, after they became popular, people got carried away with the "micro" bit, and "microservices" started getting rejected because the associated practice had skewed in the opposite direction that had caused "SOA" to be rejected.

      I guess the next iteration needs to be "goldilocks services".

      Reply View 0 replies
    • xnx 3 days ago

      Good point. They would not have been as popular if they were called "multi-services" or "team partitioned apps".

      Reply View 0 replies
    • karmakaze 3 days ago

      The definitional size I've read and heard is that you team could (with the benefit of hindsight) be able to reimplement a microservice in 2 weeks. That sounds fairly extreme but a month seems within reason to me.

      The other key difference between microservices and other architectures is that each microservice should do its primary function (temporarily) without hard dependencies, which basically means having a copy of the data that's needed. Service Oriented Architecture doesn't have this as one of its properties which is why I think of it as a mildly distributed monolith. "Distributed monolith" is the worst thing you could call a set of microservices--all the pain without the gains.

      Reply View 4 replies
      • ants_everywhere 3 days ago

        That's a pretty extreme definition in my opinion.

        Google played a role in popularizing the microservice approach.

        When I was at Google, a microservice would often be worked on with teams of 10-30 people and take a few years to implement. A small team of 4-5 people could get a service started, but it would often take additional headcount to productionize the service and go to market.

        I have a feeling people overestimate how small microservices are and underestimate how big monorepos are. About 9 times out of ten when I see something called a monorepo it's for a single project as opposed to a repo that spans multiple projects. I think the same is true of microservices. Many things that Amazon or Google considers microservices might be considered monoliths by the outside world.

        Reply View 3 replies
walt_grata 3 days ago

I started making the case for organizational efficiency rather than a technical argument. Demonstrating where the larger number of people and teams necessary to make a decision and a change and how that impacts the amount of time to ship new features has been more effective IME.

Reply View 1 reply
LtWorf 3 days ago

I thought microservices were old by now, which is why this kind of articles are finally appearing.

Reply View 1 reply
  • Nextgrid 3 days ago

    It's less about how old microservices are and more that ZIRP being over, there is now finally pressure to improve software development efficiency, and to a certain extent, optimize infrastructure costs. Developers are now riding the new wave.

    Reply View 0 replies
xnx 3 days ago

I would really like to send this article back in time 11 years

Reply View 0 replies
to11mtm 3 days ago

IMO, Engineering mindset is a huge challenge when it comes to 'do you do microservices'

And by that, I mean that I have at times seen and/or perhaps even personally used as a cudgel - "This thing has a specific contract and it is implicitly separate and it forces people to remember that if their change needs to touch other parts well then they have to communicate it". In the real world sometimes you need to partition software enough that engineers don't get too far out of the boundaries one way or another (i.e. changes inadvertently breaking something else because they were not focused enough)

Reply View 1 reply
  • randall 3 days ago

    but fr at facebook we just had unit tests. if someone else broke your code it’s your fault unless you have tests.

    there are of course microservices for things like news feed etc, but iirc all of fb.com and mobile app graphql is from the monolith by default.

    Reply View 0 replies