In Part I of "How Can the Cloud Improve your App's Quality?", we examined how the cloud helps with Performance, Features, Reliability and Conformance. In Part II we’ll describe the positive effects of the cloud on Durability, Serviceability, Aesthetics and Perceived Quality.
Durability measures the length of a product’s life. When the product can be repaired, estimating durability is more complicated, as the item will be used until it is no longer economical to operate it.
The secret to durability is replaceable parts. A typical spark plug lasts 10000 to 20000 miles. A car lasts much longer - as long as you replace the spark plugs, the oil, the tires, the brakes, and other parts. When the spark plug reaches the end of its expected life, it is replaced, not repaired.
It should work the same with servers. Servers, especially on the cloud, are supposed to be identical commodities. While there are a few types of servers - web servers, database servers, app X servers, servers of the same type should be identical. Thus if a server stops behaving correctly, it should be easier to replace it than to fix it.
Servers that are easily destroyed and replaced are called Phoenix Servers. We recommend phoenixing servers often, rather than waiting for them to break. You don't wait until your car stops moving to replace the oil. Why should you wait until your website is down to replace old web servers?
This process isn't just about hardware. It's about resetting "configuration drift" - changes over time that differentiate servers that should be identical. Sometimes this happens even if you're using automated infrastructure tools like Puppet or Chef. Do older servers only have your current tech stack like the new ones, or do they have some remnants of old software you forgot to purge?
Serviceability is the speed with which the product can be put into service when it breaks down, as well as the competence and the behavior of the serviceperson.
The cloud is incredibly serviceable, and enables us to build the most serviceable IT products and systems ever created. Again, the self-service characteristic of the cloud is extremely important, as is resource pooling. If we need to perform a change or maintenance on a resource, we can simply remove it from the pool, perform the maintenance, and then put it back.
1. Reduce downtime and avoid 3 am deploy windows...
Techniques like Blue/Green deployments are easy on the cloud. This is a deployment strategy where you have a load-balancer with two pools: blue and green. Only one pool is active at a time, and you can do zero-downtime deployments by switching between them. So, if the blue pool is active, you deploy your changes into the inactive green pool. Once you've done some smoke testing of the green servers, you can deactivate the blue pool and activate the green pool. If there is any downtime at all, it should be about one second. You than watch your monitoring systems and user feedback for any signs of trouble. At the first sign of trouble you just switch back to the blue pool. Again, this takes about one second. You haven't rolled back and lost your green changes - you're just buying some time so you can investigate. If you determine that it is a minor problem or a false alarm, you can give the green pool another shot.
2....Or consider spinning up an entire replacement
The blue/green pattern is one of the easiest zero-downtime deployment systems to visualize and implement, but there are many options. Some organizations do a similar system to blue/green, but by switching over to their Disaster Recovery site. A nice benefit of this approach is it exercises some of your Disaster Recovery processes and equipment every deployment - something that many business let slip. The canary deployment pattern is a technique that even redefines what "production" and "the production version" mean. If you have a cluster of servers, you could release the next version to just one of them. You watch it (like a canary in a coal mine) for any problems, and rollback if required. If there are no problems, you can continue rolling out the new release incrementally - 10%, 25%, 50%, 80% and finally 100% of your servers. These strategies do not require complex and error prone manual workflows.
3. The cloud is highly controllable, with multi-cloud SDKs in many programming languages and tools available from popular vendors like PuppetLabs, OpsCode, Ansible, and HashiCorp.
Most cloud providers give you a powerful API to control your resources. Often you can even choose your favorite set of languages and tools - Rackspace, for example, supports SDKs in Ruby, Java, .NET, Node.js, Python and PHP. Do not underestimate the power of doing deployments using scripts your dev and ops teams understand, and deploying at 3PM instead of 3AM so the team that created the changes is around to support their launch.
Aesthetics is the subjective dimension indicating the kind of response a user has to a product. It represents the individual’s personal preference. Okay, so the cloud does little to make your site look good. However, cloud environments and services are still powerful tools to refine the aesthetics of your application.
As it is so easy to spin up an environment with the cloud, you can easily create one to showcase a proposed visual or UX change.
If you are building a website, especially a mobile site, then a major challenge is making sure the aesthetics are good not just for your laptop, but for each browser and device used by your users. Cloud testing tools make it easy to compare aesthetics across devices. If you create a preview environment you can employ the broad network access cloud services like mogotest, Browsershots, Browserstack or Cross Browser Testing. You could also build your own system on the cloud, using tools like Selenium, Huxley, or dpxdt.
#8 Perceived Quality
[x] May matter for IT departments or IT customers - [x] Conclusion (how do the above change users perception)
Perceived Quality is the quality attributed to a good or service based on indirect measures such as the product's “history”. Your site might be bug free right now, but if you've had a lot of problems in the past your users may still feel it is a low-quality site. It's also not just about the number of problems you had, but how quickly you’ve fixed them.
The cloud, combined with continuous delivery, makes it easier to quickly reproduce, fix, and release a bugfix. It also makes it easier to quickly release new features and improvements based on user feedback.
This rapid turnaround time on both bugs and enhancements is what really gives users a perception of quality. Increasing the perception of quality is key to making your users feel like partners and promoting the growth of your product through customer referrals.
The cloud and the 8 dimensions
I strongly believe that by developing, testing, and deploying to the cloud you can build higher quality products. The ability to build a product with a high-level of quality in all 8 dimensions may not be unique to the cloud, but the cloud helps in removing any barriers that were preventing you from achieving these goals.
1. Amazon found every 100ms of latency cost them 1% in sales. ↩
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.