From db464a0e830fd86aae3387724981049a4a4f66d0 Mon Sep 17 00:00:00 2001 From: Armon Dadgar Date: Fri, 25 Jul 2014 00:11:33 -0400 Subject: [PATCH] website: Documenting use cases --- website/source/intro/use-cases.html.markdown | 106 +++++++++++++++++++ website/source/layouts/intro.erb | 2 +- 2 files changed, 107 insertions(+), 1 deletion(-) create mode 100644 website/source/intro/use-cases.html.markdown diff --git a/website/source/intro/use-cases.html.markdown b/website/source/intro/use-cases.html.markdown new file mode 100644 index 000000000..011568db6 --- /dev/null +++ b/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. + diff --git a/website/source/layouts/intro.erb b/website/source/layouts/intro.erb index 68e1d9ff6..c31ed5bf1 100644 --- a/website/source/layouts/intro.erb +++ b/website/source/layouts/intro.erb @@ -7,7 +7,7 @@ > - Use Cases + Use Cases >