anchor.diff:  
   <%=vars.pcf_pools%>
   
  -<%=vars.om_resurrector_header%>
  -<%=vars.om_resurrector_text%>
  +#### <a id='databases'></a>Databases ####
   
  +For database services deployed outside Cloud Foundry, plan to leverage your infrastructure's high availability features and to configure backup and restore where possible. <%= vars.scaling_ert_db %>
   
  -### <a id='databases'></a>Databases ###
  -
  -For scaling internal database components, <%= vars.scaling_ert %>. For database services deployed outside Cloud Foundry, plan to leverage your infrastructure's high availability features and to configure backup and restore where possible.
  +<p class="note"><strong>Note</strong>: Data services may have single points of failure depending on their configuration.</p>
   
   <%= vars.contact_support %>
   
  
positive.code: 
  <%= image_tag("scale_cf.png", :height => "450px", :width => "475px") %>
  
  ### <a id='tradeoffs'></a>Trade-offs and Benefits ###
  
  The nature of a particular application should determine whether you scale vertically or horizontally.
  
  **Diego Cells**:
  
  The optimal sizing and CPU/memory balance depends on the performance characteristics of the apps that will run on the Diego Cell. Larger Diego Cells also make for larger points of failure: the system takes longer to rebalance 100 app instances than to rebalance 20 app instances.
  
  **Router**:
  
  Scale the router with the number of incoming requests. In general, this load is much less than the load on Diego Cells.
  
  **Cloud Controller**:
  
  Scale the Cloud Controller with the number of requests to the API and with the number of apps in the system.
  
  
  ## <a id='zero-downtime'></a>High Availability and Zero Downtime ##
  
negative.code: 
  ### Supporting Component Scaling
  
  <%=vars.om_resurrector_header%>
  <%=vars.om_resurrector_text%>
  
  ####Setting `max_in_flight` values ####
  
  For each component, the `max_in_flight` variable limits how many instances of that component are restarted simultaneously during updates or upgrades. This variable can be any integer between 1 and 100. Values for `max_in_flight` are set in the manifest, and you can override them with the TK command.
  
  To ensure zero downtime during updates, set this variable to a number low enough to prevent overburdening the component instances left running. Here are some guidelines:
  
  - For Diego cells, the closer their resource usage is to 100%, the lower you should set `max_in_flight`, to allow non-migrating cells to pick up the work of cells stopping and restarting for migration. If resource usage is already close to 100%, scale your Diego cells up before any upgrades.
  - For quorum-based components (etcd, consul, and Diego BBs), guidelines TK.
  - For other components, guidelines TK.
  
  ####Capacity####
  
  Ensure that you allocate and maintain enough of the following:
  
  * Free space on Diego cells so that apps expected to deploy can successfully be staged and run.
  * Disk space and memory in your deployment such that if one Diego cell is down, all instances of apps can be placed on the remaining Diego cells.
  * Free space to handle one AZ going down if deploying in multiple AZs.
  
  ####Resource pools####
  