github.com/wikibal01/hashicorp-terraform@v0.11.12-beta1/website/intro/use-cases.html.markdown (about)

     1  ---
     2  layout: "intro"
     3  page_title: "Use Cases"
     4  sidebar_current: "use-cases"
     5  description: |-
     6    Before understanding use cases, it's useful to know what Terraform is. This page lists some concrete use cases for Terraform, but the possible use cases are much broader than what we cover. Due to its extensible nature, providers and provisioners can be added to further extend Terraform's ability to manipulate resources.
     7  ---
     8  
     9  # Use Cases
    10  
    11  Before understanding use cases, it's useful to know [what Terraform is](/intro/index.html).
    12  This page lists some concrete use cases for Terraform, but the possible use cases are
    13  much broader than what we cover. Due to its extensible nature, providers and provisioners
    14  can be added to further extend Terraform's ability to manipulate resources.
    15  
    16  ## Heroku App Setup
    17  
    18  Heroku is a popular PaaS for hosting web apps. Developers create an app, and then
    19  attach add-ons, such as a database, or email provider. One of the best features is
    20  the ability to elastically scale the number of dynos or workers. However, most
    21  non-trivial applications quickly need many add-ons and external services.
    22  
    23  Terraform can be used to codify the setup required for a Heroku application, ensuring
    24  that all the required add-ons are available, but it can go even further: configuring
    25  DNSimple to set a CNAME, or setting up Cloudflare as a CDN for the
    26  app. Best of all, Terraform can do all of this in under 30 seconds without
    27  using a web interface.
    28  
    29  ## Multi-Tier Applications
    30  
    31  A very common pattern is the N-tier architecture. The most common 2-tier architecture is
    32  a pool of web servers that use a database tier. Additional tiers get added for API servers,
    33  caching servers, routing meshes, etc. This pattern is used because the tiers can be scaled
    34  independently and provide a separation of concerns.
    35  
    36  Terraform is an ideal tool for building and managing these infrastructures. Each tier can
    37  be described as a collection of resources, and the dependencies between each tier are handled
    38  automatically; Terraform will ensure the database tier is available before the web servers
    39  are started and that the load balancers are aware of the web nodes. Each tier can then be
    40  scaled easily using Terraform by modifying a single `count` configuration value. Because
    41  the creation and provisioning of a resource is codified and automated, elastically scaling
    42  with load becomes trivial.
    43  
    44  ## Self-Service Clusters
    45  
    46  At a certain organizational size, it becomes very challenging for a centralized
    47  operations team to manage a large and growing infrastructure. Instead it becomes
    48  more attractive to make "self-serve" infrastructure, allowing product teams to
    49  manage their own infrastructure using tooling provided by the central operations team.
    50  
    51  Using Terraform, the knowledge of how to build and scale a service can be codified
    52  in a configuration. Terraform configurations can be shared within an organization
    53  enabling customer teams to use the configuration as a black box and use Terraform as
    54  a tool to manage their services.
    55  
    56  ## Software Demos
    57  
    58  Modern software is increasingly networked and distributed. Although tools like
    59  [Vagrant](https://www.vagrantup.com/) exist to build virtualized environments
    60  for demos, it is still very challenging to demo software on real infrastructure
    61  which more closely matches production environments.
    62  
    63  Software writers can provide a Terraform configuration to create, provision and
    64  bootstrap a demo on cloud providers like AWS. This allows end users to easily demo
    65  the software on their own infrastructure, and even enables tweaking parameters like
    66  cluster size to more rigorously test tools at any scale.
    67  
    68  ## Disposable Environments
    69  
    70  It is common practice to have both a production and staging or QA environment.
    71  These environments are smaller clones of their production counterpart, but are
    72  used to test new applications before releasing in production. As the production
    73  environment grows larger and more complex, it becomes increasingly onerous to
    74  maintain an up-to-date staging environment.
    75  
    76  Using Terraform, the production environment can be codified and then shared with
    77  staging, QA or dev. These configurations can be used to rapidly spin up new
    78  environments to test in, and then be easily disposed of. Terraform can help tame
    79  the difficulty of maintaining parallel environments, and makes it practical
    80  to elastically create and destroy them.
    81  
    82  ## Software Defined Networking
    83  
    84  Software Defined Networking (SDN) is becoming increasingly prevalent in the
    85  datacenter, as it provides more control to operators and developers and
    86  allows the network to better support the applications running on top. Most SDN
    87  implementations have a control layer and infrastructure layer.
    88  
    89  Terraform can be used to codify the configuration for software defined networks.
    90  This configuration can then be used by Terraform to automatically setup and modify
    91  settings by interfacing with the control layer. This allows configuration to be
    92  versioned and changes to be automated. As an example, [AWS VPC](https://aws.amazon.com/vpc/)
    93  is one of the most commonly used SDN implementations, and [can be configured by
    94  Terraform](/docs/providers/aws/r/vpc.html).
    95  
    96  ## Resource Schedulers
    97  
    98  In large-scale infrastructures, static assignment of applications to machines
    99  becomes increasingly challenging. To solve that problem, there are a number
   100  of schedulers like Borg, Mesos, YARN, and Kubernetes. These can be used to
   101  dynamically schedule Docker containers, Hadoop, Spark, and many other software
   102  tools.
   103  
   104  Terraform is not limited to physical providers like AWS. Resource schedulers
   105  can be treated as a provider, enabling Terraform to request resources from them.
   106  This allows Terraform to be used in layers: to setup the physical infrastructure
   107  running the schedulers as well as provisioning onto the scheduled grid.
   108  
   109  ## Multi-Cloud Deployment
   110  
   111  It's often attractive to spread infrastructure across multiple clouds to increase
   112  fault-tolerance. By using only a single region or cloud provider, fault tolerance
   113  is limited by the availability of that provider. Having a multi-cloud deployment
   114  allows for more graceful recovery of the loss of a region or entire provider.
   115  
   116  Realizing multi-cloud deployments can be very challenging as many existing tools
   117  for infrastructure management are cloud-specific. Terraform is cloud-agnostic
   118  and allows a single configuration to be used to manage multiple providers, and
   119  to even handle cross-cloud dependencies. This simplifies management and orchestration,
   120  helping operators build large-scale multi-cloud infrastructures.