The Quality of Service (QoS) depends on, not just the technical quality of code & documentation, but also deployment architecture & instructions, health monitoring, operational procedures, integration into hybrid scenarios, and downtime minimization thru redundancy, virtualization, and disaster recovery. In the on-premises world, there is limited incentive for the development team to optimize deployment time. Not that upgrade duration doesn't matter, but there are other priorities dominating trade-off decisions. In the Cloud world, we look to minimize required service interruptions to update the environment. Through clustering, service delivery runtime environments, etc, we can ensure system availability through many upgrades, but there are some changes that still require a planned outage, such as back-end database schema changes. A highly available (HA) system has redundancy built in, so in the event of a failure the redundant part will take over. When it comes to performing system maintenance and updates, such a HA system needs to be maintainable in a continuously available (CA) fashion. HA is automated, while CA still requires human practice to ensure the correct steps are executed in the correct sequence during CA updates. The ease of deploying the update, and the time it takes, is what I refer to as deployability, and it has renewed importance in the cloud. Both the technical complexity of the update, and the skills of the deployment team, matter. A team that has gone through the same deployment several times can execute it quicker than a team doing the deployment for the first time, and they are less likely to execute deployment steps in an incorrect sequence or to miss a check. For that reason, I like to see the production deployment team participate in earlier deployments into the customer acceptance test environment, and into the staging environment ahead of the actual Go Live date in the production environment. Interestingly, engaging the Web Delivery Operations (production) team in updating pre-release environments has the added side benefit of exposing any differences between production and test environments, which we want to eliminate as discussed in Cloud Difference #4: Test emulates the production environment. Automation of complete, virtualized service deployments is key to minimizing the opportunities for human error during updates. In addition, we require interim builds to be delivered and deployed into test environments using the same techniques that will be used in the production deployment. And although rare, in case a deployment runs into problems, we require a back-out option that will allow us to quickly fall back to the last known good configuration and release. An alternative option is to deploy on separate hardware and cut over traffic from the load balancers once the new instance is up and running. This can in many cases eliminate the concern over deployment time and back-out options, but suitable hardware is not always available because of the associated cost. So a well tested, well rehearsed, automated and well executed deployment remains important.
PS: To sort the blog and display just the ‘Cloud Difference’ series, click on the “cloud_difference” tag below the title of any post in the series.