3 ms·
> 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 t
by mrkeen 3mo ago
> 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. Everyone's responsibility is no-one's responsibility, and the code stays as is.
In a microservice, I publish an interface, and I'm free to tear up all the carpet behind it as long as it keeps doing its job as advertised. Knowing whether public routes are still in use is still a problem, so you need a minimum level of metrics or logging before you can retire an endpoint.
- nlitened 3mo agoI think you described not monolith vs microservices, but single person working on a project and making decisions vs multiple. “Everyone’s responsibility is no-one’s responsibility” works the same way if multiple people work on the same microservice. Also a monolith may (actually, must) have internal public interfaces through which components must communicate, and those contracts are more enforceable, amenable to static checks, and much higher performance that microservices’ network interfaces.
- reactordev 3mo agomonoliths can be anything under the boundaries. That's why people get this so wrong. There is no rule that says you must have internal public interfaces (misnomer? how can it be public, but internal, at the same time?). Microservices were entirely designed to split work across teams.
- reactordev 3mo agoThis 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.
- zero_shift 3mo agoTracing 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 week Datadog aggregation window
- reactordev 3mo agoIt 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.
- zero_shift 3mo agoObservability and operability are just not the same thing as being able to reason about the software. You need both You can't capture the full range of behaviours and edge cases unless you are willing to ingest billions of events without lossiness Metrics have limitations of cardinality. Logs need to be reduced or else you are in archive rehydration hell There will be code paths that have never been triggered that you still need to reason about as part of analysing a system, eg in threat modelling > I get why you think I might not have worked on large systems I didn't, necessarily. But it looked like an excessively strong claim, combined with a challenge to the author's competence. I wanted to call that out.
- reactordev 3mo ago>”There are code paths that have never been triggered” I don’t know where you learned engineering but where I work, we test our code. There are no “dark” paths. 98% code coverage over 50+ microservices.
- VulgarExigency 3mo ago> 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.
- mrkeen 3mo agoThen substitute 'dead code' for 'buggy code that someone else likes'
- inigyou 3mo agoIt 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
- danbruc 3mo agoYou do exactly the same in a monolith, functionality is broken into modules with a public API and you can switch out the implementation at any time if you want or have to.
- inigyou 3mo agoMicroservices still have global concerns. Is someone actually using that endpoint or can you remove it? How will you know? Ask everyone? How many HTTP calls are made during one user request and how long does it take? (This concern brought down one of the early microservice projects with a 10-minute page load time) What are the race conditions? User removes billing info at the same moment as making a payment - what happens? Is the payment marked as successful but not actually billed?
- mrkeen 3mo agoAt least read to the end > Knowing whether public routes are still in use is still a problem, so you need a minimum level of metrics or logging before you can retire an endpoint. > What are the race conditions? Everywhere. Just fucking everywhere. I ran a workshop for my team (4-5 backenders) with a simple, pared down example with reads and writes within a 'transaction'. I then demonstrated that LINQ breaks its transactionality, and running in READ-COMMITTED (which everyone does) also breaks transactionality. Either of these conditions is enough. My team walked away understanding this. But we left the idea there to die, because you cannot change these things politically. No monolith owner is going to even pretend to demonstrate thread safety. The lines of defence are: * He will assume it's thread safe * He will argue against change "for code consistency" * He will argue that it makes the code simpler and easier to understand * He will introduce a change which he assumes will fix it, but clearly only makes the race condition harder to diagnose * He will argue that it doesn't matter because race conditions are rare anyway. It's all academic anyway - in a monolith you won't get past the first line of defence anyway.
- inigyou 3mo agoYou seen to be equating "monolith" with "managed by a cranky guy" when it actually means "single unit of deployment"?
- mrkeen 3mo agoRight, and I am also "the cranky guy" to the other guy. But yes, I am equating those. Some people might take Conway's law as a warning to try to avoid; others might take it as a natural law description and therefore unavoidable. I'm in the second camp. Whichever way you swing, it is a political issue, and is therefore about cranky guys.
- sdfdfsfsdsdf 3mo agoIt'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.
- mrkeen 3mo agoThe pain of the network boundary pays for itself many times over compared to sharing a codebase with developers who don't program to the interface.