231–240 of 243 posts
Earlier quoted context omitted.
reminds me of that law: "For something to get clean, something else must get dirty" and the corollary: "You can get something dirty without getting anything clean"
How does that apply here? (I’m not being facetious)
You must remove complexity to make understandable code.
You can remove complexity without making anything understandable.
Earlier quoted context omitted.
Or... if you're working in an organization that already has a Microservice based infrastructure in place. Otherwise, I generally agree... I'll usually take a monolith approach and break things off in ways that make sense. Usually starting with long running processes that can simply be workers off of queues. Sometimes potential bottlenecks that have higher compute overhead, such as passphrase hashing and comparison wh…
Isn’t something paraphrase hashing something that should be heavily rate limited? In order to DoS your typical site through passphrase hashing you would need to be: - have a ton of valid usernames/emails of accounts that need to be checked (because a typical password check will rate limit by account) - send in a massive torrent of traffic from a ton of IP addresses (because a typical password check will be rate limit…
A good rule of thumb is that if you’re starting a new project and immediately implement microservices, you’ve already failed. Never seen it work, don’t think I ever will. The only way microservices can ever work is if they’re extracted over time as the monolith gets fleshed out, likely over the course of years. And even they’re probably a bad idea.
I've never done it myself, but it seems startups are succesfully deploying using for example auth0. Outsourcing auth like that is using microservices right?
Earlier quoted context omitted.
But you can make a "new service" in code in the same binary communicating through memory. You can then separate it to a separate binary, when the network and serialisation overhead worth it. 80% of the time it will never come.
Microservices are not only "function calls over TCP" though. There are other concerns such as database per service vs a single shared database. There are also security implications that you don't have with a monolity. Designing it that way from the beginning could easily be as complicated as making them separate services.
Earlier quoted context omitted.
tldr: Microservices trade design complexity with operational complexity , to address the shortcomings & patterns of the modern IT sector, at both worker and management levels. This was an excellent choice for consulting (companies like ThoughtWorks, who were pushing microservices) as it optimized their workflows and bottom line: the answer to every client's question of "what's the architecture?" was "Microservices".…
I would argue Microservices trade 100% design complexity with 100% operational complexity and 20% design complexity. Everytime I saw a microserviced design, I always wondered how would they debug this easily and re-operationalize it. Sometimes it is better to let the entire system die and spawn it back instead of having something running to make it look like it's alive.
Earlier quoted context omitted.
Sure but there's still limits such as the binary size and working memory etc
Could you give a concrete example from your experience? I ask because in my experience, services have had a relatively small (say less than a few hundred GB) fixed working memory usage, and the rest scales with utilisation meaning it would help to spawn additional processes. In other words, it sounds like you're speaking of a case where all services together consume terabytes of memory irrespective of utilisation, bu…
Earlier quoted context omitted.
Could you give a concrete example from your experience? I ask because in my experience, services have had a relatively small (say less than a few hundred GB) fixed working memory usage, and the rest scales with utilisation meaning it would help to spawn additional processes. In other words, it sounds like you're speaking of a case where all services together consume terabytes of memory irrespective of utilisation, bu…
Let's imagine Facebook, we can partition the monolith by user, but you would need the entire code base (50+ million lines?) running in each process just in case a user wants to access that functionality. I'm not saying one can't build a billion dollar business using a monolith, but at some point the limit of what a single process can host might become a problem.
Earlier quoted context omitted.
> So it is very likely for a tornado to reconfigure things into debris and extremely extremely unlikely for the tornado to reconfigure everything into a brand new car. Is this not a linguistic sleight of hand? There are billions of trillions of states we label with "debris" but only a few thousand we would call "car". So a specific state of debris, then, is equal in complexity to a car?
The technical term for this is macrostate. It is not a linguistic sleight of hand. It is literally within the formal definition entropy. Debris is a high entropy macrostate, while a car occupies a lower entropy macrostate. There are less possible atomic configurations for cars then their is for debris. Each of these individual configurations of atoms is called a microstate. A macrostate is a collection of microstates…
That doesn't really line up logically. :/
Earlier quoted context omitted.
The technical term for this is macrostate. It is not a linguistic sleight of hand. It is literally within the formal definition entropy. Debris is a high entropy macrostate, while a car occupies a lower entropy macrostate. There are less possible atomic configurations for cars then their is for debris. Each of these individual configurations of atoms is called a microstate. A macrostate is a collection of microstates…
> There are less possible atomic configurations for cars then their is for debris. That doesn't really line up logically. :/
Debris is almost any configuration of atoms that are considered trash or unusable.
There's are much more ways you can configure atoms to form useless trash then you can to make cars. Case in point "you" can manufacture "debris" or "trash" by throwing something into a trash can. Simple.
When's the last time you manufactured a car? Never.