> (...) like using microservices on a system that gets 1k users a day.
This sort of specious reasoning just shows how pervasive is the fundamental misunderstanding of the whole point of microservices. Microservices solve organizational problems, and their advantages in scaling and reliability only show up as either nice-to-haves or as distant seconds.
Microservices can an do make sense even if you have 10 users making a hand full of requests, if those services are owned and maintained by distinct groups.
> Microservices can an do make sense even if you have 10 users making a hand full of requests, if those services are owned and maintained by distinct groups.
Maybe, but after the next CEO comes in, those groups would be reorganised anyway :-/
Few companies maintain their org chart for a large length of time. My last place had the microservices maintained by distinct groups when I joined. When I left a third of the people were gone and half the groups were merged into the other half.
This is not an uncommon thing. Going microservices because you don't want to step on other peoples toes is a good reason, but it's an even bet that the boundaries will shift anyway.
> But they should consider whether this matches the size/scope of the problem being solved
In professional software development projects, specially legacy projects, often times the complexity is not justified by the problem. There is always technical debt piling up, and eventually it starts getting in the way.
> Okay, so your microservices are each very simple, but that made the interactions and resource provisioning very complex. What was the net gain?
The main misconception about microservices is that people miss why they exist and what problems they solve. If you don't understand the problem, you don't understand the solution. The main problems microservices solve are not technical, but organizational and operational. Sure, there are plenty of advantages in scaling and reliability, but where microservices are worth their weight in gold is the way they impose hard boundaries on all responsibilities, from managerial down to operational, and force all dependencies to be loosely coupled and go through specific interfaces with concrete SLAs with clearly defined ownerships.
Projects where a single group owns the whole thing will benefit from running everything in one single service. Once you feel the need to assign ownership of specific responsibilities or features or data to dedicated teams, you quickly are better off if you specify the interface, and each team owns everything begind each interface.
> Once you feel the need to assign ownership of specific responsibilities or features or data to dedicated teams, you quickly are better off if you specify the interface, and each team owns everything begind each interface.
If team A needs a new endpoint from team B, what would a typical dialogue look like under microservices and a modular monolith, respectively?
How teams interact is a function of the team/org, not the software architecture.
What microservices easily provide in this scenario that is far harder to pull off with a monolith is that with microservices the service owners are able to roll out a dedicated service as a deliverable from that dialogue. Whether the new microservice implements a new version of the API or handles a single endpoint, the service owners can deploy the new service as an extension to their service instead of a modification, and thus can do whatever they wish to do with it without risking any impact on their service's stability.
Technically it works, but it requires some work. You need to pass off ccache's executable as the target compiler, and you need to configure the settings in all vsproj files to allow calls to the compiler to be cacheable, like disabling compilation batching.
Using cmake to generate make/ninja projects and use compilers other than msvc is far simpler and straight-forward: set two cmake vars and you're done.
I mean if you use multiple translation units and header files, you need to have a copy of the function declaration in that header file to be able to call it from other translation units.
> But this also reduces the opportunity to parallelize compilation across multiple files because they have been concatenated into fewer build units (...)
Irrelevant. There is always significant overhead in handling multiple translation units, and unity builds simply eliminate that overhead.
> and each unit now requires more memory to deal with the non-header parts.
And that's perfectly ok. You can control how large unity builds are at the component level.
> For some build systems and repositories, this actually increases build time.
You're creating hypothetical problems where there are none.
In the meantime, you're completely missing the main risk of unity builds: increasing the risk of introducing problems associated with internal linkage.
unity builds do often have worse performance than separate compilation for "incremental rebuilds" during development. that all depends on how the code is split up and how bad of a factor linking is.
> It's a breakthrough but this research doesn't establish the claim in the title of the article.
What claim would that be? The only claims made in the article was that a) it's a breakthrough, and b) "Researchers say certain strains of gut bacteria are the likely cause of Parkinson's disease."
The article also refers to the bacterias as "probable causes".
Everything you pointed out supports these observations.
> “Associated with” would have been a stronger claim
in English, "stronger claim" has a meaning ambiguous between "the claim is strongly defendable, i.e. more likely to be true", and "what is being claimed is of more powerful effect". I think here the claim they are trying to point out is the powerful effect, to say "this should be pursued, its importance is elevated by its potential strong causal/explanatory effect"
No. Causation is different from correlation. "Associated with" means correlation, "probable cause" means causation. Causation is the stronger statement here.
While technically association is a prerequisite for causation (correlation doesn't imply causation but causation implies correlation) probable "cause" is too strong of a term here because the experiment didn't actually do a causative test. "Possible cause" might be better here because the title heavily implies a causative study was done.
Do note that in science nothing can be proven so in actuality probable cause is really the highest form of verification that can be made. That is the claim in the title.
> For instance, a major selling point of Node was running JS on both the client and server so you can write the code once.
What? No.
The whole point of Node was a) being able to leverage javascript's concurrency model to write async code in a trivial way, and b) the promise that developers would not be forced to onboard to entirely different tech stacks on frontend, backend, and even tooling.
There was no promise to write code once, anywhere. The promise was to write JavaScript anywhere.
That's the reasoned take, and yet I have strong and distinct memories of Node being sold on the basis of shared code as early as 2011. Much of the interest (and investment) in Meteor was fueled by its promise of "isomorphic JavaScript."
Your comment sounds awfully disingenuous. I seriously doubt you do not see the huge difference between implementing official policies of extrajudicial imprisonments and having a random person murder people for their own personal reasons.
What are you talking about? OP did not mentioned any example remotely involving Guantanamo bay. Are you trying to move the goalpost out of ignorance or cynicism?
This brand of disingenuous whining reads like someone complaining the police pull them over for no reason when they were actually crossing a red light, and they still have the gall to play the victim card.
Every time you increase compliance through force, you increase the incidents of abuse and incorrect use of the force. That's not a fallacious or even surprising revelation, and it's not specific to anything in particular about COVID-19.
It can be detrimental overall when the measures to be enforced are mostly security theater, rather than effective. Unfortunately, my observations are that both after 9/11 and during the COVID-19 crisis, force was on the bottom line mostly used to oppress and abuse, less so to decrease risk of terrorist acts and infection respectively.
In a smarter, less corrupted society, where these measures we're trying to enforce are well thought out, tested and effective, the use of force would still be necessary, despite compliance in general would be better due to effective information campaigns. Alas.
> Every time you increase compliance through force (...)
Enough with this disingenuous bullshit. Public health officials specified basic public health measures to fight a pandemic, like washing your hands, practice social distancing, and wear a mask. That's it. What do you expect to achieve by putting up these pathetic strawmen? Do you actually expect to gaslight everyone who lived through the pandemic?
Did you miss the horrors of the Chinese lockdowns? The Australian "quarantine centers" practices & abuse? What about people in Greece who were banned from leaving their homes or neighborhood? I'm barely scratching the surface, there was so much stupidity in how we handled the pandemic, worldwide.
You're simply ignorant. Very, very, ignorant, and very arrogant which blinds you from your ignorance. That's a classic toxic combo.
For the record, I'm double vaccinated, wore masks before anyone else did, after most everyone else did, and FFP2/N95 respirators at that, not surgical masks, and I obviously avoid tight crowds and wash my hands.
But your attitude is counter-productive and frankly disgusting. Every issue has two sides. A reasonable person is aware of this and plays the uneasy, but necessary balancing game to avoid extremes. You are NOT a reasonable person. You're a loudmouth who thinks they're on a religious mission to shut the mouths of "gaslighters" who do not sufficiently praise authority, which is blameless and infallible. You're part of the problem.
If anyone is gaslighting, it's you, who dismisses a whole complex range of extremely valid criticisms of civil liberties abuses, dubiously rushed policies, regulatory incompetence and in some cases outright dishonesty by government organizations and politicians as "disingenuous bullshit"... What an absurdly narrow, simplistic and willfully ignorant take on so many complex points.
This sort of specious reasoning just shows how pervasive is the fundamental misunderstanding of the whole point of microservices. Microservices solve organizational problems, and their advantages in scaling and reliability only show up as either nice-to-haves or as distant seconds.
Microservices can an do make sense even if you have 10 users making a hand full of requests, if those services are owned and maintained by distinct groups.