I wrote a post on my blog[1] a while back about this. Actually, there are records in memoirs and such that show similar pressures existed when MSA emerged.
[1]https://www.makonea.com/en-US/blog/how-did-microservices-arc...
What Even Are Microservices?
41–50 of 87 posts
Re: What Even Are Microservices?
#42> Inside a monolith it's easy to answer questions like "Which dependencies are we shipping?"; or "Is this piece of code still used?" Static analysis can often tell you. Once the code is spread across dozens of independent services, those answers become much harder to obtain. I draw the opposite conclusion here. In monoliths, someone else might want the code to stay in the codebase. I don't want to ask everyone about…
It's called programming to an interface.
type ThingDoer interface { DoTheThingIDontCareHow() (result, error) }
func NewAmazingThingIMade(theThingINeedButIDontCareHowItDoesIt ThingDoer) { // You receive the superduper thing and dont care about it in any other way }
func (a *Amazing) DoSomeThing() (result, error) { return a.DoTheThingIDontCareHow() }
Nothing about "monoliths" prevents or hampers this development style. Once someone decides to do the Thing in another fashion, they are free to do so and you wouldn't have to change a thing.
All problems you experience are organizational, not technical. It's psychology we should be studying, not computer science.
Edit: In fact you introduced a network boundary which can fundamentally only complicate matters, not make them simpler.
Re: What Even Are Microservices?
#43Earlier quoted context omitted.
This is complete lack of experience on the authors part. No tracing, no observability, no knowledge of distributed systems design to allow them to see what they can clearly measure. Your take is the correct one. Microservices break up the monolith so that multiple teams can work on pieces of the solution/platform without stepping on each others toes. The rest of it is documentation/discovery.
Tracing and o11y are a poor sibling to static analysis. > This is complete lack of experience on the authors part Actually I'm going to turn the accusation back on yourself: if you think reasoning about a system's entire graph of behaviours from runtime traces is trivial, I don't believe you've worked on a truly complex system The range of what a program can do is much larger than what a program does do in your two w…
It is trivial when properly configured and used. I get why you think I might not have worked on large systems but to the contrary, I've built systems for Fortune 500s. All of them had this baked in and all of them had a place to go when things went wrong. Self-service, observable, documented, and supported by the very folks who wrote it.
Re: What Even Are Microservices?
#44[flagged]
Re: What Even Are Microservices?
#45> Inside a monolith it's easy to answer questions like "Which dependencies are we shipping?"; or "Is this piece of code still used?" Static analysis can often tell you. Once the code is spread across dozens of independent services, those answers become much harder to obtain. I draw the opposite conclusion here. In monoliths, someone else might want the code to stay in the codebase. I don't want to ask everyone about…
> I draw the opposite conclusion here. In monoliths, someone else might want the code to stay in the codebase. I don't want to ask everyone about it. Everyone's responsibility is no-one's responsibility, and the code stays as is. Then they can retrieve it from source control? Leaving dead code in the codebase because "someone else might want it" sounds like nonsense.
It seems usual to leave code in the codebase (possibly commented out) if you think it may be used again in the near future. It's easier than digging through source control. If you know you won't need it any more, then you delete it
Re: What Even Are Microservices?
#46> Inside a monolith it's easy to answer questions like "Which dependencies are we shipping?"; or "Is this piece of code still used?" Static analysis can often tell you. Once the code is spread across dozens of independent services, those answers become much harder to obtain. I draw the opposite conclusion here. In monoliths, someone else might want the code to stay in the codebase. I don't want to ask everyone about…
This is complete lack of experience on the authors part. No tracing, no observability, no knowledge of distributed systems design to allow them to see what they can clearly measure. Your take is the correct one. Microservices break up the monolith so that multiple teams can work on pieces of the solution/platform without stepping on each others toes. The rest of it is documentation/discovery.
Why do you think different people can't work on different parts of a single deployment unit (which is what we mean by "monolith")?
Re: What Even Are Microservices?
#47This is basically Conway's Law in practice: microservices aren't created because of technical boundaries, but they emerge because organizations need team boundaries. https://en.wikipedia.org/wiki/Conway%27s_law
Yes, and then they start complaining that the shared domain objects are not kept up to date by team $notMine, and so they inevitably go to a shared library where they fall back into the same issues.
Is that a result of poor DDD, not modelling more appropriate objects? Eg a Customer Address, Delivery Address, Invoice Address Vs just a single shared Address
Or is there still too much conflict for the truly shareable objects?
Re: What Even Are Microservices?
#48Earlier quoted context omitted.
This is complete lack of experience on the authors part. No tracing, no observability, no knowledge of distributed systems design to allow them to see what they can clearly measure. Your take is the correct one. Microservices break up the monolith so that multiple teams can work on pieces of the solution/platform without stepping on each others toes. The rest of it is documentation/discovery.
Tracing and o11y are a poor sibling to static analysis. > This is complete lack of experience on the authors part Actually I'm going to turn the accusation back on yourself: if you think reasoning about a system's entire graph of behaviours from runtime traces is trivial, I don't believe you've worked on a truly complex system The range of what a program can do is much larger than what a program does do in your two w…
Missing the point.
Static analysis doesn't go away. Metrics just covers the gap of "is this used by external callers", and nothing more than that. You need that to identify dead routes in a monolith anyway.
If you like static analysis, you should be able to spin up new code in a language more amenable to it than the incumbent code. Not doable in a monolith.
Re: What Even Are Microservices?
#49I feel like the discussion between "monolith" and "microservices" is a false dichotomy. For a big software company, you don't have to ship a single behemoth monolith, but you don't have have microservices so small that a team of 3 has to manage 10 services. You can have "right size" services. I don't like to call them micro because they can be fairly big and do multiple things, as long as it makes sense to have them…
We had services mostly built around deployment requirements. This package runs on the CDN edge, this other one runs centrally on a cluster.
Re: What Even Are Microservices?
#50[flagged]
Cancer is that which increases its own number without any concern for the health of larger systems it exists within.
So you might be right.