6 ms·
Funny, but we saw a debate around monolithic codebases and the monolithic image in Smalltalk. A team of three engineers orchestrating 25 microservices sounds i
by stcredzero 8y ago
Funny, but we saw a debate around monolithic codebases and the monolithic image in Smalltalk.
A team of three engineers orchestrating 25 microservices sounds insane to me. A team of of thirty turning one monolith into 10 microservices and splitting into 10 teams of three, each responsible for maintaining one service, is the scenario you want for microservices.
A team size of 10 should be able to move fast and do amazing things. This has been the common wisdom for decades. Get larger, then you spend too much time communicating. There's a reason why Conway's Law exists.
https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law
- nicoburns 8y agoAgreed. And there's no reason why your monolith need become 10 microservices. It could be split into say just 3 if that makes more sense.
- pytester 8y agoI don't think Martin Fowler realized when he wrote the first microservices article that he'd stumbled upon a technical solution to a political problem. He just saw it work and wanted to share.
- stcredzero 8y agoI don't think Martin Fowler realized when he wrote the first microservices article that he'd stumbled upon a technical solution to a political problem. He just saw it work and wanted to share. The generation of programmers that Martin Fowler is from, are exactly the people from whom I got my ideas around how organization politics effect software and vice versa. There was plenty of cynicism around organization politics back then.
- jacquesm 8y agoAnd it's not as if Martin Fowler came up with the idea as an original either, QnX, Erlang and many other systems used those basic ideas much earlier (sometimes decades earlier). But this is the web, where the old is new again.
- icebraining 8y agoHe says so himself: > We do not claim that the microservice style is novel or innovative, its roots go back at least to the design principles of Unix.
- projektfu 8y agoIt’s safe to say that Fowler rarely claims to originate things. He’s more of a taxonomist.
- User23 8y agoIt's interesting how few executives understand this come reorganization time.
- mcguire 8y agoThe architecture of software comes to resemble the organization writing the software. Use that fact or it will use you.
- igouy 8y ago> Funny, but we saw a debate around monolithic codebases and the monolithic image in Smalltalk. What reasons do you have for making that link? What are you refering to? It's possible to load some code and snapshot as a Smalltalk image; then load some different code and snapshot as a different Smalltalk image.
- stcredzero 8y agoWhat reasons do you have for making that link? What are you refering to? It's possible to load some code and snapshot as a Smalltalk image; then load some different code and snapshot as a different Smalltalk image. It's a different story when you're working on a team, and a different story when there are two or more teams using the same repository. Sure, you still have the image. The debate had to do with how the Smalltalk image affected the community's relationship to the rest of the world of software ecosystems, and how the image affected software architecture in the small. That "geography" tended to produce an insular Smalltalk community and tightly bound architecture within individual projects.
- protomyth 8y agoDid anyone ever build a multi-image Smalltalk? For a lot of stuff it wouldn't make sense, but having the ability to separate the image.
- stcredzero 8y agoDid anyone ever build a multi-image Smalltalk? People at least played around with that as a research project. There's one that showed up at the Camp Smalltalks I went to, with a weird-but-sensible sounding name. (Weird enough I can't remember the name.) There would have been great utility in such a thing. For one thing, the debugger in Smalltalk is just another Smalltalk application. So what happens when you want to debug the debugger? Make a copy of the debugger's code and modify the debugger hooks so that when debugging the debugger, it's the debugger-copy that's debugging the debugger. With multi-image Smalltalk, you could just have one Smalltalk image run the debugger-copy without doing a bunch of copy/renaming. (Which, I just remembered, you can make mistakes at, with hilarious results.) If you do the hacky shortcut of implementing one Smalltalk inside another Smalltalk (Call this St2), then the subset of objects that are the St2 objects can act a bit like a separate image. In that case, the host Smalltalk debugger can debug the St2 debugger.
- tabtab 8y agoIndeed! Conway's the man. Unless your "service" corresponds to an actual existing team who has the time and authority to focus on it, you are asking for trouble and/or wasteful busywork. I curse misapplied microservices. By the way, for a relatively small service to be shared by multiple applications, try RDBMS stored procedures first.
- jrochkind1 8y ago> Funny, but we saw a debate around monolithic codebases and the monolithic image in Smalltalk. Was there a consensus resolution?
- stcredzero 8y agoWas there a consensus resolution? Smalltalk is awesome. Everyone else is doing it wrong, those dirty unwashed! https://www.lesswrong.com/posts/ZQG9cwKbct2LtmL3p/evaporative-cooling-of-group-beliefs https://www.lesswrong.com/posts/ZQG9cwKbct2LtmL3p/evaporativ...