4 ms·

I feel like if you're building them brittle, you're building them wrong. I had the pleasure of watching Sam Newman's tutorial on microservices. He's uploaded

I feel like if you're building them brittle, you're building them wrong. I had the pleasure of watching Sam Newman's tutorial on microservices. He's uploaded the slides here: http://t.co/2nhDBJK1oB http://t.co/2nhDBJK1oB Building microservices requires a few changes in culture. If you are moving from a monolith to microservices, your entire culture must change how you look at problems must change and if you fail to do those things, of course your transition will change. It is not a silver bullet. It is a paradigm shift.

crdoconnor 11y ago
The more people use the phrases 'paradigm shift', 'culture change' and 'I feel like" and the less people give actual hard-nosed technical justification for this new architectural mold, the more convinced I become that it is a transient fashion that needs to die already.
- duaneb 11y ago
  > technical justification for this new architectural mold The technical justification is easier than the cultural or managerial justification: you can make more granular technical decisions by splitting and merging code across services and servers. This is very powerful. Microservices aren't going away—they are the core of a successful, scalable distributed system. The hype surrounding the term is definitely loaded with cultural and managerial implications that are rarely addressed, however, and I hope that changes soon.
  - crdoconnor 11y ago
    >you can make more granular technical decisions by splitting and merging code across services "granular technical decisions" -- can you please give an example of a 'granular' technical decision? >Microservices aren't going away—they are the core of a successful, scalable distributed system. It would be more accurate to say that microservices is what you call a system that you made distributed even though you didn't actually have to make it distributed.
    - duaneb 11y ago
      > can you please give an example of a 'granular' technical decision? Whether or not to upgrade an underlying library for a service. How many nodes to give a cluster, what features to prioritize on that node. You can do this with a monolithic codebase but you move slowwww if upgrading one unit implies upgrading others. With microservices, you could even write every service in an entirely different language. > It would be more accurate to say that microservices is what you call a system that you made distributed even though you didn't actually have to make it distributed. You don't have to make anything distributed. I think it's more apt to draw an analogy to the Actor paradigm—microserves are discrete actors in a distributed system and can be analyzed independently from the other actors. All the microservices movement has really brought to the table is "no, you don't need to distribute your work to benefit from the looser coupling". If you're seeing anything more, I suspect there would be significant disagreement in the movement about it.
      - crdoconnor 11y ago
        >Whether or not to upgrade an underlying library for a service. How many nodes to give a cluster, what features to prioritize on that node. You can do this with a monolithic codebase Right. And it's no harder, either. >you move slowwww if upgrading one unit implies upgrading others. Absolutely not. You don't have to have microservices to have a set of loosely coupled libraries. A reliable automated test suite is what is going to make library upgrades less painful for you, not 1,000 new, brittle serialization/deserialization layers. >With microservices, you could even write every service in an entirely different language. Really, really bad idea. Debugging a call stack is an order of magnitude easier than tracing a failure across a set of multiple services which is an order of magnitude easier than tracing a failure across a set of services written in different languages. >You don't have to make anything distributed. Some systems do have to be distributed for the ability to call on more resources than one machine can realistically provide, to deal with the inherent unreliability of individual servers, or (sometimes) for legal reasons. There are a great number of problems that you create for yourself if you do this, though, which is why avoiding it where possible and minimizing the pain of doing it is the architecturally sane thing to do. "Microservices" is the 'paradigm' that you should create this headaches for yourself because Martin Fowler Told You To and because the idea that separation of concerns and loosely coupled libraries won't happen unless you do the technical equivalent of self-flagellation. The unfortunate reality is that it is just as easy to write tightly coupled code with microservices, it just creates a bigger headache for you when you do. >All the microservices movement has really brought to the table is "no, you don't need to distribute your work to benefit from the looser coupling". It seems to me that the microservices movement implies the direct opposite of this.
- crashoverdrive 11y ago
  Okay then. Let's play the "hard nosed technical justification" for this new architectural mold. Specifically pointed at your issues. > The serialization/deserialization layer adds potential for bugs. Adding an agreed upon layer that aligns with clean architecture[0) will actually produce less bugs both upstream and downstream. (This is why contract apis are important) and are actually more valuable than monolithic systems where there is a sincere lack of data and state guarantees. (clean understanding vs black box mentality) > The massively increased number of services all need constant monitoring. It's the same amount of monitoring. It's just horizontally scaled and is actually easier to pinpoint issues. This also allows you the ability to change or create circuit breakers to fail over when issues targeting specific are found. (see slides 134-150 of Sam Newman's principles of microservices [1]) > The massively multiplied error conditions (what happens when service 37 talks to 39 and 39 times out?) need to be accounted for and those edge cases must be ironed out. They should have been "ironed out" well before this point to begin with. If the application fails due to infrastructure issues, it is actually an application design failure that should have been identified and resolved previously via TDD and failure state testing. Graceful failure is always desirable, and having a legacy monolithic application does not prevent infrastructure/connectivity failures. (for reference, check out Martin Fowler's "The 12 Factor App" [2]) > You get fuck all except migraines caused by the brittleness of your app. What it sounds like you're saying is: "Building a monolithic app allows you to crutch bad behavior and poor design without having to understand the realities of software. You can ignore scalability, clean architecture, concurrency, data modeling and graceful failures." I can understand how moving to a microservice could seem very painful and have a brittle result without the depth of understanding these realities. This is specifically why I noted it is a required paradigm shift for many developers. For more inspired reading, you may want to checkout Gilt's discussions on moving to microservices.[3] [0] http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-arch... [1] http://www.slideshare.net/spnewman/principles-of-microservices-velocity http://www.slideshare.net/spnewman/principles-of-microservic... [2] http://12factor.net/ http://12factor.net/ [3] http://tech.gilt.com/post/102628539834/making-architecture-work-in-microservice http://tech.gilt.com/post/102628539834/making-architecture-w...
  - matwood 11y ago
- pc86 11y ago
  This comment is identical to "I feel like it" except it's essentially just "I don't like micro-services." Your earlier comment did not provide any "hard-nosed technical justification" for why you don't like them, it was just "they're brittle" which the GP is arguing that if they are they're not implemented correctly. What is the hard-nosed technical justification for either microservices being brittle by default or for them not being a realistic way to build a system?
  - crdoconnor 11y ago
    >Your earlier comment did not provide any "hard-nosed technical justification" for why you don't like them, it was just "they're brittle" I gave three reasons. Did you not read them?

crdoconnor 11y ago

The more people use the phrases 'paradigm shift', 'culture change' and 'I feel like" and the less people give actual hard-nosed technical justification for this new architectural mold, the more convinced I become that it is a transient fashion that needs to die already.

duaneb 11y ago
> technical justification for this new architectural mold The technical justification is easier than the cultural or managerial justification: you can make more granular technical decisions by splitting and merging code across services and servers. This is very powerful. Microservices aren't going away—they are the core of a successful, scalable distributed system. The hype surrounding the term is definitely loaded with cultural and managerial implications that are rarely addressed, however, and I hope that changes soon.
- crdoconnor 11y ago
  >you can make more granular technical decisions by splitting and merging code across services "granular technical decisions" -- can you please give an example of a 'granular' technical decision? >Microservices aren't going away—they are the core of a successful, scalable distributed system. It would be more accurate to say that microservices is what you call a system that you made distributed even though you didn't actually have to make it distributed.
  - duaneb 11y ago
    > can you please give an example of a 'granular' technical decision? Whether or not to upgrade an underlying library for a service. How many nodes to give a cluster, what features to prioritize on that node. You can do this with a monolithic codebase but you move slowwww if upgrading one unit implies upgrading others. With microservices, you could even write every service in an entirely different language. > It would be more accurate to say that microservices is what you call a system that you made distributed even though you didn't actually have to make it distributed. You don't have to make anything distributed. I think it's more apt to draw an analogy to the Actor paradigm—microserves are discrete actors in a distributed system and can be analyzed independently from the other actors. All the microservices movement has really brought to the table is "no, you don't need to distribute your work to benefit from the looser coupling". If you're seeing anything more, I suspect there would be significant disagreement in the movement about it.
    - crdoconnor 11y ago
      >Whether or not to upgrade an underlying library for a service. How many nodes to give a cluster, what features to prioritize on that node. You can do this with a monolithic codebase Right. And it's no harder, either. >you move slowwww if upgrading one unit implies upgrading others. Absolutely not. You don't have to have microservices to have a set of loosely coupled libraries. A reliable automated test suite is what is going to make library upgrades less painful for you, not 1,000 new, brittle serialization/deserialization layers. >With microservices, you could even write every service in an entirely different language. Really, really bad idea. Debugging a call stack is an order of magnitude easier than tracing a failure across a set of multiple services which is an order of magnitude easier than tracing a failure across a set of services written in different languages. >You don't have to make anything distributed. Some systems do have to be distributed for the ability to call on more resources than one machine can realistically provide, to deal with the inherent unreliability of individual servers, or (sometimes) for legal reasons. There are a great number of problems that you create for yourself if you do this, though, which is why avoiding it where possible and minimizing the pain of doing it is the architecturally sane thing to do. "Microservices" is the 'paradigm' that you should create this headaches for yourself because Martin Fowler Told You To and because the idea that separation of concerns and loosely coupled libraries won't happen unless you do the technical equivalent of self-flagellation. The unfortunate reality is that it is just as easy to write tightly coupled code with microservices, it just creates a bigger headache for you when you do. >All the microservices movement has really brought to the table is "no, you don't need to distribute your work to benefit from the looser coupling". It seems to me that the microservices movement implies the direct opposite of this.
crashoverdrive 11y ago
Okay then. Let's play the "hard nosed technical justification" for this new architectural mold. Specifically pointed at your issues. > The serialization/deserialization layer adds potential for bugs. Adding an agreed upon layer that aligns with clean architecture[0) will actually produce less bugs both upstream and downstream. (This is why contract apis are important) and are actually more valuable than monolithic systems where there is a sincere lack of data and state guarantees. (clean understanding vs black box mentality) > The massively increased number of services all need constant monitoring. It's the same amount of monitoring. It's just horizontally scaled and is actually easier to pinpoint issues. This also allows you the ability to change or create circuit breakers to fail over when issues targeting specific are found. (see slides 134-150 of Sam Newman's principles of microservices [1]) > The massively multiplied error conditions (what happens when service 37 talks to 39 and 39 times out?) need to be accounted for and those edge cases must be ironed out. They should have been "ironed out" well before this point to begin with. If the application fails due to infrastructure issues, it is actually an application design failure that should have been identified and resolved previously via TDD and failure state testing. Graceful failure is always desirable, and having a legacy monolithic application does not prevent infrastructure/connectivity failures. (for reference, check out Martin Fowler's "The 12 Factor App" [2]) > You get fuck all except migraines caused by the brittleness of your app. What it sounds like you're saying is: "Building a monolithic app allows you to crutch bad behavior and poor design without having to understand the realities of software. You can ignore scalability, clean architecture, concurrency, data modeling and graceful failures." I can understand how moving to a microservice could seem very painful and have a brittle result without the depth of understanding these realities. This is specifically why I noted it is a required paradigm shift for many developers. For more inspired reading, you may want to checkout Gilt's discussions on moving to microservices.[3] [0] http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-arch... [1] http://www.slideshare.net/spnewman/principles-of-microservices-velocity http://www.slideshare.net/spnewman/principles-of-microservic... [2] http://12factor.net/ http://12factor.net/ [3] http://tech.gilt.com/post/102628539834/making-architecture-work-in-microservice http://tech.gilt.com/post/102628539834/making-architecture-w...
- matwood 11y ago
pc86 11y ago
This comment is identical to "I feel like it" except it's essentially just "I don't like micro-services." Your earlier comment did not provide any "hard-nosed technical justification" for why you don't like them, it was just "they're brittle" which the GP is arguing that if they are they're not implemented correctly. What is the hard-nosed technical justification for either microservices being brittle by default or for them not being a realistic way to build a system?
- crdoconnor 11y ago
  >Your earlier comment did not provide any "hard-nosed technical justification" for why you don't like them, it was just "they're brittle" I gave three reasons. Did you not read them?