5 ms·

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

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.
- wsy 8y ago
  It's a bit like asking to replace medical doctors with science and theory. We need science and theory, and skilled architects who can apply it to the problem at hand.
  - crimsonalucard 8y ago
    The practices of Doctors are based off of science and theory. Design patterns and microservices while technical are not based off of science. They are ideas without quantitiative basis or science.
    - agentultra 8y ago
      Model checking is based off of mathematics and can be verified or, with some elbow grease, proven. I'll take a TLA+ specification over a diagram any day.
      - crimsonalucard 8y ago
        What do you mean by model checking? Usually anything with the keyword "Design" like design patterns for microservices have no science or mathematics to back it up.
        eitally 8y ago
        You may be technically correct, but I'd argue it's generally more useful what we do have: practical experience. When one says "we need better architects", to me that implies that our current architects are creating design patterns and reference implementations that are both 1) not practical, and 2) don't adhere to known-good best practices. Systems design in real life is an "artistic science": there are always known limitations (and some expected unknown ones) that rule out the theoretic optimal design for good reasons. The problem is that limitations and compromises are often not disclosed, and that many programmers and architects are too inexperienced to really grok the implicit meaning behind specific design decisions. So we struggle along, with bloggers, researchers and FOSS contributors halfheartedly collaborating to make point improvements as solutions are discovered. Stodgy enterprises suffer, big tech companies make decisions with global impact, startups are left wondering WTF to do, and the rest of us largely don't care. Why? Because nit picking doesn't solve business problems [almost ever. I'd argue this point in cases of things like SCADA systems and other mission critical control systems.].
mikekchar 8y ago
> ... the fundamental problem was centered around a shared architecture of destinations and shared code. From an architectural perspective, there is absolutely no difference between a micro service and a library. The only real difference is in the dispatch mechanism. The problems around configuration management are the same problems we've had as programmers for decades. It's just that the people who are keen on micro services are usually not old enough to have experienced the pain in a different context. Should shared libraries be in different repos, or should you put everything in a single repo? How do you deal with versioning? What happens if one app wants version 1 of the library and another app wants version 2? How do you deal with backwards compatibility of the API? Do you make a whole new library when you decide the old API is incompatible with the new vision? Blah, blah, blah, blah. None of this is a new problem. I can't remember which version of Windows it was (maybe 7?) where they were seriously delayed mainly because they had so many programs using different versions of libraries. Integrating it at the end was apparently complete hell. Since they wanted to have separation of responsibility in their groups, each group was just pounding away implementing the features that they needed, but not integrating as they went -- because that would mean lots of cross team communication. The exact same thing is likely in a large organisation with a ton of micro services. There isn't just one way to solve the problem. Mono repos and monoliths help in certain ways and cause problems in other ways. There are other techniques as well (should we implement ld.so for micro services? :-) ) But as you mention, the real answer is that the solution requires humans, not technology.
- robotresearcher 8y ago
  > From an architectural perspective, there is absolutely no difference between a micro service and a library. I’ll stick to linking glibc, friend architect. Performance is also architecture.
- weberc2 8y ago
  Microservices do have various organizational tradeoffs. Individual teams can now own deployment, operation, language, and tooling choices for better or worse. This is probably advantageous for large companies where the number of teams scales beyond what a hierarchical control structure can support. In other words, a single devops team can't make good decisions and prescriptions about languages, tooling, deployment, etc nor effectively react to feedback from the dev teams. Control (power and responsibility) becomes distributed instead of centralized, with all the tradeoffs that entails.
JonasJSchreiber 8y ago
Yes, couldn't agree more. The O in SOLID should be adhered to in this case. Open for extension, closed for modification

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.
wsy 8y ago
It's a bit like asking to replace medical doctors with science and theory. We need science and theory, and skilled architects who can apply it to the problem at hand.
- crimsonalucard 8y ago
  The practices of Doctors are based off of science and theory. Design patterns and microservices while technical are not based off of science. They are ideas without quantitiative basis or science.
  - agentultra 8y ago
    Model checking is based off of mathematics and can be verified or, with some elbow grease, proven. I'll take a TLA+ specification over a diagram any day.
    - crimsonalucard 8y ago
      What do you mean by model checking? Usually anything with the keyword "Design" like design patterns for microservices have no science or mathematics to back it up.
      - eitally 8y ago
        You may be technically correct, but I'd argue it's generally more useful what we do have: practical experience. When one says "we need better architects", to me that implies that our current architects are creating design patterns and reference implementations that are both 1) not practical, and 2) don't adhere to known-good best practices. Systems design in real life is an "artistic science": there are always known limitations (and some expected unknown ones) that rule out the theoretic optimal design for good reasons. The problem is that limitations and compromises are often not disclosed, and that many programmers and architects are too inexperienced to really grok the implicit meaning behind specific design decisions. So we struggle along, with bloggers, researchers and FOSS contributors halfheartedly collaborating to make point improvements as solutions are discovered. Stodgy enterprises suffer, big tech companies make decisions with global impact, startups are left wondering WTF to do, and the rest of us largely don't care. Why? Because nit picking doesn't solve business problems [almost ever. I'd argue this point in cases of things like SCADA systems and other mission critical control systems.].

mikekchar 8y ago

> ... the fundamental problem was centered around a shared architecture of destinations and shared code. From an architectural perspective, there is absolutely no difference between a micro service and a library. The only real difference is in the dispatch mechanism. The problems around configuration management are the same problems we've had as programmers for decades. It's just that the people who are keen on micro services are usually not old enough to have experienced the pain in a different context. Should shared libraries be in different repos, or should you put everything in a single repo? How do you deal with versioning? What happens if one app wants version 1 of the library and another app wants version 2? How do you deal with backwards compatibility of the API? Do you make a whole new library when you decide the old API is incompatible with the new vision? Blah, blah, blah, blah. None of this is a new problem. I can't remember which version of Windows it was (maybe 7?) where they were seriously delayed mainly because they had so many programs using different versions of libraries. Integrating it at the end was apparently complete hell. Since they wanted to have separation of responsibility in their groups, each group was just pounding away implementing the features that they needed, but not integrating as they went -- because that would mean lots of cross team communication. The exact same thing is likely in a large organisation with a ton of micro services. There isn't just one way to solve the problem. Mono repos and monoliths help in certain ways and cause problems in other ways. There are other techniques as well (should we implement ld.so for micro services? :-) ) But as you mention, the real answer is that the solution requires humans, not technology.

robotresearcher 8y ago
> From an architectural perspective, there is absolutely no difference between a micro service and a library. I’ll stick to linking glibc, friend architect. Performance is also architecture.
weberc2 8y ago
Microservices do have various organizational tradeoffs. Individual teams can now own deployment, operation, language, and tooling choices for better or worse. This is probably advantageous for large companies where the number of teams scales beyond what a hierarchical control structure can support. In other words, a single devops team can't make good decisions and prescriptions about languages, tooling, deployment, etc nor effectively react to feedback from the dev teams. Control (power and responsibility) becomes distributed instead of centralized, with all the tradeoffs that entails.

JonasJSchreiber 8y ago

Yes, couldn't agree more. The O in SOLID should be adhered to in this case. Open for extension, closed for modification