6 ms·

I prefer lower devops complexity and higher software application complexity. Any day. Microservices is higher devops complexity in exchange for lower software

I prefer lower devops complexity and higher software application complexity. Any day. Microservices is higher devops complexity in exchange for lower software application complexity. A really terrible deal IMO.

tmotwu 6y ago
Sure, if you are independently building your service, or working a tight feedback loop with others on the product. As others pointed out, it works for companies who operate and scale engineering teams. Good luck maintaining complex applications across tens to hundreds of developers.
- boltefnovor 6y ago
  You are correct and I agree with you. I have not worked in big projects, only small, so that’s where my beliefs come from. I feel the problem is a software problem that should be solved by better development tools/languages rather than throwing up hands and pushing the problem into the operations domain.
- Retric 6y ago
  Tens to low hundreds possibly, but micro services can make things much worse as you scale to thousands of developers. The ultimate limit of any design is how much any one person can understand both from both a complexity standpoint and a rate off change standpoint. It’s the same issue that pushed people from goto > functions > libraries > ... Eventually you need another layer of abstraction. For very large companies doing mergers etc things are always going to be in flux in ways that the startup world tends to ignore.
andy_ppp 6y ago
But the idea that interacting services can be built by different teams isn’t just dev ops complexity, it’s insanely complex managing that stuff because it involves humans. Never mind that everyone building micro services just goes “fuck transactions and eventual consistency, I’ll go with maybe/probably my data gets corrupted over time” whoop.
- deleted 6y ago
  [deleted]
- marcinzm 6y ago
  It doesn't matter if it's multiple services or one monolith, once you have multiple teams on one product the complexity is already there. The argument is that microservices force it to be visible and dealt with while monoliths hide it until you blow your feet off.
  - dragonwriter 6y ago
    Particularly, IMO, for internal business apps, microservices make it more likely that you can align products, business owners, and teams, whereas monoliths force complicated governance as well as multiteam products. And, in practice, the development teams and business owners aren't aligned, so you get a many-to-many web of requirements and approvals communication.
  - andy_ppp 6y ago
    Who said anything about one monolith? I believe much more in starting with one service and splitting it when it becomes absolutely torture to work with... Make as few services as you can possibly handle and make absolute guarantees between them in terms of data consistency. This is basically what the article suggests in detail, but I assume you disagree with it? Bounded contexts DO NOT need network partitions to be enforced BTW. For example, I'm pretty sure Google has all their source code in a single repo (or at least a LOT), how do they with a million developers stop people from intertwining everything? My guess is code reviews, hiring good people and tooling. EDIT: sorry to the person who liked it I've rewritten this comment for clarity, and removed lots of words...
    - marcinzm 6y ago
      Very very few companies are actually like Google to the point where I'd say making an argument that assumes you are like Google is a fallacy. When you have a near infinite stream of ad money to pay developers million dollar salaries then amazing things are possible.
kinkrtyavimoodh 6y ago
1000 people working on the same code base is human complexity too.
- winrid 6y ago
  So is 1000 people trying to coordinate package versions and interface changes across 100 systems (throw in loosely typed languages for extra fun).
  - robertlagrant 6y ago
    That assumes all services talk to all other services directly. a) they probably don't, and b) message busses can help a lot.
  - dodobirdlord 6y ago
    APIs shouldn't change in backward-incompatible ways. That's sorta the bedrock of a service oriented architecture. If teams have to communicate with each other through more than API documentation and can push responsibilities onto each other by making backwards-incompatible changes then you've kneecapped the entire benefit of a service oriented architecture from the get-go.
    - winrid 6y ago
      I'm not talking about backwards compatibility so much as adding features in parallel that span many services, which happens when you're closing a lot of sales deals when the salespeople don't say no to things :p
anonacct38 6y ago
I've seen both extremes. For instance I'm told github largely has a rails monolith and that they have to run headless instances of rails to do database leader election (although this statement implies they are trying to break things out). I've also talked to junior engineers who want to make every function call a pubsub message. I've heard principals from Amazon promote a model where one service is responsible for one entity. What I've decided is that the services in your company should follow conway's law. Most of the problems with a monolith come when multiple teams with differing release cycles and requirements are making changes in a shared codebase and they are having trouble keeping their tree green. You should generally have one to a few services per team. Scoping a service to a team ensures that people can have true ownership. For SREs microservices are harder, but they give SREs the control plane they need to do a good job. If communication happens between services rather than function calls, it's easier to instrument all services in a common way and build dashboards. It's simpler to spin up different instances connected to different datasources.
- chucknthem 6y ago
  This is the first time I've heard of Conway's law used in a positive or at least non-negative way.
  - mirekrusin 6y ago
    I don't think I ever read mention of conway's law as having positive or negative connotation.
    - Aeolun 6y ago
      The law itself is fine, it’s just that the organisation of most companies is abysmal, so your software is too.
  - nafey 6y ago
    In case of rewriting the codebase it actually makes sense. Your organisation already has a codebase and complementary org structure. Any microservices rewrite should be tailored to the existing boundaries of teams for maximum effectiveness.
nullsense 6y ago
I think whether that's the case is largely dependent on implementation. It could increase or decrease software complexity. It could also increase or decrease devops complexity.

tmotwu 6y ago

Sure, if you are independently building your service, or working a tight feedback loop with others on the product. As others pointed out, it works for companies who operate and scale engineering teams. Good luck maintaining complex applications across tens to hundreds of developers.

boltefnovor 6y ago
You are correct and I agree with you. I have not worked in big projects, only small, so that’s where my beliefs come from. I feel the problem is a software problem that should be solved by better development tools/languages rather than throwing up hands and pushing the problem into the operations domain.
Retric 6y ago
Tens to low hundreds possibly, but micro services can make things much worse as you scale to thousands of developers. The ultimate limit of any design is how much any one person can understand both from both a complexity standpoint and a rate off change standpoint. It’s the same issue that pushed people from goto > functions > libraries > ... Eventually you need another layer of abstraction. For very large companies doing mergers etc things are always going to be in flux in ways that the startup world tends to ignore.

andy_ppp 6y ago

But the idea that interacting services can be built by different teams isn’t just dev ops complexity, it’s insanely complex managing that stuff because it involves humans. Never mind that everyone building micro services just goes “fuck transactions and eventual consistency, I’ll go with maybe/probably my data gets corrupted over time” whoop.

deleted 6y ago
[deleted]
marcinzm 6y ago
It doesn't matter if it's multiple services or one monolith, once you have multiple teams on one product the complexity is already there. The argument is that microservices force it to be visible and dealt with while monoliths hide it until you blow your feet off.
- dragonwriter 6y ago
  Particularly, IMO, for internal business apps, microservices make it more likely that you can align products, business owners, and teams, whereas monoliths force complicated governance as well as multiteam products. And, in practice, the development teams and business owners aren't aligned, so you get a many-to-many web of requirements and approvals communication.
- andy_ppp 6y ago
  Who said anything about one monolith? I believe much more in starting with one service and splitting it when it becomes absolutely torture to work with... Make as few services as you can possibly handle and make absolute guarantees between them in terms of data consistency. This is basically what the article suggests in detail, but I assume you disagree with it? Bounded contexts DO NOT need network partitions to be enforced BTW. For example, I'm pretty sure Google has all their source code in a single repo (or at least a LOT), how do they with a million developers stop people from intertwining everything? My guess is code reviews, hiring good people and tooling. EDIT: sorry to the person who liked it I've rewritten this comment for clarity, and removed lots of words...
  - marcinzm 6y ago
    Very very few companies are actually like Google to the point where I'd say making an argument that assumes you are like Google is a fallacy. When you have a near infinite stream of ad money to pay developers million dollar salaries then amazing things are possible.

kinkrtyavimoodh 6y ago

1000 people working on the same code base is human complexity too.

winrid 6y ago
So is 1000 people trying to coordinate package versions and interface changes across 100 systems (throw in loosely typed languages for extra fun).
- robertlagrant 6y ago
  That assumes all services talk to all other services directly. a) they probably don't, and b) message busses can help a lot.
- dodobirdlord 6y ago
  APIs shouldn't change in backward-incompatible ways. That's sorta the bedrock of a service oriented architecture. If teams have to communicate with each other through more than API documentation and can push responsibilities onto each other by making backwards-incompatible changes then you've kneecapped the entire benefit of a service oriented architecture from the get-go.
  - winrid 6y ago
    I'm not talking about backwards compatibility so much as adding features in parallel that span many services, which happens when you're closing a lot of sales deals when the salespeople don't say no to things :p

anonacct38 6y ago

I've seen both extremes. For instance I'm told github largely has a rails monolith and that they have to run headless instances of rails to do database leader election (although this statement implies they are trying to break things out). I've also talked to junior engineers who want to make every function call a pubsub message. I've heard principals from Amazon promote a model where one service is responsible for one entity. What I've decided is that the services in your company should follow conway's law. Most of the problems with a monolith come when multiple teams with differing release cycles and requirements are making changes in a shared codebase and they are having trouble keeping their tree green. You should generally have one to a few services per team. Scoping a service to a team ensures that people can have true ownership. For SREs microservices are harder, but they give SREs the control plane they need to do a good job. If communication happens between services rather than function calls, it's easier to instrument all services in a common way and build dashboards. It's simpler to spin up different instances connected to different datasources.

chucknthem 6y ago
This is the first time I've heard of Conway's law used in a positive or at least non-negative way.
- mirekrusin 6y ago
  I don't think I ever read mention of conway's law as having positive or negative connotation.
  - Aeolun 6y ago
    The law itself is fine, it’s just that the organisation of most companies is abysmal, so your software is too.
- nafey 6y ago
  In case of rewriting the codebase it actually makes sense. Your organisation already has a codebase and complementary org structure. Any microservices rewrite should be tailored to the existing boundaries of teams for maximum effectiveness.

nullsense 6y ago

I think whether that's the case is largely dependent on implementation. It could increase or decrease software complexity. It could also increase or decrease devops complexity.