3 ms·

Cross-repo refactoring (even worse: renaming) seems like an at best worthless and at worst quite costly thing to optimize your toolchain around. Having stable i

by dcre 6y ago

Cross-repo refactoring (even worse: renaming) seems like an at best worthless and at worst quite costly thing to optimize your toolchain around. Having stable interfaces between systems is very important. The whole point of having separate systems is so you don't have to change one when you change the other. If that's not the case, you're better off with a monorepo.

mnd999 6y ago
Indeed, if you’re doing that kind of refactoring a lot what you have is a distributed monolith, not a microservices architecture.
jayd16 6y ago
I see what you're saying but I don't agree. Repo topology might not be a choice. Almost certainly new features will cut across multiple projects. Why make that hard? Tools should help you do the right thing. They should not be a painful bludgeon against other devs. Enabling fast and easy end to end testing is only helpful.
- dcre 6y ago
  I agree that you should write tools to improve the workflows you actually have. But this post, as I read it, is not written from the point of view of narrow problems and solutions — or rather, it is, but it is trying to be something else. It is talking about The Evolution of the IDE. And from that point of view I think my criticism is appropriate.
- closeparen 6y ago
  In general a new feature should have its home in one service and make calls to the existing network APIs of other services. If you’re regularly having to change the innards of those services to support new use cases, you have serious architecture debt.
  - jayd16 6y ago
    You're being overly zealous. Every service has callers. Sometimes you want to work on the caller concurrently with the callee. Sometimes even the same person can work on the feature end to end. There is no reason that making that easy to do will cause tech debt. You already have other means to your services cleanly versioned and compatible, such as tests. Making things environments easy to run locally doesn't change that.
    - closeparen 6y ago
      A caller and caller that you want to change at the same time for the same reason belong in the same service.
      - jayd16 6y ago
        If I want to add a piece of data and a visualization of that data the UI and the data store should be in the same service, no exceptions? You're saying that a desire for when something gets worked on should trump any other design decision? "Want at the same time" informs separation of concerns? You make services in an vacuum without considering the stakeholder/consumer of your service? You've never planned for a service in your org you consume to gain functionality because doing so would mean you should implement that functionality yourself in a service you own?
        closeparen 6y ago
        Teams that call themselves "platforms" are very often tempted to operate in a mode where they add a lot of one-off endpoints tailored to the specific use cases of particular callers. This skips the whole economic value of "platform" and makes them consultancies instead. My company has this problem in a big way, there are CTO-level efforts towards reusable abstractions and generic extension points instead of all this deep cross-team cross-service coupling. It is frequently the way I can add the most value in a design review: help the team come up with abstractions based on their domain model that are sufficient for their callers, instead of building to the letter of current callers' requirements (and signing themselves up to keep doing that for each new caller). "How often will we need to change this and what will that be like?" is usually my top design consideration after "will it work?" So yes on that one.

by dcre 6y ago

mnd999 6y ago

Indeed, if you’re doing that kind of refactoring a lot what you have is a distributed monolith, not a microservices architecture.

jayd16 6y ago

I see what you're saying but I don't agree. Repo topology might not be a choice. Almost certainly new features will cut across multiple projects. Why make that hard? Tools should help you do the right thing. They should not be a painful bludgeon against other devs. Enabling fast and easy end to end testing is only helpful.

dcre 6y ago
I agree that you should write tools to improve the workflows you actually have. But this post, as I read it, is not written from the point of view of narrow problems and solutions — or rather, it is, but it is trying to be something else. It is talking about The Evolution of the IDE. And from that point of view I think my criticism is appropriate.
closeparen 6y ago
In general a new feature should have its home in one service and make calls to the existing network APIs of other services. If you’re regularly having to change the innards of those services to support new use cases, you have serious architecture debt.
- jayd16 6y ago
  You're being overly zealous. Every service has callers. Sometimes you want to work on the caller concurrently with the callee. Sometimes even the same person can work on the feature end to end. There is no reason that making that easy to do will cause tech debt. You already have other means to your services cleanly versioned and compatible, such as tests. Making things environments easy to run locally doesn't change that.
  - closeparen 6y ago
    A caller and caller that you want to change at the same time for the same reason belong in the same service.
    - jayd16 6y ago
      If I want to add a piece of data and a visualization of that data the UI and the data store should be in the same service, no exceptions? You're saying that a desire for when something gets worked on should trump any other design decision? "Want at the same time" informs separation of concerns? You make services in an vacuum without considering the stakeholder/consumer of your service? You've never planned for a service in your org you consume to gain functionality because doing so would mean you should implement that functionality yourself in a service you own?
      - closeparen 6y ago
        Teams that call themselves "platforms" are very often tempted to operate in a mode where they add a lot of one-off endpoints tailored to the specific use cases of particular callers. This skips the whole economic value of "platform" and makes them consultancies instead. My company has this problem in a big way, there are CTO-level efforts towards reusable abstractions and generic extension points instead of all this deep cross-team cross-service coupling. It is frequently the way I can add the most value in a design review: help the team come up with abstractions based on their domain model that are sufficient for their callers, instead of building to the letter of current callers' requirements (and signing themselves up to keep doing that for each new caller). "How often will we need to change this and what will that be like?" is usually my top design consideration after "will it work?" So yes on that one.