website: Documenting use cases

Author: armon

website/source/intro/use-cases.html.markdown

@@ -0,0 +1,106 @@
+---
+layout: "intro"
+page_title: "Use Cases"
+sidebar_current: "use-cases"
+---
+
+# Use Cases
+
+Before understanding use cases, it's useful to know [what Terraform is](/intro/index.html).
+This page lists some concrete use cases for Terraform, but the possible use cases are
+much broader than what we cover. Due to it's extensible nature, providers and provisioners
+can be added to further extend Terraform's ability to manipulate resources.
+
+#### Heroku App Setup
+
+Heroku is a popular PaaS for hosting web apps. Developers create an app, and then
+attach add-ons, such as a database, or email provider. One of the best features it
+the ability to elastically scale the number of dynos or workers. However, most
+non-trivial applications quickly need many add-ons and external services.
+
+Terraform can be used to codify the setup required for a Heroku application, ensuring
+that all the required add-ons are available but it can go even further, configuring
+DNSimple to use an update CNAME, or setting up CloudFlare to act as a CDN for the
+app. Best of all, Terraform can do all of this without using a web interface in
+under 30 seconds.
+
+#### Multi-Tier Applications
+
+A very common pattern is the N-tier architecture. The most common 2-tier architecture is
+a pool of web servers that interface with a database tier. Extending this, additional
+tiers get added for API servers, caching servers, routing meshes, etc. This pattern is used
+because the tiers can be scaled indepedently and provide a seperation of concerns.
+
+Terraform is an ideal tool for building and managing these infrastructures. Each tier can
+be described as a collection of resources, and the depedencies between each tier is handled
+automatically; Terraform will ensure the database tier is available before the web servers
+are started and that the load balancers are aware of the web nodes. Each tier can then be
+scaled easily using Terraform by modifying a single `count` configuration value. Because
+the creation and provisioning of a resource is codified and automated, it becomes trivial
+to build autoscaling systems to elastically scale with load.
+
+#### Self-Service Clusters
+
+At a certain organizational size, it becomes very challenging for a centralized
+operations team to manage a large and growing infrastructure. Instead it becomes
+more attractive to make "self-serve" infrastructure, allowing product teams to
+manage their own infrastructure using tooling provided by the central operations team.
+
+Using Terraform, the knowledge of how to build and scale a service can be codified
+in a configuration. Terraform configurations can be shared within an organization
+enabling customer teams to use the configuration as a black box and use Terraform as
+a tool to manage their services.
+
+#### Software Demos
+
+Modern software is increasing networked and distributed. Although there exists
+tools like [Vagrant](http://www.vagrantup.com/) to build virtualized environments
+for demos, it is still very challenging to demo software on infrastructure providers
+which more closely match production environments or require a large number of nodes.
+
+Sofware writers can provide a Terraform configuration to create, provision and
+bootstrap a demo on cloud providers like AWS. This allows end users to easily demo
+the software on their own infrastructure, and even enables tweaking parameters like
+cluster size to more rigorously test tools at any scale.
+
+#### Disposable Environments
+
+It is common practice to have both a production and staging or QA environment.
+These environments are smaller clones of their production counterpart, but are
+used to test new applications before releasing in production. As the production
+environment grows larger and more complex, it becomes increasingly onerous to
+maintain an up-to-date staging environment.
+
+Using Terraform, the production environment can codified and then shared with
+staging, QA or dev. These configurations can be used to rapidly spin up new
+environments to test in, and then easily disposed of. Terraform can help tame
+the difficulty of maintaining parallel environments, and makes it practical
+to elastically create and destroy them.
+
+#### Software Defined Networking
+
+Software Defined Networking (SDN) is becoming increasingly prevalent in the
+datacenter, as it provides more control to operators and developers and
+allows the network to better support the applications running on top. Most SDN
+implementations have a control layer and infrastructure layer.
+
+Terraform can be used to codify the configuration for software defined networks.
+This configuration can then be used by Terraform to to automatically setup and modify
+settings by interfacing with the control layer. This allows configuration to be
+versioned and changes to be automated. As an example, [AWS VPC](http://aws.amazon.com/vpc/)
+is the largest deployments and commonly used SDN implementations, and [can be configured by
+Terraform](/docs/providers/aws/r/vpc.html).
+
+#### Resource Schedulers
+
+In large scale infrastructures, static assignment of applications to machines
+becomes increasingly challenging. To solve that problem, there are a number
+of schedulers like Borg, Mesos, YARN, and Kubernetes. These can be used to
+dynamically schedule Docker containers, Hadoop, Spark, and many other software
+tools.
+
+Terraform is not limited to physical providers like AWS. Resource schedulers
+can be treated as a provider, allowing Terraform to request resources from them.
+This allows Terraform to be used in layers: to setup the physical infrastructure
+running the schedulers as well as onto the scheduled grid.
+

website/source/layouts/intro.erb

@@ -7,7 +7,7 @@
                 </li>
 
 				<li<%= sidebar_current("use-cases") %>>
-				<a href="/intro/index.html">Use Cases</a>
+				<a href="/intro/use-cases.html">Use Cases</a>
 				</li>
 
 				<li<%= sidebar_current("vs-other") %>>