Application Upgrades
Service Fabric enables us to upgrade each service in an application independently, which is right in line with the notion of independently versionable and deployable microservices. Let’s assume we have an application with a stateless service that serves as the web front end, and a stateful service that serves as our back-end services. As we have learned, both services are referenced in the application manifest and each service has its own service manifest. Assume further that we have made updates to the backend service. In this case, we would only need to change the version number of the application itself and the version of the back-end service. The front-end service can remain unchanged and in its initial version.
The upgrade itself is done as a rolling upgrade. This means that the service is upgraded in stages. In each stage, the upgrade is applied to the nodes in a specific upgrade domain. By continuing upgrades in that manner, Service Fabric ensures that the service remains available throughout the process. Figure 8.9 shows the upgrade process of an application in Service Fabric Explorer, with the service in upgrade domain 0 completed and in upgrade domain 1 in progress.
During the entire upgrade, the process is monitored by default. The upgrade is performed on one upgrade domain, and if all health checks pass, moves on to the next upgrade domain automatically, and so on. If the health checks fail and/or timeouts are reached, the upgrade is rolled back for the upgrade domain.
More information on Service Fabric upgrades and health checks can be found here: https://azure.microsoft.com/en-us/documentation/articles/service-fabric-application-upgrade/.