View source for Applying Cloud Mindset to Continuous Delivery: Abundance over Scarcity

''' ''Effectively'' using the cloud for Continuous Delivery (CD) requires a new mindset - one that embraces ''abundance'' over scarcity. With the freedom that comes with abundance requires responsibility'''

== Motivations (Similar to Non-Cloud CD) ==  
* Reduce Cycle Time and Accelerate Feedback
* Fix problems faster; Troubleshoot more quickly
* Always be working off/in a known state - version-control should always represent the canonical source of the whole software system
* Get features to users quicker
* Reduce repetitive error-prone manual processes
* Reduce Infrastructure Costs

== Principles == 
* Abundance over Scarcity
* Reduce and Eliminate Assumptions
* Continually Validate the Source of Truth

== High-Level Practices == 
* Dispose Early and Often
* Recreate from Source
* Use Binaries to Speed Environment and Deployment Creation
== Patterns == 
* '''Ephemeral Environments''': Environments (instance ids, endpoints, etc.) exist per version-control revision in deployment pipeline. The concept of fixed environments (for example, Dev->QA->Staging->Production with fixed IP Addresses, endpoints, etc.) go away. The logical environments in a deployment pipeline (Commit->Acceptance->UAT->Load&Performance->Production) exist for the duration of a source code revision; then they get terminated and a new environment is added based on recent code changes. The [http://martinfowler.com/bliki/BlueGreenDeployment.html Blue/Green Deployment] pattern is a way to keep environments always up and running while embracing the Ephemeral Environment pattern.
* '''Software Systems as Code''': All software systems assets (ACID: Application Code, Configuration, Infrastructure, Data) are described in code, get committed to a version-control repository and move down the pipeline to be built, tested, and deployed
** Infrastructure gets "built" just like the application code
* '''Self-Service Deployments''': Any authorized team member can perform a Self-Service Deployments (w/ Environments) from any stage in the pipeline - from binary artifacts - without contacting a human
* '''Dynamic Configuration''': Many attributes contained in configuration files/databases in non-cloud environments can be dynamically obtained through tools like CloudFormation, Puppet, Chef, etc. so that they don't need to be hard-coded in config files for each environment type
* '''Disposable Environments''': Non-Production Environments are automatically terminated based on team policies. Open-source tools like [https://github.com/stelligent/cloudpatrol CloudPatrol] and [https://github.com/Netflix/SimianArmy/wiki/Janitor-Home Janitor Monkey] can assist with this. 
* '''Short-Lived Dev/Test Environments''' Responsible team members only use an environment for the duration of their test and then terminate it so that the team is no longer charged by the cloud provide for usage

== Antipatterns == 
* '''Fixed Environments''' (Keeping around environments with the same instance ids, endpoints) for multiple revisions, multiple days, etc. as a way to "conserve" time. repetition, "cost" 
* '''Stale Environments''' Similar to Fixed Environments, but when developers and other team members keep their environments around for more than a few days.
* '''Fragmented Automation''' - Various automation scripts and components used in creating/modifying environments or deployments at different times. Some might be automated, while others might be automated. The opposite of a Single Path to Production as part of a deployment pipeline. 
* '''Partial Deployments''' - Making deployment changes to existing environments as a way to reduce the time of deployment. The adverse effect is that the envrionment/system is in an unknown state making it difficult to troubleshoot problems. 
* '''Shared Environments''' - Multiple team members (Dev, QA, Ops, etc.) have access to a non-production environment as a way to manage resource usage. 
* '''Locking down Environments''' - As a way to control change to environments that are "works of art" - have been created through manual and/or automated means over a period of days, weeks or months. These environments are considered "scarce" and are often only modified by a few select people as a way to deal with change management and to reduce the risk that a change could detrimentally impact the system. This is an antipattern because environments are often in an unknown state and it presents bottlenecks for change. Locking down environments can be an effective when there's a team policy in which environments are only created through automated scripts and nothing else (see the pattern above).