6 ms·

I'd wager that microservices, a lot of the time, are basically used as a management structure rather than for their benefits as pure tech, so less mature teams

by ljm 8y ago

I'd wager that microservices, a lot of the time, are basically used as a management structure rather than for their benefits as pure tech, so less mature teams can silo themselves off and avoid communication (e.g. "I can work just on my backend image processing bit without dealing with the React guys now", "now the CTO won't be on my back so much," or whatever). The irony being that anything approaching SOA (or microservices) requires exactly the same amount of communication. More likely they require more since it's almost certain that such a decision introduced chaos.

stcredzero 8y ago
I'd wager that microservices, a lot of the time, are basically used as a management structure rather than for their benefits as pure tech A lot of software is used to control or impose someone's will on others organizationally.
- johndubchak 8y ago
  Very well said.
- flukus 8y ago
  This is why things like ticketing systems and other workflow tools almost universally suck. Manager needs x field to run some report so x field becomes mandatory and the software is a pain to use because know one apart from that one manager knows what the field even means. Currently our JIRA kanban board is crippled because someone just had to take a simple system and impose a workflow that can't be deviated from.
organsnyder 8y ago
I agree, though I'm not so cynical about it. Well-defined API contracts are themselves a communication mechanism. If I provide an API, I am declaring that if you interact with me in a given way, I will behave in a certain way. Given that one of the hardest parts of scaling an organization is the boundaries between individuals and teams, providing a structured mechanism to define system behavior is incredibly valuable. Well-written APIs are SLAs on steroids.
- foobarian 8y ago
  I hated that in our monolith Java web app, any random team could come along and pepper our team's module with global variable lookups and short term hacks that never get cleaned up. Even though we see the changes often times they are urgent changes needed right now, accompanied with promises to clean up later (which usually doesn't happen). The nice thing about a SOA architecture is that it makes it harder to do this kind of cowboy programming. Yes maybe some quick business wins are harder than in a monolith, but I think (at least in our org) the cleaner architecture pays off by letting us move quicker on a different class of product projects since there is less technical debt.
  - p2t2p 8y ago
    I had enough of this stuff in my case so I locked repo down so only members of a team can merge PRs and no one can merge anything without a PR.
  - DCoder 8y ago
    Isn't that a technical solution to an organizational problem?
    - organsnyder 8y ago
      Yes. And that's okay, sometimes. To me, the difference is whether it's an organizational challenge or an organizational dysfunction. There will always be challenges inherent to operating a business—and technical solutions often play a critical part. However, if the issue is really an organizational malady that should be addressed, technical solutions probably aren't the right approach.
johndubchak 8y ago
I think what was missed, in the article, is that the fundamental problem was centered around a shared architecture of destinations and shared code. You cannot possibly have every destination be a separate repo and then have the development lifecycle of your shared code be so active that it ultimately puts at risk the architecture of your entire organization. What makes shared code so perfect is having stability such that you extract your variant code into your non-shared code. Shared code should evolve at a much slower pace than your non-shared code or you risk this very outcome. Microservices are not dead, nor are they the solution to everything. We need better architects.
- crimsonalucard 8y ago
  No we need science and theory to definitively define necessary architectures that are appropriate to certain use cases. An architect is just a another man with an opinion.
  - johndubchak 8y ago
    We have these things. A better architect implies that one is trained in analyzing and producing these architectures using the science she/he was trained with: https://www.sei.cmu.edu/education-outreach/credentials/credential.cfm?customel_datapageid_14047=15203 https://www.sei.cmu.edu/education-outreach/credentials/crede... The certificate means nothing, the training and instruction is priceless. Add to that things like TOGAF and a deep understanding of the current state of existing architectures and you'll understand what I originally meant, but failed to explain. UPDATE: misspelled "meant"
    - crimsonalucard 8y ago
      That's not science or proof. Thats a course on design. By science and proof I mean like definitive logic. a^2 + b^2 = c^2
    - crimsonalucard 8y ago
      The closest mathematical formal system I've seen that dictates architecture is category theory. But even this system doesn't say anything about being "better" or more efficient than another design pattern.
philwelch 8y ago
I would flip this argument around 180 degrees. Once you have any system that's built by large numbers of people, you have to discuss and negotiate your interfaces. You can either do this implicitly, by having a shared codebase and making sure that your test coverage and code reviews guarantee backwards compatibility, or explicitly, by defining service interfaces and black-boxing behind them.
tetha 8y ago
Yeah. We're currently in a second push to introduce microservices and this time I'm on board. The first time was more about enforcing code ownership and such, and that was going to be a mess. Now, people are pondering things like: Ok, management of elasticsearch has performance issues and it's a general pain if the elasticsearch documents change. So let's try to move the schema of elasticsearch documents into a strictly semver'd artifact. And let's move management of our search indexes into a service depending on that artifact, so the schema changes in a controlled way. And ops and the search team can scale and optimize the service as they need to minimize search outages. Creating smaller services based on problems is a good thing. Creating smaller services because of ... reasons... not so much.
gaius 8y ago
I'd wager that microservices, a lot of the time, are basically used as a management structure Conway’s Law in action, or in reverse https://en.wikipedia.org/wiki/Conway's_law https://en.wikipedia.org/wiki/Conway's_law

by ljm 8y ago

stcredzero 8y ago

I'd wager that microservices, a lot of the time, are basically used as a management structure rather than for their benefits as pure tech A lot of software is used to control or impose someone's will on others organizationally.

johndubchak 8y ago
Very well said.
flukus 8y ago
This is why things like ticketing systems and other workflow tools almost universally suck. Manager needs x field to run some report so x field becomes mandatory and the software is a pain to use because know one apart from that one manager knows what the field even means. Currently our JIRA kanban board is crippled because someone just had to take a simple system and impose a workflow that can't be deviated from.

organsnyder 8y ago

I agree, though I'm not so cynical about it. Well-defined API contracts are themselves a communication mechanism. If I provide an API, I am declaring that if you interact with me in a given way, I will behave in a certain way. Given that one of the hardest parts of scaling an organization is the boundaries between individuals and teams, providing a structured mechanism to define system behavior is incredibly valuable. Well-written APIs are SLAs on steroids.

foobarian 8y ago
I hated that in our monolith Java web app, any random team could come along and pepper our team's module with global variable lookups and short term hacks that never get cleaned up. Even though we see the changes often times they are urgent changes needed right now, accompanied with promises to clean up later (which usually doesn't happen). The nice thing about a SOA architecture is that it makes it harder to do this kind of cowboy programming. Yes maybe some quick business wins are harder than in a monolith, but I think (at least in our org) the cleaner architecture pays off by letting us move quicker on a different class of product projects since there is less technical debt.
- p2t2p 8y ago
  I had enough of this stuff in my case so I locked repo down so only members of a team can merge PRs and no one can merge anything without a PR.
- DCoder 8y ago
  Isn't that a technical solution to an organizational problem?
  - organsnyder 8y ago
    Yes. And that's okay, sometimes. To me, the difference is whether it's an organizational challenge or an organizational dysfunction. There will always be challenges inherent to operating a business—and technical solutions often play a critical part. However, if the issue is really an organizational malady that should be addressed, technical solutions probably aren't the right approach.

johndubchak 8y ago

I think what was missed, in the article, is that the fundamental problem was centered around a shared architecture of destinations and shared code. You cannot possibly have every destination be a separate repo and then have the development lifecycle of your shared code be so active that it ultimately puts at risk the architecture of your entire organization. What makes shared code so perfect is having stability such that you extract your variant code into your non-shared code. Shared code should evolve at a much slower pace than your non-shared code or you risk this very outcome. Microservices are not dead, nor are they the solution to everything. We need better architects.

crimsonalucard 8y ago
No we need science and theory to definitively define necessary architectures that are appropriate to certain use cases. An architect is just a another man with an opinion.
- johndubchak 8y ago
  We have these things. A better architect implies that one is trained in analyzing and producing these architectures using the science she/he was trained with: https://www.sei.cmu.edu/education-outreach/credentials/credential.cfm?customel_datapageid_14047=15203 https://www.sei.cmu.edu/education-outreach/credentials/crede... The certificate means nothing, the training and instruction is priceless. Add to that things like TOGAF and a deep understanding of the current state of existing architectures and you'll understand what I originally meant, but failed to explain. UPDATE: misspelled "meant"
  - crimsonalucard 8y ago
    That's not science or proof. Thats a course on design. By science and proof I mean like definitive logic. a^2 + b^2 = c^2
  - crimsonalucard 8y ago
    The closest mathematical formal system I've seen that dictates architecture is category theory. But even this system doesn't say anything about being "better" or more efficient than another design pattern.

philwelch 8y ago

I would flip this argument around 180 degrees. Once you have any system that's built by large numbers of people, you have to discuss and negotiate your interfaces. You can either do this implicitly, by having a shared codebase and making sure that your test coverage and code reviews guarantee backwards compatibility, or explicitly, by defining service interfaces and black-boxing behind them.

tetha 8y ago

Yeah. We're currently in a second push to introduce microservices and this time I'm on board. The first time was more about enforcing code ownership and such, and that was going to be a mess. Now, people are pondering things like: Ok, management of elasticsearch has performance issues and it's a general pain if the elasticsearch documents change. So let's try to move the schema of elasticsearch documents into a strictly semver'd artifact. And let's move management of our search indexes into a service depending on that artifact, so the schema changes in a controlled way. And ops and the search team can scale and optimize the service as they need to minimize search outages. Creating smaller services based on problems is a good thing. Creating smaller services because of ... reasons... not so much.

gaius 8y ago

I'd wager that microservices, a lot of the time, are basically used as a management structure Conway’s Law in action, or in reverse https://en.wikipedia.org/wiki/Conway's_law https://en.wikipedia.org/wiki/Conway's_law