However, a new problem began to arise. Testing and deploying changes to these shared libraries impacted all of our destinations. It began to require considerable time and effort to maintain. Making changes to improve our libraries, knowing we’d have to test and deploy dozens of services, was a risky proposition. When pressed for time, engineers would only include the updated versions of these libraries on a single destination’s codebase. Over time, the versions of these shared libraries began to diverge across the different destination codebases. The great benefit we once had of reduced customization between each destination codebase started to reverse. Eventually, all of them were using different versions of these shared libraries. We could’ve built tools to automate rolling out changes, but at this point, not only was developer productivity suffering but we began to encounter other issues with the microservice architecture.
7 years ago! I wonder what they’re doing now. but this passage caught my eye. Too often I see micro services just turn into pinned version shrines. Sure the rest of the app evolved and moved on but now you have traded the small expense of keeping thing up to date with decay and rot.
Quote Citation: Twilio, “Goodbye Microservices | Twilio”, July 10, 2018, https://www.twilio.com/en-us/blog/developers/best-practices/goodbye-microservices