3 ms·

I’ve always seen microservices as primarily used a trendy way to impose basic engineering discipline on projects where there isn’t the will to define interfaces

I’ve always seen microservices as primarily used a trendy way to impose basic engineering discipline on projects where there isn’t the will to define interfaces between components explicitly (DNS being a crude service locator pattern, different VMs providing basic encapsulation). Unfortunately this is only a marginal improvement, as the team remains devoid of engineering discipline. :/ This article has meaningful advice but I’m not sure that it will be often applied.

Twisol 6y ago
> Unfortunately this is only a marginal improvement, as the team remains devoid of engineering discipline. :/ This strikes me as the crux here, along with this line from the article: > There were three main reasons for the initial success of microservices as an architectural pattern for software: [...] 3) an excuse for having no architecture. Microservices are a little bit too much of a "just so" story to me. It's a cozy non-answer to the hard problems of system design.
systemvoltage 6y ago
You nailed it so perfectly. The difference is encapsulation of dependencies and independent scalability of each service. That aside, whether we have a monolith or microservices, you cannot fix bad architecture. It’s like spreading out components with larger copper traces and separating them. If you’re circuit is wrong, no amount of things you can do on the PCB level will fix it. Fix the schematic (circuit) first.