4 ms·

Avoid microservices entirely and you won't adopt 50 unnecessary cloud services and external SaaS platforms to help you manage those 50 services. If each busines

Avoid microservices entirely and you won't adopt 50 unnecessary cloud services and external SaaS platforms to help you manage those 50 services. If each business unit/domain has their own "monolith" it serves the same goals without the hype and complexity.

BenoitP 5y ago
But then 10 years down the line you'll be scrambling to implement Master Data Management, where you'll try (unsuccessfully) to merge user profiles and data. I'm very anti-microservices, and rather than implement them for organizational reasons (read: teams unable to work together), I think that the most important business objects need to be maintained at a single point. Managing user identity at a single point is a valid reasons for microservices; like Google does with gmail/search/drive/storage/cloud services/youtube/android/etc.
- fn1 5y ago
  > where you'll try (unsuccessfully) to merge user profiles and data. Why? Can't a monolith be refactored?
  - BenoitP 5y ago
    I was talking about each silo of data; which is orthogonal to each monolith's code being refactorable. > If each business unit/domain has their own "monolith" This furiously looks like accidental microserviced data; which is kind of ironic considering the original comment was about "Avoid microservices entirely". And yes, important business objects managed by different microservices are a PITA to merge; basically you're going to ask the users themselves to merge profiles, and they'll answer "we're divorced now" / "I like it better having multiple accounts, I get more promo codes" / "Why should I?" / "I don't care" / "Who are you?".
- fouc 5y ago
  Is that a microservice though? That sounds more like a proper service.
RandyRanderson 5y ago
I guess this is obvious but for the record: once one company using hot_tech_x gets significant funding, several more do. Then you have a bunch of ppl invested (literally) in hot_tech_x's success. hot_tech_x is then the answer to every problem. clogged sink? microservice. Maybe a question is: what is today's hot tech? Do we even care as long as we get paid?
- dreyfan 5y ago
  > Maybe a question is: what is today's hot tech? React, Kubernetes, Docker, GraphQL, Elixir You're absolutely right. So few companies are solving actual problems anymore. It's all a cyclical bullshit hype cycle with very little innovation. Once the hot tech company IPOs, VC's force feed the next wave of bullshit tech/ideas. I hope Fowler is getting compensated well by the cloud companies for his misinterpreted advice.
est 5y ago
My theory is if you can't organize local-procedure-calls properly, then don't bother do remote-procedure-calls entirely.
- pantulis 5y ago
  This reasoning is absolutely spot on.
throwaway984393 5y ago
I mean, if that's feasible, sure. The problem is there's plenty of businesses that simply can't or won't justify the work to make a couple monoliths. Often there's dozens of microservices because there's dozens of acquisitions that nobody is willing to invest any money in; the microservices are hipster business glue. If they were run by smart people they'd realize that the cost of maintenance for dozens of new microservices to wrap around a bunch of shitty legacy acquisitions is far more expensive than just refactoring the legacy apps (or tearing out chunks and shoving them in other products, or making brand new products out of one or two features). But try telling some C-level bozos from an industry that knows nothing about tech that.
- konschubert 5y ago
  The monoliths you acquire through acquisitions aren't really microservices :)
adrianN 5y ago
Write microservices, but link them in one binary and do normal procedure calls. The important part about microservices are the clear interfaces, the lack of global state blobs, and the independent testability, not the 50 cloud services needed to manage containers.
- dgb23 5y ago
  Sounds like modules to me.
  - adrianN 5y ago
    Modules, but with 100% more hype. Best practices for software engineering haven't changed all that much in the last two decades or so, but the vocabulary keeps changing.
- konschubert 5y ago
  One advantage of real microservices is that you get better tooling around rate-limiting HTTP APIs than for simple function calls. And it's much easier to see which services creates the most CPU/Database/Network load.
  - muxator 5y ago
    In this context, the measuring aspect would be taken care by profiling/instrumenting.

BenoitP 5y ago

But then 10 years down the line you'll be scrambling to implement Master Data Management, where you'll try (unsuccessfully) to merge user profiles and data. I'm very anti-microservices, and rather than implement them for organizational reasons (read: teams unable to work together), I think that the most important business objects need to be maintained at a single point. Managing user identity at a single point is a valid reasons for microservices; like Google does with gmail/search/drive/storage/cloud services/youtube/android/etc.

fn1 5y ago
> where you'll try (unsuccessfully) to merge user profiles and data. Why? Can't a monolith be refactored?
- BenoitP 5y ago
  I was talking about each silo of data; which is orthogonal to each monolith's code being refactorable. > If each business unit/domain has their own "monolith" This furiously looks like accidental microserviced data; which is kind of ironic considering the original comment was about "Avoid microservices entirely". And yes, important business objects managed by different microservices are a PITA to merge; basically you're going to ask the users themselves to merge profiles, and they'll answer "we're divorced now" / "I like it better having multiple accounts, I get more promo codes" / "Why should I?" / "I don't care" / "Who are you?".
fouc 5y ago
Is that a microservice though? That sounds more like a proper service.

RandyRanderson 5y ago

I guess this is obvious but for the record: once one company using hot_tech_x gets significant funding, several more do. Then you have a bunch of ppl invested (literally) in hot_tech_x's success. hot_tech_x is then the answer to every problem. clogged sink? microservice. Maybe a question is: what is today's hot tech? Do we even care as long as we get paid?

dreyfan 5y ago
> Maybe a question is: what is today's hot tech? React, Kubernetes, Docker, GraphQL, Elixir You're absolutely right. So few companies are solving actual problems anymore. It's all a cyclical bullshit hype cycle with very little innovation. Once the hot tech company IPOs, VC's force feed the next wave of bullshit tech/ideas. I hope Fowler is getting compensated well by the cloud companies for his misinterpreted advice.

est 5y ago

My theory is if you can't organize local-procedure-calls properly, then don't bother do remote-procedure-calls entirely.

pantulis 5y ago
This reasoning is absolutely spot on.

throwaway984393 5y ago

I mean, if that's feasible, sure. The problem is there's plenty of businesses that simply can't or won't justify the work to make a couple monoliths. Often there's dozens of microservices because there's dozens of acquisitions that nobody is willing to invest any money in; the microservices are hipster business glue. If they were run by smart people they'd realize that the cost of maintenance for dozens of new microservices to wrap around a bunch of shitty legacy acquisitions is far more expensive than just refactoring the legacy apps (or tearing out chunks and shoving them in other products, or making brand new products out of one or two features). But try telling some C-level bozos from an industry that knows nothing about tech that.

konschubert 5y ago
The monoliths you acquire through acquisitions aren't really microservices :)

adrianN 5y ago

Write microservices, but link them in one binary and do normal procedure calls. The important part about microservices are the clear interfaces, the lack of global state blobs, and the independent testability, not the 50 cloud services needed to manage containers.

dgb23 5y ago
Sounds like modules to me.
- adrianN 5y ago
  Modules, but with 100% more hype. Best practices for software engineering haven't changed all that much in the last two decades or so, but the vocabulary keeps changing.
konschubert 5y ago
One advantage of real microservices is that you get better tooling around rate-limiting HTTP APIs than for simple function calls. And it's much easier to see which services creates the most CPU/Database/Network load.
- muxator 5y ago
  In this context, the measuring aspect would be taken care by profiling/instrumenting.