That’s right; this is what else she writes:
Versioning of internal libraries and/or microservices and pinning to specific versions of internal libraries and/or services is very much discouraged in micro‐ service architecture because it tends to lead to bugs and (in extreme cases) serious failures, because of the fast-paced nature of microservice development: these libraries and services are constantly changing, and pinning to specific versions (along with versioning of these services and libraries in general) can lead to developers using unstable, unreliable, and sometimes unsafe versions of them.
Logging Without Microservice Versioning
Microservice versioning is often discouraged because it can lead to other (client) services pinning to specific versions of a microservice that may not be the best or most updated version of the microservice. Without versioning, determining the state of a microservice when a failure or outage occurred can be difficult, but thorough logging can prevent this from becoming a problem: if the logging is good enough that state of a microservice at the time of an outage can be sufficiently known and understood, the lack of versioning ceases to be a hindrance to quick and effective mitigation and resoution.
My intent with this post isn’t to argue against versioning, but rather to share unexpected advice from a credible book. If I were to argue against versioning, though, I’d add that:
* Supporting backward compatible APIs necessarily leads to more complicated, difficult to maintain, code.
* The traditional approach to versioning APIs is often to also strive to limit breaking changes. I’ve even seen people argue against ever making such changes. It’s easy to imagine this stunting the growth of an API and its associated product.
* Although microservices provide modularization just like traditionally versioned libraries, there are some important differences. Libraries, in the most general sense, are often:
A) Downloaded and compiled into a monolith, which is then stuck with that version of the library, bugs and all, until the monolith is manually upgraded.
B) Used by numerous, unrelated, projects.
Given this distribution and usage model, versioning libraries makes perfect sense. The extent to which microservices are used to offer modularity exclusively within a single application, however, is the degree to which traditional assumptions about the need for versioning can be revisited.