Comment by echelon

Comment by echelon 3 days ago

9 replies

View on Hacker News

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.

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
      • hosh 2 days ago

        Kubernetes is a good example of a microservice architecture. It was designed in a way where each microservice work with other microservices in a way where the dependencies are not so coupled together.

        For example, the API server only reads and writes resources to etcd. A separate microservice called the scheduler does the actual assignment of pods to nodes by watching for changes in the resource store against available nodes. And yet a different microservice that lives on each node accepts the assignment and boots up (or shuts down) pods assigned to its node. It is called the kublet. The API server does none of that.

        You can run the kublet all on its own, or even replace it to change part of the architecture. Someone was building a kublet that uses systemd instead of docker, and Fly.io (who seems to hate kubernetes) wrote a kublet that could stand things up using their edge infrastructure.

        The API server also does some validations, but it also allows for other microservices to insert itself into the validation chain through pod admission webhooks.

        Other examples: deployment controllers, replicaset controllers, horizontal pod autoscalers, and cluster autoscalers to work independently of each other yet coordinated together to respond to changing circumstances. Operators are microservices that manage a specific application component, such as redis, rabbitmq, Postgresql, tailscale, etc.

        One of the big benefits of this is that Kubernetes become very extensible. Third-party vendors can write custom microservices to work with their platform (for example, storage interfaces for GCP, AWS, Azure, or Ceph, etc). An organization implementing Kubernetes can tailor it to fit their needs, whether it is something minimal or something operating in highly regulated markets.

        Ironically, Kubernetes is typically seen and understood by many to be a monolith. Kubernetes, and the domain it was designed to solve is complex, but incorrectly understanding Kubernetes as a monolith creates a lot of confusion for people working with it.

        Reply View 0 replies
      • treis 3 days ago

        That's the good old two pizza team service oriented architecture that Amazon is known for. Microservices are much smaller than that. At current job I think we have slightly more microservices than engineers on the team.

        Reply View 1 reply
        • ants_everywhere 3 days ago

          > At current job I think we have slightly more microservices than engineers on the team.

          You are free to do that, but that's a very specific take on microservices that is at odds with the wider industry. As I said above, what I was describing is what Google referred to internally as microservices. Microservices are not smaller than that as a matter of definition, but you can choose to make them extra tiny if you wish to.

          If you look at what others say about microservices, it's consistent with what I'm saying.

          For example, Wikipedia gives as a dichotomy: "Service-oriented architecture can be implemented with web services or Microservices." By that definition every service based architecture that isn't built on web services is built on microservices.

          Google Cloud lists some examples:

          > Many e-commerce platforms use microservices to manage different aspects of their operations, such as product catalog, shopping cart, order processing, and customer accounts.

          Each of these microservices is a heavy lift. It takes a full team to implement a shopping cart correctly, or customer accounts. In fact each of these has multiple businesses offering SaaS solutions for that particular problem. What I hear you saying is that if your team were, for example, working on a shopping cart, they might break the shopping cart into smaller services. That's okay, but that's not in any way required by the definition of microservices.

          Azure says https://learn.microsoft.com/en-us/azure/architecture/guide/a...

          > Model services around the business domain. Use DDD to identify bounded contexts and define clear service boundaries. Avoid creating overly granular services, which can increase complexity and reduce performance.

          Azure also has a guide for determining microservice boundary where again you'd need a full team to build microservices of this size https://learn.microsoft.com/en-us/azure/architecture/microse...

          Reply View 0 replies