Most services have multiple instances running in production. The load-balancing mechanisms might direct a call for service to any instance. Thus, during a rollout, two versions of the service must coexist—say, vN and vN+1. Callers to vN must be able to call vN +1 and get equivalent behavior. Similarly, vN +1 calls to other (older) services must demand no more than what vN did.
So, assuming a steady state system with no rollouts currently underway, we might have the following:
Note that client and server are just to indicate who initiates the call (caller) and who receives the call (callee). Furthermore, the client or server might be a partner that is not part of your feature team or part of your product. Note that the same is true when the communication is more indirect via shared data stores (for example, log writers/readers)—only even more complicated, as Y can "communicate with itself" via a data store from which it reads and writes (for example, persistent state). So, think also about your partner consumers and producers.
During rollout of service Y from vN to vN +1 (denoted as Y+), we have for the service-message protocols the following:
Typically, changing only Y means that there is no protocol change, because neither the caller (X) nor the callee (Z) of Y has changed. However, Y+ might rollout with a protocol change in anticipation of future or concurrent (as shown later) rollouts of X or Z.
Protocols can be updated in myriad ways. Two common update methods are transparent extension (compatible evolution) and explicit versioning (big bang). Transparent extension can occur by adding optional parameters. For example, say that X can send only three parameters to Y, and Y can return only two. Y+ must return only the same two parameters when dealing with X, but it can allow an optional fourth parameter (typically, coming only from X+). If it receives an optional fourth parameter, it can then return three parameters.
Note Some protocols are built to "ignore" extra parameters—allowing Y+ to return excess parameters to X. However, with such "lazy" protocols, there are security implications.
Similarly, Y might be allowed to send only two parameters to Z, but Y+ might be built to accept an optional third parameter from Z (typically, a Z+1 version). Explicit versioning means that the collection of messages between two services is collected under a single version umbrella (for example, a versioned namespace). Changing any message means creation of a new version of the collection of messages. Typically, the start of a conversation between services identifies the version of the messages that are to be exchanged. It is possible also just to version every message.
For more coverage about this topic, see "5.2 Web Service Versioning" (http://www.w3.org/TR/wsdl20-primer/#adv-versioning) in the W3 working group WSDL 2.0 primer.
With data sharing, typically, Y+ might be rolled out able to "understand" new XY or ZY formats, but the only format to which it can change immediately might be the vN+1 format of its own data store.
How the versioning is done depends on the data-flow relationship. If Y merely is writing a log file, Y+ might intermix new (versioned) log records (assuming that the log reader is updated before or during the rollout!) into the same data store. If each instance of Y stores some independent state (for example, a cache), the Y would read/write to its store in vN format, while Y+ could read/write to its sore in vN+1 format. In rarer cases, the format is extensible, such that Y ignores extra or changed data in vN+1 formats. Y+ also might be rolled out with the vN+1 format disabled; then, after all instances are upgraded to Y+, a configuration change is used to allow vN+1 writing.
However, the preceding is just too easy. Frequently, along with your service Y, the surrounding services X and Z might be rolled out also as part of the release train. In this case, the situation looks something more like the following:
In that case, the explicit versioning model, X/Y, X/Y+, and X+/Y all would use version N of the protocol, while X+/Y+ could use a totally different N+1 version of the protocol. Similarly, Y/Z, Y+/Z, and Y/Z+ would use version M of their protocol, while Y+/Z+ could use a totally different M+1 version of their protocol.
Additionally, as alluded to earlier, it is possible for data formats to change as a release train rolls out. You must think about the producer and consumers of data in the same rollout.
A phased rollout should make sure that all data consumers are rolled out prior to data producers.