41–50 of 328 posts
Earlier quoted context omitted.
> Melvin Conway, who introduced the idea in 1967.
Yes, I don’t think that you need microservices to be able to tackle Conway's law. At least it doesn’t have anything to do with each other. You could still do microservices and still fail to deal with Conway’s law.
That's what the poster suggests happened. Nowhere do they suggest that microservices are overall required.
This sounds like the old arguments about OOP. Turning everything into an object can make a small program into a big program, so it’s maybe not such a good idea for small-scale stuff. http://www.solipsys.co.uk/new/TheParableOfTheToaster.html However, in my experience, OOP made it possible to do really big stuff. It’s all about not having a “one-size-fits-all” approach. I don’t think it’s just about scaling architectur…
"Turning everything into an object can make a small program into a big program, so it’s maybe not such a good idea for small-scale stuff." In my experience OOP actually makes programs smaller. Assuming of course they have good programmers/architects and the program itself is larger than "Hello world".
I think that the problem here was that they were fighting against Conway's Law: https://en.wikipedia.org/wiki/Conway%27s_law > Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. I think microservices work well in organizations that are big enough to have a team per microservice. However if you've just split your monol…
I think that the problem here was that they were fighting against Conway's Law: https://en.wikipedia.org/wiki/Conway%27s_law > Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. I think microservices work well in organizations that are big enough to have a team per microservice. However if you've just split your monol…
I'll claim that splitting a well-structured monolith into microservices will always make it less maintanable, but it might be worth it if you need to for some reason like elasticity or failure tolerance.
But for the love of god, keep the design open. Don't tie the existence of internal software components to peoples livelihoods.
I'm just curious if there is a middle ground somewhere? On one end you have a giant monolith. All services rolled into one which includes your API, Middle ware and then Database. One the other end you have microservices which bundle services into individual distinct units with each service being responsible for its API, middleware and database. Are there any preexisting patterns which seek to combine these two and co…
That is a big red flag. Microservices that suffer from shared code changes are not really microservices, but a distributed monolith instead.
They just went from naive monolith, to naive micro services, then to smart coupling of the two...
I think that the problem here was that they were fighting against Conway's Law: https://en.wikipedia.org/wiki/Conway%27s_law > Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. I think microservices work well in organizations that are big enough to have a team per microservice. However if you've just split your monol…
Noo! Building teams around software components cements your architecture and prevents most cross-cutting improvements. I'll claim that splitting a well-structured monolith into microservices will always make it less maintanable, but it might be worth it if you need to for some reason like elasticity or failure tolerance. But for the love of god, keep the design open. Don't tie the existence of internal software compo…
The claim is that such ties, at the macro-structure level, are inevitable and exist regardless.
The point is then to determine the best way either to restructure the organisation, or, the code base, to cope.
Earlier quoted context omitted.
Why do you think/feel that there are "too many"? What's the threshold for an acceptable number of microservices? (Not asking this to be confrontational. Just curious, because it's a sentiment I've seen before, without the reasoning behind it being articulated.)
One per developer seems like a fairly loose upper bound.
We recently had an interview candidate say this when we questioned the wisdom of having over a thousand microservices: some in languages that only the one developer maintaining them used! For me this is insane, but I digress
Monzo says that they have 800 people, and 1500 services. If we're generous and say 500/800 are developers, then each developer is responsible for 3 services! A team of 6 would have 18 projects in their domain.
I think that the problem here was that they were fighting against Conway's Law: https://en.wikipedia.org/wiki/Conway%27s_law > Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. I think microservices work well in organizations that are big enough to have a team per microservice. However if you've just split your monol…
Noo! Building teams around software components cements your architecture and prevents most cross-cutting improvements. I'll claim that splitting a well-structured monolith into microservices will always make it less maintanable, but it might be worth it if you need to for some reason like elasticity or failure tolerance. But for the love of god, keep the design open. Don't tie the existence of internal software compo…