4 ms·

I absolutely agree, buuuut also realize we as programmers don't even have the same definition of what a microservice is. A lot of people here say...one service

I absolutely agree, buuuut also realize we as programmers don't even have the same definition of what a microservice is. A lot of people here say...one service per team. But to me that is, or can be, a monolith. Often a team is a product line, so you have one service for that product. Is that a monolith? I don't know either, I guess. I -do- know most people who go around promoting that sweet microservice life end up being the worst. They seem to want every db table to be its own service, introduce tons of message passing and queues, etc, for absolutely no reason. I think we can probably all agree that is about the worst way to go about it.

oaiey 4y ago
Yes! It is about splitting your business in reasonable chunks/domain/boundaries. Pizza rules/rewrite rules ... that is all nonsense. But doing it right, is nevertheless hard. Because cutting your business into chunks ... is not as easy as it always looks.
bottlepalm 4y ago
Every service needs it’s own database. Then you need to handle all the DLQ errors between services as well.
- klabb3 4y ago
  Devils advocate, but is it possible microservices need a shared feature-ful message passing layer, and good tooling, to be working well? Eg schema, auth, flow control, ttl, persistence, partitioning etc in the message layer, a la Kafka? I mean it’s kind of implied that microservices can only work if they can talk to each other, and “talking” is a lot more nuanced than we tend to think.
  - bottlepalm 4y ago
    Comm requires massive overhead versus simply 'calling a function'. Calling a function doesn't fail. Maybe the code in it does, but not the call to the function itself. This is why microservice costs often far outweighs the benefits, but they rarely consider the cost in their crusade to 'break up the monolith'
    - klabb3 4y ago
      Absolutely. But in the cases where it a monolith is not doable, such as highly heterogenous hardware requirements for different “services”, it seems like the messaging stack plays a more important role (even if that’s only needed in 5% of use cases). Typical HTTP request-response, which is often fine for a monolith, is not enough for building say task queues. A strong messaging layer can reduce the need of ad-hoc wheel reinvention.
lrem 4y ago
meh In my org in Google we average over one microservice per engineer. I'll be adding two in the next couple weeks. With the right automation setup you don't notice them any more than you do server instances.

oaiey 4y ago

Yes! It is about splitting your business in reasonable chunks/domain/boundaries. Pizza rules/rewrite rules ... that is all nonsense. But doing it right, is nevertheless hard. Because cutting your business into chunks ... is not as easy as it always looks.

bottlepalm 4y ago

Every service needs it’s own database. Then you need to handle all the DLQ errors between services as well.

klabb3 4y ago
Devils advocate, but is it possible microservices need a shared feature-ful message passing layer, and good tooling, to be working well? Eg schema, auth, flow control, ttl, persistence, partitioning etc in the message layer, a la Kafka? I mean it’s kind of implied that microservices can only work if they can talk to each other, and “talking” is a lot more nuanced than we tend to think.
- bottlepalm 4y ago
  Comm requires massive overhead versus simply 'calling a function'. Calling a function doesn't fail. Maybe the code in it does, but not the call to the function itself. This is why microservice costs often far outweighs the benefits, but they rarely consider the cost in their crusade to 'break up the monolith'
  - klabb3 4y ago
    Absolutely. But in the cases where it a monolith is not doable, such as highly heterogenous hardware requirements for different “services”, it seems like the messaging stack plays a more important role (even if that’s only needed in 5% of use cases). Typical HTTP request-response, which is often fine for a monolith, is not enough for building say task queues. A strong messaging layer can reduce the need of ad-hoc wheel reinvention.

lrem 4y ago

meh In my org in Google we average over one microservice per engineer. I'll be adding two in the next couple weeks. With the right automation setup you don't notice them any more than you do server instances.