In a traditional environment, you cannot have multiple versions of the same service up and running at the same time unless some routing is built at the application layer.

However, in the preceding example, we have three versions of the Reviews microservice up and running at the same time. Since this application is running within a Kubernetes environment with network service definitions, it is possible to have multiple versions of the same microservice up and running. However, the traffic to each microservice is random, and we don't know which microservice will be receiving the traffic.

You can think of it this way: you have a frontend web application already running stable but not using modern web UI capabilities. You want to enable another web UI frontend with a handful of customers without affecting others. This type of selective rollout fits very well in the Continuous Improvement and Continuous Development strategy. The requirement is that we should be able to do this without having to write any piece of code.

Traditional application development requires engineers to write some form of source code because that is the de facto development methodology. When you're considering a cloud-native framework, things are shifting to operations staff who can manage rules and policies without any code changes.

To explore BookInfo further, let's look at the deployed pods, services, and overall availability of the different services within this application.