4 ms·

Another aspect to consider is, time taken to run regression and automation tests on the Monolith, by both devs & QAs. This affects frequent release of software

Another aspect to consider is, time taken to run regression and automation tests on the Monolith, by both devs & QAs. This affects frequent release of software considerably l.

icebraining 10y ago
That's because you're testing the monolith end-to-end, but testing the microservices individually. None of this is inevitable: you should still test the microservice network as a whole, and you can definitively test the components of a monolith individually.
- sriram_iyengar 10y ago
  Agree that the functionality needs to be tested in-whole. But the delta in time is very large when the feature level tests have to be run on the monolith & they can be avoided when they are tested on the micro service.
  - ProblemFactory 10y ago
    But where does the difference come from? A "well-designed monolith's" code architecture would be very similar to microservices - with separated modules, but in-process function calls instead of remote API calls. If you do large-scale integration tests that cross module boundaries in the monolith, then you should also have the same tests of the full deployment with microservices. If you test each microservice independently, then you could also run tests for each module independently.
    - sokoloff 10y ago
      My experience (sample size of 1) is that long-lived monoliths tend not to evolve along "well-designed" lines, but rather along "what can I possibly do to get this to work in the time I have?" lines. Further, it's an impossible hurdle to schedule big dig to make substantial architectural improvements on a large monolith, so refactorings and improvements tend to be shallow and localized. A decade later, and you have a lot of business logic in stored procedures in your database and now hear grumbling from coders who don't know or don't want to learn SQL. (And, to be fair, it does make it harder to scale the engineering team if everyone needs to be proficient at SQL.) Neither availability nor technical scaling concerns were the reason we started to transition away from our monolith. We were regularly hitting 4 nines of availability (measured by "orders coming in") and had scaled to well over $1BB in revenue essentially on a single database for most of the site functionality. Above average engineers and ops, and way above average DBA team was key to making that happen.
  - danmaz74 10y ago
    Running unit tests on only the parts of your monolith you touched should be fast. Running the full test suite will be slow, but then testing a full architecture made of lots of micro services, with all possible race conditions and other concurrency complications, is way more difficult, at least in my experience (and that is with few not-so-micro services).
- mtkd 10y ago
  surely the microservice set needs to be tested as a whole too - especially if the services are consumers of each other this is the biggest argument against going large on using them in my view - you create a collection of ghettos with the intention of partitioning - but end up with spaghetti when it comes to maintenance and adding macro features later - especially as developers come and go and don't fully understand the architecture I completely buy using them to scale very high load core functions or to separate isolated non-core functions - in moderation
  - sriram_iyengar 10y ago
    Hi, suggest you to read on the test pyramid and the advantages micro services bring in to compliment it. Thanks
pathsjs 10y ago
I think you mean that usually testing monoliths is easier (no network and so on) but I am not sure, can you clarify?
- gregmac 10y ago
  It should -- microservices require testing versioned interactions between services. Let's say you're changing the behaviour of a feature in service A that is consumed by service B. Service A is at version 15, service B is at version 42. You have to deploy service A version, but it has to have the new change but still also be compatible with service B v42 (because that's what's running). Then, when service B v43 is deployed, service A has to start serving the new functionality. This gets exponentially more complicated with more services, more dependencies and more versions.

Another aspect to consider is, time taken to run regression and automation tests on the Monolith, by both devs & QAs. This affects frequent release of software considerably l.

icebraining 10y ago

That's because you're testing the monolith end-to-end, but testing the microservices individually. None of this is inevitable: you should still test the microservice network as a whole, and you can definitively test the components of a monolith individually.

sriram_iyengar 10y ago
Agree that the functionality needs to be tested in-whole. But the delta in time is very large when the feature level tests have to be run on the monolith & they can be avoided when they are tested on the micro service.
- ProblemFactory 10y ago
  But where does the difference come from? A "well-designed monolith's" code architecture would be very similar to microservices - with separated modules, but in-process function calls instead of remote API calls. If you do large-scale integration tests that cross module boundaries in the monolith, then you should also have the same tests of the full deployment with microservices. If you test each microservice independently, then you could also run tests for each module independently.
  - sokoloff 10y ago
    My experience (sample size of 1) is that long-lived monoliths tend not to evolve along "well-designed" lines, but rather along "what can I possibly do to get this to work in the time I have?" lines. Further, it's an impossible hurdle to schedule big dig to make substantial architectural improvements on a large monolith, so refactorings and improvements tend to be shallow and localized. A decade later, and you have a lot of business logic in stored procedures in your database and now hear grumbling from coders who don't know or don't want to learn SQL. (And, to be fair, it does make it harder to scale the engineering team if everyone needs to be proficient at SQL.) Neither availability nor technical scaling concerns were the reason we started to transition away from our monolith. We were regularly hitting 4 nines of availability (measured by "orders coming in") and had scaled to well over $1BB in revenue essentially on a single database for most of the site functionality. Above average engineers and ops, and way above average DBA team was key to making that happen.
- danmaz74 10y ago
  Running unit tests on only the parts of your monolith you touched should be fast. Running the full test suite will be slow, but then testing a full architecture made of lots of micro services, with all possible race conditions and other concurrency complications, is way more difficult, at least in my experience (and that is with few not-so-micro services).
mtkd 10y ago
surely the microservice set needs to be tested as a whole too - especially if the services are consumers of each other this is the biggest argument against going large on using them in my view - you create a collection of ghettos with the intention of partitioning - but end up with spaghetti when it comes to maintenance and adding macro features later - especially as developers come and go and don't fully understand the architecture I completely buy using them to scale very high load core functions or to separate isolated non-core functions - in moderation
- sriram_iyengar 10y ago
  Hi, suggest you to read on the test pyramid and the advantages micro services bring in to compliment it. Thanks

pathsjs 10y ago

I think you mean that usually testing monoliths is easier (no network and so on) but I am not sure, can you clarify?

gregmac 10y ago
It should -- microservices require testing versioned interactions between services. Let's say you're changing the behaviour of a feature in service A that is consumed by service B. Service A is at version 15, service B is at version 42. You have to deploy service A version, but it has to have the new change but still also be compatible with service B v42 (because that's what's running). Then, when service B v43 is deployed, service A has to start serving the new functionality. This gets exponentially more complicated with more services, more dependencies and more versions.