71–80 of 243 posts
There is a big misconception that a monolith has to be fully deployed every time. A well designed monolith can be partially deployed.
Can you say more about that ? I'm a DotNet developer and I don't see how this could be possible without having several applications
Microservices shift complexity from code to operations - microservices don't remove complexity - they spread it wider, making the whole more complex.
Earlier quoted context omitted.
Doesn't this just mean you picked a bad service boundary? You shouldn't have to join across services, ever. Seems like a straw man.
It will eventually happen even if you manage to create the perfect boundaries, e.g for report & statistics.
Earlier quoted context omitted.
> Microservices are relatively new and unproven. They are so old, buddy, actually. Splitting monolith into services(not always been micro) is a natural evolution for any software.
It was SOA (Service Oriented Architecture) where you would split them up, that predates Microservices by quite a bit. I remember doing that in the early 2000s. What I think he is saying is that Microservices people pitch their service against monolith as better, but monolith hasn't been in vogue for 20 years. I saw the same tactic with scrum people pitching against waterfall which hadn't been in vogue for quite a whi…
Why would you consider microservices if you are only 12 developers?
And that I think how you should approach micro services, to solve an organizational problem, not use it for solving a technical problem.
Earlier quoted context omitted.
>The golden rule is to never break API backwards compatibility. If you must, create a new version of the API and leave the old version functional It also helps with zero-downtime deployments: 1) spawn a new instance of the service with the new API, side by side with the old one 2) now incoming traffic (which still expects the old API) is routed to the new instance with the new API, and it's OK, because it's backward-…
How can accumulation of versions be prevented? Now the same team has to maintain two products, and the underlying mechanism is still limited by the older version. Anecdotally, a robust backward-compatibility has been seen as a hinderance to e.g. Java's progress (so much that a newer language, Kotlin, was created to break free from that burden).
However, I do think it can be easier to deal with for internal services then for something like Java. When the number of users is in the dozens rather then the millions, it's a lot easier to make sure everyone gets moved over to the new version.
Earlier quoted context omitted.
Examining behavior in the limit (a la physics) is interesting. Imagine a system where every function call goes out to a separate process. Suddenly you have a lot of processes waiting around to be called. Debugging requires special tools. Profiling becomes a nightmare. Even determining if the system is fully running becomes difficult. What have you gained?
> What have you gained? Separation of responsibilities? Easier to analyze because you only have so many inputs and outputs to a simpler system? Debugging something that touches a lot of paths in a monolith can be quite nightmarish as well.
I guess what it means is that even if you can build a well modularized system, it will only stay well modularized if you use a network call to enforce it. Well, at least for most companies.
Conceptually, there's nothing keeping you from designing your codebase to work as both microservices or direct calls. I've certainly done it before - each service defined a Java interface, and codegen could hook that up as either a direct call or to route over some kind of layer.
The term "Monolith" was devised by people who wanted to brand microservices as newer and superior. It's almost as if in order to succeed these days you need to discredit and disparage your competition rather than simply having a better product, and that's why I don't buy into buzz words at all. If it's not broken, don't fix it... Microservices are relatively new and unproven. The way the world has rushed to dive into…
I’m somewhat sure everyone is somewhere in between depending on who you ask.