11 ms·

Microservices brings a lot of complexity. Yeah you're not analyzing a stack trace, instead you put correlation IDs in your requests and you analyze a network ca

by linkdd 6y ago

Microservices brings a lot of complexity. Yeah you're not analyzing a stack trace, instead you put correlation IDs in your requests and you analyze a network call stack. And you'll need a centralized logging mechanism to not have to log to hundreds of servers (or pods if running on kubernetes) to get that sweet failing request with its correlation ID. It's far more easier to do Service Oriented Architecture when you don't need the performance/flexibility/scaling of microservices. I would not recommend any startup to go through the microservice route until they have the resources *and the need* to do so.

100011_100001 6y ago
Microservices done right help isolate issues though. If you have an ecosystem of 100 microservices, but blue-widget-microservice is throwing errors you know which codebase you need to look at. Of course it might turn out that the errors are coming from bad inbound REST calls, but regardless it helps to narrow things down. I don't think that microservices work well with a pure server kind of architecture. For one you miss out on a fundamental microservice advantages, scalability and portability.
- candiddevmike 6y ago
  Does it though? If you're triaging an issue, in a microservice environment, errors become limitless red herrings. Reproducibility becomes an enormous undertaking, especially when you can't (quickly) recreate the entire stack ("won't fit on my laptop"). A monolith can be quite scalable and portable.
  - coding123 6y ago
    Not only can a monolithic code base be scaleable but you can make it into microservices by adjusting it's startup parameters: monolith --start-batch-jobs monolith --start-claim-processor monolith --start-graphql And they would be interconnected probably via some clustering protocol with libraries that hide the complexity and runs a bus available in a litany of languages. Need scale? k8s replica count on the above pods.
    - cameronbrown 6y ago
      Hmm, wouldn't it make more sense to keep batch jobs outside the monolith? Everything else makes sense to stay in a single binary.
      - coding123 6y ago
        The point of it is to be able to run it simply for developers developering things. If I run in prod with 12 different splits of code, that's fine. If I want to run this locally to develop new features, I would love to put in a breakpoint to see my puppeteer job run to do some screen scraping without having to have 15 VSCode windows open. (Which is what I sometimes have to do at my current company because we're a team of 6 doing microservices with 12 apps (more planned yay).
  - hvidgaard 6y ago
    My experience is that monoliths tend to decay over time unless some serious discipline is enforced. It's possible to reference across boundaries, so that happens sooner or later. By going down a microservice route, those boundaries are ruthlessly enforce because it's the only way. That trade off may or may not be worth it.
    - linkdd 6y ago
      Not doing microservice does not mean doing monolith. There is an in-between that you can aim for.
  - 100011_100001 6y ago
    But you don't have to recreate the entire stack, that's the whole point.
- mumblemumble 6y ago
  > If you have an ecosystem of 100 microservices, but blue-widget-microservice is throwing errors you know which codebase you need to look at. If you have a system with 100 well-defined modules, but blue-widget-model is throwing errors, you know which codebase you need to look at. No modularization technique has a monopoly on this characteristic.
  - 100011_100001 6y ago
    It's a lot easier to violate that when it's just an import and a call away. I will concede that if the system is well designed and developers follow the patterns set it doesn't matter if it's a microservice based architecture or not.
    - mumblemumble 6y ago
      I suppose it depends on your language. For example, if you're working in Java 8 where everything's just one big jumbled globally visible classpath, sure. If, on the other hand, you're working in Java 9 or later, you have the ability to control your public interface. People can get around that with reflection, so it's technically more permeable than a service boundary, but, if you're letting shenanigans like that sail past code review, you get what you deserve.
      - 100011_100001 6y ago
        Perhaps the dev culture I am in is skewing my perspective. There have been developers that have changed private methods to public just so that they can access them. You make a good point, it's a code review problem and by extension Architecture teams not communicating effectively with Dev Leads.
        rowland66 6y ago
        I agree, and packages and package private access is such a powerful tool in Java, that so many developers completely ignore.
cmdkeen 6y ago
This article explicitly goes down the "micro" in microservices route, which does have the problems you identify. There's an alternative school of thought that regrets, or at least downplays the obsession with "micro". Much of the drive to microservices was a reaction against things like the Enterprise Service Bus in the SOA world becoming the big ball of mud no-one can easily change - SOA and microservices don't have to look a world apart. I'm a big fan of Mark Richards and Neal Ford's emphasis of architecture being about trade-offs. No one thing is a silver bullet.
- linkdd 6y ago
  What I call a Service Oriented Architecture is much like the Microservice architecture but without worrying about the "micro" aspect. Typical architecture in our projects: - User Management Service with ORY[1] - Payment Service with Stripe[2] - Hasura[3] for the storage layer - GraphQL backend querying the above services - Frontend querying the GraphQL backend Basically, we tend to delegate the boilerplate to third-parties (self-hosted whenever it's possible) and only implement the business logic ourselves. [1] - https://ory.sh https://ory.sh [2] - https://stripe.com https://stripe.com [3] - https://hasura.io https://hasura.io
discreteevent 6y ago
Microservices: Instead of debugging a function, debug why it didn't even get called. What a waste of time.
ex_amazon_sde 6y ago
Ex-Amazon SDE here: SOA is good, team boundaries are good, tiny microservices are bad, distibuted monolith is really bad. > performance/flexibility/scaling of microservices Tiny microservices tend to perform and scale poorly due to their granularity.
- fatnoah 6y ago
  >Ex-Amazon SDE here: SOA is good, tiny microservices are not. Fully agree. Unless the strict granularity is needed, which it's usually not, services should align to the tasks that the upstream "user" needs to accomplish. If every task requires calling the same 4 microservices in sequence, you've done it wrong. At the very least, the granularity should exist only where it's needed.
- __jem 6y ago
  Disagree with distributed monolith. It's a big team/small team thing. We converted a big monolith batch processing application to streaming + Kafka using what might be described as a distributed monolith and it worked great. Using a single framework abstraction (in this case Spring) helps eliminate a huge amount of incidental complexity. We don't want teams inventing their own ways to manage things like retries, topic creation / administration, dlq, partitioning,... If I wasn't using Spring/Java, I'd be using Elixir for similar reasons. Frameworks are good for async/distributed programming. If you work in big tech and have enormous amounts of resources to throw at it, sure, go with totally independent microservices. But, distributed monolith can be very productive and provide a significantly easier mental model.
  - linkdd 6y ago
    Erlang/Elixir is a bad example because much of the microservice best practices come from (IMHO) the actor model implemented with OTP. Put your microservices in a mono-repo, replace "microservice" by "erlang process", replace "orchestration" with "OTP supervisors", and that's it. Conceptually it's almost the same.
  - deleted 6y ago
    [deleted]

by linkdd 6y ago

100011_100001 6y ago

Microservices done right help isolate issues though. If you have an ecosystem of 100 microservices, but blue-widget-microservice is throwing errors you know which codebase you need to look at. Of course it might turn out that the errors are coming from bad inbound REST calls, but regardless it helps to narrow things down. I don't think that microservices work well with a pure server kind of architecture. For one you miss out on a fundamental microservice advantages, scalability and portability.

candiddevmike 6y ago
Does it though? If you're triaging an issue, in a microservice environment, errors become limitless red herrings. Reproducibility becomes an enormous undertaking, especially when you can't (quickly) recreate the entire stack ("won't fit on my laptop"). A monolith can be quite scalable and portable.
- coding123 6y ago
  Not only can a monolithic code base be scaleable but you can make it into microservices by adjusting it's startup parameters: monolith --start-batch-jobs monolith --start-claim-processor monolith --start-graphql And they would be interconnected probably via some clustering protocol with libraries that hide the complexity and runs a bus available in a litany of languages. Need scale? k8s replica count on the above pods.
  - cameronbrown 6y ago
    Hmm, wouldn't it make more sense to keep batch jobs outside the monolith? Everything else makes sense to stay in a single binary.
    - coding123 6y ago
      The point of it is to be able to run it simply for developers developering things. If I run in prod with 12 different splits of code, that's fine. If I want to run this locally to develop new features, I would love to put in a breakpoint to see my puppeteer job run to do some screen scraping without having to have 15 VSCode windows open. (Which is what I sometimes have to do at my current company because we're a team of 6 doing microservices with 12 apps (more planned yay).
- hvidgaard 6y ago
  My experience is that monoliths tend to decay over time unless some serious discipline is enforced. It's possible to reference across boundaries, so that happens sooner or later. By going down a microservice route, those boundaries are ruthlessly enforce because it's the only way. That trade off may or may not be worth it.
  - linkdd 6y ago
    Not doing microservice does not mean doing monolith. There is an in-between that you can aim for.
- 100011_100001 6y ago
  But you don't have to recreate the entire stack, that's the whole point.
mumblemumble 6y ago
> If you have an ecosystem of 100 microservices, but blue-widget-microservice is throwing errors you know which codebase you need to look at. If you have a system with 100 well-defined modules, but blue-widget-model is throwing errors, you know which codebase you need to look at. No modularization technique has a monopoly on this characteristic.
- 100011_100001 6y ago
  It's a lot easier to violate that when it's just an import and a call away. I will concede that if the system is well designed and developers follow the patterns set it doesn't matter if it's a microservice based architecture or not.
  - mumblemumble 6y ago
    I suppose it depends on your language. For example, if you're working in Java 8 where everything's just one big jumbled globally visible classpath, sure. If, on the other hand, you're working in Java 9 or later, you have the ability to control your public interface. People can get around that with reflection, so it's technically more permeable than a service boundary, but, if you're letting shenanigans like that sail past code review, you get what you deserve.
    - 100011_100001 6y ago
      Perhaps the dev culture I am in is skewing my perspective. There have been developers that have changed private methods to public just so that they can access them. You make a good point, it's a code review problem and by extension Architecture teams not communicating effectively with Dev Leads.
      - rowland66 6y ago
        I agree, and packages and package private access is such a powerful tool in Java, that so many developers completely ignore.

cmdkeen 6y ago

This article explicitly goes down the "micro" in microservices route, which does have the problems you identify. There's an alternative school of thought that regrets, or at least downplays the obsession with "micro". Much of the drive to microservices was a reaction against things like the Enterprise Service Bus in the SOA world becoming the big ball of mud no-one can easily change - SOA and microservices don't have to look a world apart. I'm a big fan of Mark Richards and Neal Ford's emphasis of architecture being about trade-offs. No one thing is a silver bullet.

linkdd 6y ago
What I call a Service Oriented Architecture is much like the Microservice architecture but without worrying about the "micro" aspect. Typical architecture in our projects: - User Management Service with ORY[1] - Payment Service with Stripe[2] - Hasura[3] for the storage layer - GraphQL backend querying the above services - Frontend querying the GraphQL backend Basically, we tend to delegate the boilerplate to third-parties (self-hosted whenever it's possible) and only implement the business logic ourselves. [1] - https://ory.sh https://ory.sh [2] - https://stripe.com https://stripe.com [3] - https://hasura.io https://hasura.io

discreteevent 6y ago

Microservices: Instead of debugging a function, debug why it didn't even get called. What a waste of time.

ex_amazon_sde 6y ago

Ex-Amazon SDE here: SOA is good, team boundaries are good, tiny microservices are bad, distibuted monolith is really bad. > performance/flexibility/scaling of microservices Tiny microservices tend to perform and scale poorly due to their granularity.

fatnoah 6y ago
>Ex-Amazon SDE here: SOA is good, tiny microservices are not. Fully agree. Unless the strict granularity is needed, which it's usually not, services should align to the tasks that the upstream "user" needs to accomplish. If every task requires calling the same 4 microservices in sequence, you've done it wrong. At the very least, the granularity should exist only where it's needed.
__jem 6y ago
Disagree with distributed monolith. It's a big team/small team thing. We converted a big monolith batch processing application to streaming + Kafka using what might be described as a distributed monolith and it worked great. Using a single framework abstraction (in this case Spring) helps eliminate a huge amount of incidental complexity. We don't want teams inventing their own ways to manage things like retries, topic creation / administration, dlq, partitioning,... If I wasn't using Spring/Java, I'd be using Elixir for similar reasons. Frameworks are good for async/distributed programming. If you work in big tech and have enormous amounts of resources to throw at it, sure, go with totally independent microservices. But, distributed monolith can be very productive and provide a significantly easier mental model.
- linkdd 6y ago
  Erlang/Elixir is a bad example because much of the microservice best practices come from (IMHO) the actor model implemented with OTP. Put your microservices in a mono-repo, replace "microservice" by "erlang process", replace "orchestration" with "OTP supervisors", and that's it. Conceptually it's almost the same.
- deleted 6y ago
  [deleted]