Goodbye Microservices: From 100s of problem children to 1 superstar
It seems like splitting into separate repos was a rash response to low-value automated tests. If tests don&#x27;t actually increase confidence in the correctness of the code they&#x27;re negative value. Maybe they should have deleted or rewritten a bunch of tests instead. Which is what they did in the end anyway.<p>&gt;&gt; A huge point of frustration was that a single broken test caused tests to fail across all destinations. When we wanted to deploy a change, we had to spend time fixing the broken test even if the changes had nothing to do with the initial change. In response to this problem, it was decided to break out the code for each destination into their own repos<p>They also introduced tech debt and did not responsibly address it. The result was entirely predictable, and they ended up paying back this debt anyway when they switched back to a monorepo.<p>&gt;&gt; When pressed for time, engineers would only include the updated versions of these libraries on a single destination’s codebase... Eventually, all of them were using different versions of these shared libraries.<p>To summarize, it seems like they made some mistakes, microed their services in a knee-jerk attempt to alleviate the symptoms of the mistakes, realized microservices didn&#x27;t fix their mistakes, finally addressed the mistakes, then wrote a blog post about microservices.