website: Documenting use cases
This commit is contained in:
parent
652c76500e
commit
db464a0e83
|
@ -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.
|
||||
|
|
@ -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") %>>
|
||||
|
|
Loading…
Reference in New Issue