191–200 of 243 posts
Earlier quoted context omitted.
Sounds like a way to spend a lot of your time doing “cross functional work.”
I never thought about that as a euphemism for "you're doing it wrong." Makes me rethink my priorities...
Earlier quoted context omitted.
Given your last sentence incidental complexity can be created and destroyed (and is more difficult to destroy than create). The quote would probably be more accurate as: > "ESSENTIAL Complexity can neither be created nor destroyed, only moved somewhere else."
That just makes it a tautology. It basically says “essential complexity exists”.
Often a developer will see something big or complex and see it as a problem.
But they should consider whether this matches the size/scope of the problem being solved
The whole debate is rather silly. Just pick the right architecture for the given problem. Sometimes it's monolith, sometimes it is not. The end.
This really is the issue. When you have no informed opinion, it may be better to start with monolith. This Microservice culture was all about "let me reduce the design complexity by using MS"
Obviously doesn't scale but aluring anyway
Earlier quoted context omitted.
What do you mean "the type of strings"? In pretty much every programming language, String is one of the most fundamental types. There's no "different types of string". (yes, this is a joke, a bad one at that. badum tish)
Obviously you haven't seen the Substring [1] type of Swift. [1] https://developer.apple.com/documentation/swift/substring
Earlier quoted context omitted.
Before "microservices" there are services, which are also composable. And in the realm of monoliths there are also modules. Which are the key to composability. What microservices give you is a hard boundary that you cannot cross (though you can weaken it, you cannot eliminate it) between modules. This means the internal state of a module now has to be explicitly and more deliberately exposed rather than merely bypass…
> The challenge in monoliths is that the boundary is so easily breached The biggest challenge with monoliths is the limits of a single process and machine.
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.
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 which is relatively easy to DDoS, but if broken off only effects new logins and password changes.
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?
So I generally try to design with a separated authentication from the beginning. I'll start with a "dev" auth service that will just have a form you can fill out whatever you want for the "user" and permissions, then sign a token to get into your local/dev environment application. From there it's really easy to create a more robust system or wrappers for external systems (Auth0, Okta, Azure AD, etc).
In general, however, MicroServices is about completely separating a given context domain from other services in a larger system. Account Management is separate from Assets, etc. In practice this means you will have a much more complex orchestration, deployment and communications system in place, often with some sort of Distributed RPC, Queue or other layers on top. You also have to be much more concerned with communications between teams and service versioning and availability.
This complexity isn't less complex, it just shifts the complexity, which can help with larger organizations, but for smaller teams it can really bottleneck everything. This is why the general concensus is to start with a more monolithic codebase designed to still scale horizontally, then break off systems as the need arizes.
The exception being if you are in an organization that has already paid the overhead/debt of setting up for microservice orchestrations.
Software would be 50% better if every developer understood Tesler's Law: "Complexity can neither be created nor destroyed, only moved somewhere else." The drive to simplify is virtuous, but often people are blind to the complexity that it adds. Okay, so your microservices are each very simple, but that made the interactions and resource provisioning very complex. What was the net gain? The correct solution depends on…
Earlier quoted context omitted.
Given your last sentence incidental complexity can be created and destroyed (and is more difficult to destroy than create). The quote would probably be more accurate as: > "ESSENTIAL Complexity can neither be created nor destroyed, only moved somewhere else."
That just makes it a tautology. It basically says “essential complexity exists”.
It's one thing to shift complexity to a different group/team, such as managing microservice infrastructure and orchestration that can specialize in that aspect of many applications/systems. It's very different to create those abstractions and separations when the same people will be doing the work on both sides, as this adds cognitive overhead to the existing team(s). Especially if you aren't in a scenario where your application performance overhead is in eminent danger of suffering as a whole.
Software would be 50% better if every developer understood Tesler's Law: "Complexity can neither be created nor destroyed, only moved somewhere else." The drive to simplify is virtuous, but often people are blind to the complexity that it adds. Okay, so your microservices are each very simple, but that made the interactions and resource provisioning very complex. What was the net gain? The correct solution depends on…
> Okay, so your microservices are each very simple, but that made the interactions and resource provisioning very complex. What was the net gain? The net gain was composability of microservices, distribution of computing resources, and the ability to marshall off implementation details. Just because those requirements were routinely ignored in the era of monoliths doesn't mean the complexity wasn't essential or didn'…