101–110 of 139 posts
My thoughts on microservices... They're fine. But what's NOT fine are nano services. I did security on a project once where it seemed that every function was its own microservice. User registration, user login, and password resetting were each a separate microservice. It was an utter nightmare.
Earlier quoted context omitted.
> With a monolith any random developer can go and flip some private method to public, import it way across the modules, and presto you are now building a ball of mud. If "any developer" can do it, then the problem is not with monoliths, but rather with your pull request reviews process and lack of code ownership. This can even be helped by Github and other platforms with a CODEOWNERS file. Microservices by themselves…
I haven't had experience with well isolated modules in a monolith so I'm likely not giving monolith enough credit here. It's possible a microservice organization may still have an advantage by having more of this isolation by default, instead of an uphill battle to get things set up properly.
Microservices are not a solution, they're a capability. It's powerful for a team to be able to deploy a tiny service with the absolute minimum amount of explicit plumbing to meet operational requirements. Whether they should break their system up this way is a case by case judgment. Every place I've been, the costs of microservices get overlooked in favor of the illusion of decoupling. Microservices will absolutely m…
In this case, using microservices was like getting drunk: a way to briefly push all your problems out of your mind and just focus on what's in front of you. But your problems didn't really go away, and in fact you just made them worse.
If I was CTO of a company, microservices would give me nightmares. How do you do due diligence on used free software (licenses and security updates)? How do you plan the resource usage of your whole setup if every developer can add a new autoscaling service? Who is actually keeping track on deployments so we don't accidentally overload the system? How do you refactor a cross-service feature consistently? And the wors…
Use the same process you would use if you had a monolith.
The rest of your issues can be solved by planning out your services, rather than giving everyone free reign to make a new service. Switching to services doesn't magically mean your teams stop talking and designing together.
Earlier quoted context omitted.
So you're not only suggesting monolith, but single instance? In process and non-shared queues only? No load balancing across monoliths?
Not necessarily. That one can have these tools in-application doesn't mean one cannot combine this with some form of RPC as well. Especially whether one needs load balancing or not seem to be a completely orthogonal issue. On the other hand, why not a monolith and single instance? If one uses a performant language one would be amazed how much can run on a single machine. If one expects growth one should have some pla…
Single points of failure are bad. I agree its orthogonal, which is why I inquired further about the, imo, odd suggestion.
Microservices are not a solution, they're a capability. It's powerful for a team to be able to deploy a tiny service with the absolute minimum amount of explicit plumbing to meet operational requirements. Whether they should break their system up this way is a case by case judgment. Every place I've been, the costs of microservices get overlooked in favor of the illusion of decoupling. Microservices will absolutely m…
Def the best/worst reason to use it, but it does - practically - make sense. Anyone who has had cross-team-monoliths will welcome this.
Earlier quoted context omitted.
> With a monolith any random developer can go and flip some private method to public, import it way across the modules, and presto you are now building a ball of mud. If "any developer" can do it, then the problem is not with monoliths, but rather with your pull request reviews process and lack of code ownership. This can even be helped by Github and other platforms with a CODEOWNERS file. Microservices by themselves…
I haven't had experience with well isolated modules in a monolith so I'm likely not giving monolith enough credit here. It's possible a microservice organization may still have an advantage by having more of this isolation by default, instead of an uphill battle to get things set up properly.
If you’re using microservices + monorepo, you need exactly the same thing, otherwise people will just commit in your service.
If you’re relying on multiple repositories, you can just split things within libraries and have the exact same effect. You can even have separate deployments with this arrangement.
Not to mention it is also an “uphill battle to get things set up properly” with microservices, so there’s really no advantage in using them for enforcing encapsulation.
But most important: a team unable to enforce encapsulation and code ownership is not ready for microservices at all.
Earlier quoted context omitted.
Fails because the function is unreachable. The second half of the sentence you quoted says exactly that, why did you cut it out?
If execution of your binary is stopped some time between the call and return (with following restart), dealing with it is no simpler than dealing with network partitioning.
Earlier quoted context omitted.
Given your negative characterisation of the "ball of mud", I'm guessing you haven't actually read the original paper. > heck even a different language There's nothing about writing software in different languages that necessitates separating functionality with HTTP calls.
> There's nothing about writing software in different languages that necessitates separating functionality with HTTP calls I mean it's only computers and the only limit to what we can make them do is our imagination. In this case though for the sake of argument what options would I have if I, say, needed to let a remote team add some functionality to my, say, Spring backend but they really prefer to write C# and have…
With a library.
Depending on what you’re doing (process ran a few times a day?), maybe even spawning a process is enough.
> what options would I have if I, say, needed to let a remote team add some functionality to my, say, Spring backend but they really prefer to write C# and have their own CI/CD system.
That sounds like you need at most two different services, not microservices.
Earlier quoted context omitted.
Not necessarily. That one can have these tools in-application doesn't mean one cannot combine this with some form of RPC as well. Especially whether one needs load balancing or not seem to be a completely orthogonal issue. On the other hand, why not a monolith and single instance? If one uses a performant language one would be amazed how much can run on a single machine. If one expects growth one should have some pla…
>On the other hand, why not a monolith and single instance? Single points of failure are bad. I agree its orthogonal, which is why I inquired further about the, imo, odd suggestion.