91–100 of 356 posts
Earlier quoted context omitted.
Here is the thing, whatever you write doesn't work without linking, so no we never moved away from it.
But is linking the right way to couple business logic from two different organisational units? That is the question being discussed.
International company was wasting 6x the clouding hosting costs. And using 30+ engineers. Competitor, 6 engineers.
Competitor successfully completed the project and is releasing features faster.
Microservices should only be used when necessary, just as antibiotics.
Hahaha. I have been saying the same for years but have either been punished by my managers or mercilessly downvoted on HN. Somehow mentioning that microservices might not be perfect solution in every case triggers a lot of people. I have actually helped save at least one project in a huge bank which got rolled from 140 services into one. The team got also scaled down to third of its size but was able to work on this…
I think my biggest gripe with orgs that adopt microservices is they don't build out any of the testing, CI/CD, monitoring and debugging workflows to support it. It goes from shitty, slow monolithic application that super-pro can debug in a few minutes to.. Slow, shitty disparate services that are managed by different teams who don't share anything, suddenly you've got a Cuckoo's Egg situation where 1 guy needs to get…
If you have trouble managing ONE application what makes you think you will be better at managing multiple?
Also, running distributed system is way more complicated than having all logic in a single application. Ideally you want to delay switching to distributed system until it is inevitable that you are not going to be able to fulfill the demand using monolithic service.
If your application has problems, don't move to microservices. Remove all unnecessary tasks and let your team focus on solving the problems first and then automate all your development, testing, deployment and maintenance processes.
Or call me and I can help you diagnose and plan:)
A problem I've seen on the project I'm working on is that the team seems to want to do conflate orthogonal issues from a design and technical perspective. "We're going to microservices because the monolith is slow and horrible. We're going to use CQRS to alleviate pressure on the repositories. We're going to use Event Sourcing because it works nicely with CQRS."
Question: "Why are we Event Sourcing this simple CRUD process?"
Answer: "Because we are moving from the Monolith to Microservices".
have seen that happening. importing modules from all over the place to get a new feature out in the monolith. also, note this happened with rapid on boarding, the code-review culture was not strong enough to prevent this.
so the timing of the change from monolith to micro-service is critical, in order to get rid of it. otherwise, chances are high you got a monolith and microservices to take care of.
Earlier quoted context omitted.
When the same practices used to sell microservices get applied to modules, packages and libraries, there is no need to put a network in the middle to do the linker's job. But too many are eager to jump into distributed computing without understanding what they are bring into their development workflow and debugging scenarios.
It is much harder to enforce the discipline of those practices across modules boundaries than around network boundaries. So in theory yes you could have a well modularized monolith. In practice it is seldom the case. The other advantage of the network boundary is that you can use different languages / technologies for each of your modules / services.
Don't get me wrong, sometimes it's worth it (I particularly like Spark's facilities for distributed statistical modelling), but I really don't get (and have never gotten) why you would want to inflict that pain upon yourself if you don't have to.
Earlier quoted context omitted.
When the same practices used to sell microservices get applied to modules, packages and libraries, there is no need to put a network in the middle to do the linker's job. But too many are eager to jump into distributed computing without understanding what they are bring into their development workflow and debugging scenarios.
Not to mention the operational overhead, which grows exponentially with the number of services, languages, frameworks and the sum of all their quirks.
I'm embarrassed to say that I recently built microservices first, and am now kicking myself as I merge them back in to a monolith.
If you don't mind telling this story, why did you end up merging them back in? I would have thought that needlessly making microservices is bad but not bad enough to justify merging back.
Earlier quoted context omitted.
It is much harder to enforce the discipline of those practices across modules boundaries than around network boundaries. So in theory yes you could have a well modularized monolith. In practice it is seldom the case. The other advantage of the network boundary is that you can use different languages / technologies for each of your modules / services.
But the network is so slooooooowwwwwwwww. Don't get me wrong, sometimes it's worth it (I particularly like Spark's facilities for distributed statistical modelling), but I really don't get (and have never gotten) why you would want to inflict that pain upon yourself if you don't have to.
I’ve been developing for more years than dime if you have lived, and the best thing I’ve heard in years was that Google interviews were requiring developers to understand the overhead of requests.
In addition, they should require understanding of design complexity of asynchronous queues, needing and suffering from management overhead of dead letter, scaling by sharding queues if it makes more sense vs decentralizing and having to have non-transactionality unless it’s absolutely needed.
But not just Google- everyone. Thanks, Mr. Fowler for bringing this into the open.