3 ms·

I contend that a lot of the issues related to microservices growing so popular is that we are missing boundaries in our applications. Instead of creating strong

I contend that a lot of the issues related to microservices growing so popular is that we are missing boundaries in our applications. Instead of creating stronger boundaries between modules (or having well defined modules at all), we create physical boundaries between applications and computers to force a protocol based system. I gave a talk about MWRC 2015 about this: http://brianknapp.me/message-oriented-programming/ http://brianknapp.me/message-oriented-programming/

josho 11y ago
You hit the nail on the head. Without discipline module boundaries aren't enforced as developers reach into internal APIs between modules to meet deadlines. The result is a complex web of dependencies that are difficult to understand and maintain. Micro services are simply a physical boundary to enforce discipline between logical modules. It is a solution to a symptom rather than solving the root causes.
- beat 11y ago
  But is treating the symptom rather than the root cause always a bad thing? Alcoholics don't keep booze in the house either. That's treating a symptom, not a cause, but it's effective. And yes, I did compare programmers violating interface boundaries to alcoholics.
  - josho 11y ago
    Good point and I do agree to an extent. However, without discipline we are simply moving the risk. Eg. We can't enforce interface boundaries in our system vs. we have a micro service architecture with N systems that we need to deploy as a monolith because we don't have the discipline to ensure backwards compatibility between systems. Yes. My current enterprise client takes a week to deploy their micro service arch. Because all systems need to be deployed at once. So, they simply traded one complexity for another without fixing the root problem--a disciplined development methodology.
    - beat 11y ago
      Yeah, I think there's a problem with the definition of microservices in theory vs in practice. In theory, the boundary of a microservice is the api, right? In practice, the boundary is the set of things you must change in order to update one part. If you have to DEPLOY ALL THE THINGS!!!! in order to update a single component, it's not a microservices architecture. Not in practice, anyway. It's a monolith with a bunch of different moving parts.
- taude 11y ago
  I've never really explicitly thought of it this way, but you're exactly right. In a well-designed monolith (or early on in it's life), there should be a distinct flow of dependencies. However, over time, with muliple devs coming and going, and requirements piling on, is that the dependencies turn into a ball of yarn. Having a physical deployment boundary might reduce this aspect of intertwined modules.

josho 11y ago

You hit the nail on the head. Without discipline module boundaries aren't enforced as developers reach into internal APIs between modules to meet deadlines. The result is a complex web of dependencies that are difficult to understand and maintain. Micro services are simply a physical boundary to enforce discipline between logical modules. It is a solution to a symptom rather than solving the root causes.

beat 11y ago
But is treating the symptom rather than the root cause always a bad thing? Alcoholics don't keep booze in the house either. That's treating a symptom, not a cause, but it's effective. And yes, I did compare programmers violating interface boundaries to alcoholics.
- josho 11y ago
  Good point and I do agree to an extent. However, without discipline we are simply moving the risk. Eg. We can't enforce interface boundaries in our system vs. we have a micro service architecture with N systems that we need to deploy as a monolith because we don't have the discipline to ensure backwards compatibility between systems. Yes. My current enterprise client takes a week to deploy their micro service arch. Because all systems need to be deployed at once. So, they simply traded one complexity for another without fixing the root problem--a disciplined development methodology.
  - beat 11y ago
    Yeah, I think there's a problem with the definition of microservices in theory vs in practice. In theory, the boundary of a microservice is the api, right? In practice, the boundary is the set of things you must change in order to update one part. If you have to DEPLOY ALL THE THINGS!!!! in order to update a single component, it's not a microservices architecture. Not in practice, anyway. It's a monolith with a bunch of different moving parts.
taude 11y ago
I've never really explicitly thought of it this way, but you're exactly right. In a well-designed monolith (or early on in it's life), there should be a distinct flow of dependencies. However, over time, with muliple devs coming and going, and requirements piling on, is that the dependencies turn into a ball of yarn. Having a physical deployment boundary might reduce this aspect of intertwined modules.