Microservices should not be locked to specific versions

Microservices seldom run in a vacuum.

A business driven by microservices can have tens of services working together to meet business needs. These services coordinate and collaborate to enable the workflows necessary to run the business.

While this interaction is necessary, microservices must be loosely coupled. We want to retain the flexibility of changing and deploying each service independently as they grow over time. They should interact only over published APIs.

From a business's point of view, such changes must not affect operations or application availability. This often means that a microservice's public API should never break. APIs need to be forward compatible and backward compatible to be able to deploy microservices independently.

So a microservice should not be hard-linked to a specific version of another.

Doing so will lead to ripple effects across the ecosystem when a microservice needs redeployment. At the very least, it will require tighter coordination across multiple services, which destroys the gains that Microservices bring to the picture.

Microservices can still be versioned separately, allowing us to detect updates across the app landscape. We can choose to update and use a newer version only if and when necessary.

Sometimes, a core change makes a microservice's API incompatible with older versions.

However, these instances should be few and far between because the coordination effort can be draining. It also slows down the deployment cadence because of all the communication overhead.

Running two copies of a microservice to overcome the incompatibility issue temporarily can seem like a clever solution. It is cheap to spin up new services with most cloud infra providers. But the situation can quickly get cumbersome because these services may share data or accidentally double-process events. So it is best to always run a single version of a microservice and deal with any incompatibilities immediately.