4 ms·

> The higher coupling in most monoliths also restricts a teams ability to try new things and take risks. I think it's you who's missing the point. That right t

by pdpi 11y ago

> The higher coupling in most monoliths also restricts a teams ability to try new things and take risks. I think it's you who's missing the point. That right there is why. Turning your monolith into a micro-service architecture should add up to basically: - Wrap your internal modules in your favourite form of RPC - Replace the modules with stubs that call the RPC If you need more work than that, the problem with your application isn't being a monolith, it's having functionality be way too tightly coupled. If turning your application into a micro-service architecture actually _is_ that simple, then you already have well-delineated modules that your teams can focus on. Deployment is just about integrating the latest stable version of each module, and the decision process within each team needs only respect the contract around the interface they provide -- same as a micro-service. Saying you need a micro-service architecture to keep a sane internal structure to your application is a symptom that you need to review your engineering practices, because people aren't respecting the interfaces, and it's throwing out the baby with the bathwater.

to3m 11y ago
Don't forget that an RPC call can take longer to complete than a function call. Loose coupling doesn't imply that your program expects operations to routinely take 1ms to return results.
- mje__ 11y ago
  Or sometimes 10s, or never, or partial results, or dropped connections, or... The network is not reliable.
- pdpi 11y ago
  I was replying to a comment that ended with "If performance of technology is the only metric that matters to you, then yes, microservices are probably a horrible idea". I figured that it'd be more effective to make my point without bringing performance into the discussion.
cpitman 11y ago
I get what you're saying, and I've tried both ways: using project structure to explicitly force modularity vs trying to instill culture and practices to preserve modularity within a monolith. I should mention I am a consultant, so I tend to work in enterprise environments with varying levels of practices and maturity. My experience has been that lots of different people will touch a codebase over the lifetime of a piece of software, and they will have varying skill levels. Even if everyone on the team right now will avoid creating a ball of spaghetti, at some point everyone involved will be gone. Patches and new functionality end up getting bolted on and added to an ever growing list of technical debt (we'll get to it, we swear). 10 years down the line no one can maintain it because no one knows what the interactions are across the system. Splitting code into separate services/codebases doesn't totally prevent this from happening, but it does make it a lot harder. First, adding coupling is no longer the path of least resistance when you "need to delivery yesterday". Second, each service is significantly easier to grok than a single legacy monolith, and therefore easier to refactor back to sanity. Vaguely related, I also really like how microservices offer a non-insane approach to modernizing a large system. A lot of my clients have large highly-coupled mainframe applications written in Smalltalk/COBOL/etc. They want to migrate to a "modern" language (ie one with a workforce). Big bang migrations almost never work, so we end up carving off functionality, re-implementing it in the new framework, and then integrating it with the monolith via messaging/services. Microservices make it easier to pull out one piece and rewrite it, without having to also touch every client.
- pdpi 11y ago
  > First, adding coupling is no longer the path of least resistance when you "need to delivery yesterday". I wouldn't be so sure. More often than not, it's cheaper to set up a new module/library than it is to setup a whole new service, and I've seen plenty of cases where people just tacked functionality on to the handiest service because they needed to get shit done Right Now, and setting up a new service was a waste of time.
dreamfactory2 11y ago
The microservices approach has 2 major benefits - 1. Those boundaries running over services allows you a lot of flexibility in read caching using commodity software like Varnish or Mongo (generally assuming REST here) 2. It allows for a polyglot architecture (ok it's a benefit or disadvantage depending on your outlook)

by pdpi 11y ago

to3m 11y ago

Don't forget that an RPC call can take longer to complete than a function call. Loose coupling doesn't imply that your program expects operations to routinely take 1ms to return results.

mje__ 11y ago
Or sometimes 10s, or never, or partial results, or dropped connections, or... The network is not reliable.
pdpi 11y ago
I was replying to a comment that ended with "If performance of technology is the only metric that matters to you, then yes, microservices are probably a horrible idea". I figured that it'd be more effective to make my point without bringing performance into the discussion.

cpitman 11y ago

I get what you're saying, and I've tried both ways: using project structure to explicitly force modularity vs trying to instill culture and practices to preserve modularity within a monolith. I should mention I am a consultant, so I tend to work in enterprise environments with varying levels of practices and maturity. My experience has been that lots of different people will touch a codebase over the lifetime of a piece of software, and they will have varying skill levels. Even if everyone on the team right now will avoid creating a ball of spaghetti, at some point everyone involved will be gone. Patches and new functionality end up getting bolted on and added to an ever growing list of technical debt (we'll get to it, we swear). 10 years down the line no one can maintain it because no one knows what the interactions are across the system. Splitting code into separate services/codebases doesn't totally prevent this from happening, but it does make it a lot harder. First, adding coupling is no longer the path of least resistance when you "need to delivery yesterday". Second, each service is significantly easier to grok than a single legacy monolith, and therefore easier to refactor back to sanity. Vaguely related, I also really like how microservices offer a non-insane approach to modernizing a large system. A lot of my clients have large highly-coupled mainframe applications written in Smalltalk/COBOL/etc. They want to migrate to a "modern" language (ie one with a workforce). Big bang migrations almost never work, so we end up carving off functionality, re-implementing it in the new framework, and then integrating it with the monolith via messaging/services. Microservices make it easier to pull out one piece and rewrite it, without having to also touch every client.

pdpi 11y ago
> First, adding coupling is no longer the path of least resistance when you "need to delivery yesterday". I wouldn't be so sure. More often than not, it's cheaper to set up a new module/library than it is to setup a whole new service, and I've seen plenty of cases where people just tacked functionality on to the handiest service because they needed to get shit done Right Now, and setting up a new service was a waste of time.

dreamfactory2 11y ago

The microservices approach has 2 major benefits - 1. Those boundaries running over services allows you a lot of flexibility in read caching using commodity software like Varnish or Mongo (generally assuming REST here) 2. It allows for a polyglot architecture (ok it's a benefit or disadvantage depending on your outlook)