4 ms·

I know microservices are successful in many organizations but one downside I've experienced from the microservices hype is starting an application with microser

by 100k 10y ago

I know microservices are successful in many organizations but one downside I've experienced from the microservices hype is starting an application with microservices. It's very difficult to get the system boundaries correct while you're still iterating on core functionality, and if you get it wrong you're in a world of pain. Refactoring becomes very hard and performance suffers from unnecessary network overhead. Deployment is harder. Coordination is harder. Developers can't run the whole system locally. Testing is harder. Basically, if you don't have a very well defined interface between components, it's going to hurt. I would not recommend starting with a microservices architecture. Build a modular, well-factored application and split out pieces if they need to be scaled separately or there are other compelling benefits of a microservice. To quote Kris Jenkins: This is your return type: Int This is your return type on microservices: IO (Logger (Either HttpError Int)) Microservices: Know the risks. https://twitter.com/krisajenkins/status/762901550696194048 https://twitter.com/krisajenkins/status/762901550696194048

nawitus 10y ago
"Developers can't run the whole system locally." Developers should be able to run the whole system locally.
- 100k 10y ago
  I agree. In the system I'm currently working on, they can't. I think it would be possible to implement, but no one has been able to take the time (or, perhaps sees the value in it). (OTOH, I kind of doubt developers at Google or Facebook run the whole thing locally, so there must be some kind of end state for this.)
  - nawitus 10y ago
    If the alternative to microservices is a monolith, and you can run the monolith locally, then logically microservices can also be run locally. If it's difficult to run all the microservices locally then that's just a sign of weak tooling.
    - 100k 10y ago
      Yes, the tooling is weak. Now, let's convince the engineering managers to spend a bunch of time building tooling to start everything together and fix service discovery on localhost. Turns out, they'd rather build features. I'm with you 100%. It drives me crazy, but right now you cannot run multiple services locally without a bunch of fiddling.
      - nawitus 10y ago
        In my own projects you can start up every microservice with a single command / script. Yes, having sufficient tooling for microservices does consume resources.
      - cookiecaper 10y ago
        It's not impossible. As a sibling comment says, it usually just requires a bunch of ad-hoc scripts to make sure everything is running. This does get increasingly complex, especially as microservices are written with different stacks, but that's part of the tradeoff.
    - cloakandswagger 10y ago
      "Just a sign of weak tooling." Why does technical overhead take a backseat whenever a microservices vs monolith discussion comes up? Yes, in a perfect world every org would have sufficient time and engineering resources to implement microservices for better scalability and code quality. In the real world, setting up and maintaining microservices has huge technical overhead, I'd estimate double that of the equivalent monolithic architecture. If your company isn't flush with cash and the product you're building will never need massive scaling then it makes no sense to use microservices, at least from a business perspective.
      - nawitus 10y ago
        "Why does technical overhead take a backseat whenever a microservices vs monolith discussion comes up?" I don't think it does, but that's kind of off topic. "In the real world, setting up and maintaining microservices has huge technical overhead, I'd estimate double that of the equivalent monolithic architecture." I agree.
  - vojant 10y ago
    I actually disagree, developers doesn't need to run the whole code on the local env. In my company we use development docker cluster where we keep instances of all of our micro-services and they are exposed (via vpn) to the outside world so you can call them by domains. When you work on the logic that e.g. would affect 2 micro-services you can just set-up 2 of them and make remote request to the dev env for everything else. I don't see any reason why you should run all of them on your computer.
    - 100k 10y ago
      Yeah that's a good point. When the system is too big there's no way you can run it all locally. The angle I'm coming from is an application that's fairly new and still small and is changing rapidly with lots of cross-cutting changes. We're paying some heavy microservices taxes with development, testing, deployment, and performance, but not at a point where we see benefits yet (IMHO).
- logn 10y ago
  It shouldn't be too hard to set up some common code for making service calls. If the service isn't responding, the caller compiles and starts it, assuming some env variable is set to signal it's a dev machine. I've done this for my project.
- platz 10y ago
  I doubt your company is going to allow you to run your merchant cc payment processor locally.
  - closeparen 10y ago
    Why not? Paypal and Stripe have sandbox modes. Use fake numbers. Your company certainly shouldn't let you run CC processing code for this first time in production.
- flukus 10y ago
  You know how many shops run on shared databases because the still have no idea how to manage changes? I'd say the answer would be most.

by 100k 10y ago

nawitus 10y ago

"Developers can't run the whole system locally." Developers should be able to run the whole system locally.

100k 10y ago
I agree. In the system I'm currently working on, they can't. I think it would be possible to implement, but no one has been able to take the time (or, perhaps sees the value in it). (OTOH, I kind of doubt developers at Google or Facebook run the whole thing locally, so there must be some kind of end state for this.)
- nawitus 10y ago
  If the alternative to microservices is a monolith, and you can run the monolith locally, then logically microservices can also be run locally. If it's difficult to run all the microservices locally then that's just a sign of weak tooling.
  - 100k 10y ago
    Yes, the tooling is weak. Now, let's convince the engineering managers to spend a bunch of time building tooling to start everything together and fix service discovery on localhost. Turns out, they'd rather build features. I'm with you 100%. It drives me crazy, but right now you cannot run multiple services locally without a bunch of fiddling.
    - nawitus 10y ago
      In my own projects you can start up every microservice with a single command / script. Yes, having sufficient tooling for microservices does consume resources.
    - cookiecaper 10y ago
      It's not impossible. As a sibling comment says, it usually just requires a bunch of ad-hoc scripts to make sure everything is running. This does get increasingly complex, especially as microservices are written with different stacks, but that's part of the tradeoff.
  - cloakandswagger 10y ago
    "Just a sign of weak tooling." Why does technical overhead take a backseat whenever a microservices vs monolith discussion comes up? Yes, in a perfect world every org would have sufficient time and engineering resources to implement microservices for better scalability and code quality. In the real world, setting up and maintaining microservices has huge technical overhead, I'd estimate double that of the equivalent monolithic architecture. If your company isn't flush with cash and the product you're building will never need massive scaling then it makes no sense to use microservices, at least from a business perspective.
    - nawitus 10y ago
      "Why does technical overhead take a backseat whenever a microservices vs monolith discussion comes up?" I don't think it does, but that's kind of off topic. "In the real world, setting up and maintaining microservices has huge technical overhead, I'd estimate double that of the equivalent monolithic architecture." I agree.
- vojant 10y ago
  I actually disagree, developers doesn't need to run the whole code on the local env. In my company we use development docker cluster where we keep instances of all of our micro-services and they are exposed (via vpn) to the outside world so you can call them by domains. When you work on the logic that e.g. would affect 2 micro-services you can just set-up 2 of them and make remote request to the dev env for everything else. I don't see any reason why you should run all of them on your computer.
  - 100k 10y ago
    Yeah that's a good point. When the system is too big there's no way you can run it all locally. The angle I'm coming from is an application that's fairly new and still small and is changing rapidly with lots of cross-cutting changes. We're paying some heavy microservices taxes with development, testing, deployment, and performance, but not at a point where we see benefits yet (IMHO).
logn 10y ago
It shouldn't be too hard to set up some common code for making service calls. If the service isn't responding, the caller compiles and starts it, assuming some env variable is set to signal it's a dev machine. I've done this for my project.
platz 10y ago
I doubt your company is going to allow you to run your merchant cc payment processor locally.
- closeparen 10y ago
  Why not? Paypal and Stripe have sandbox modes. Use fake numbers. Your company certainly shouldn't let you run CC processing code for this first time in production.
flukus 10y ago
You know how many shops run on shared databases because the still have no idea how to manage changes? I'd say the answer would be most.