ResiLien
/
terraform
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

website: vs pages

This commit is contained in:
Armon Dadgar 2014-07-25 12:53:06 -04:00
parent f9f61268e9
commit cc6e7f12e8
5 changed files with 105 additions and 46 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
website/source/intro/vs/boto.html.markdown Normal file
View File

@ -0,0 +1,22 @@
---
layout: "intro"
page_title: "Terraform vs. Boto, Fog, etc."
sidebar_current: "vs-other-boto"
---
# Terraform vs. Boto, Fog, etc.
Libraries like Boto, Fog, etc. are used to provide native access
clients to cloud providers and services by using their APIs. Some
libraries are focused on specific clouds, while others attempt
to bridge them all and mask the semantic differences. Using a client
library only provides low-level access to APIs, requiring application
developers to build their own tooling to build and manage their infrastructure.
Terraform is not intended to give low-level programmatic access to
providers, but instead provides a high level syntax for describing
how cloud resources and services should be created, provisioned, and
combined. It acts as a feature rich and flexible tool, using a
a plugin-based model to support providers and provisioners, giving
it the ability to support almost any service that exposes APIs.

42
website/source/intro/vs/chef-puppet.html.markdown
View File

@ -6,37 +6,15 @@ sidebar_current: "vs-other-chef"
# Terraform vs. Chef, Puppet, etc.
It is not uncommon to find people using Chef, Puppet, and other configuration
management tools to build service discovery mechanisms. This is usually
done by querying global state to construct configuration files on each
node during a periodic convergence run.
Configuration management tools install and manage tools on a machine
that already exists. Terraform is not a configuration management tool,
and uses the existing tooling to do what they do best: bootstrap and initialize resources.
Unfortunately, this approach has
a number of pitfalls. The configuration information is static,
and cannot update any more frequently than convergence runs. Generally this
is on the interval of many minutes or hours. Additionally, there is no
mechanism to incorporate the system state in the configuration. Nodes which
are unhealthy may receive traffic exacerbating issues further. Using this
approach also makes supporting multiple datacenters challenging as a central
group of servers must manage all datacenters.
Using provisioners, Terraform allows any configuration management tool
to be used to setup a resource once it has been created. Terraform
focuses on the higher-level abstraction of the datacenter and associated
services, without sacrificing the ability to use configuration management
tools to do what they do best. It also embraces the same codification that
is responsible for the success of those tools, making entire infrastructure
deployments just as easy and reliable.
Terraform is designed specifically as a service discovery tool. As such,
it is much more dynamic and responsive to the state of the cluster. Nodes
can register and deregister the services they provide, enabling dependent
applications and services to rapidly discover all providers. By using the
integrated health checking, Terraform can route traffic away from unhealthy
nodes, allowing systems and services to gracefully recover. Static configuration
that may be provided by configuration management tools can be moved into the
dynamic key/value store. This allows application configuration to be updated
without a slow convergence run. Lastly, because each datacenter runs indepedently,
supporting multiple datacenters is no different than a single datacenter.
That said, Terraform is not a replacement for configuration management tools.
These tools are still critical to setup applications and even to
configure Terraform itself. Static provisioning is best managed
by existing tools, while dynamic state and discovery is better managed by
Terraform. The separation of configuration management and cluster management
also has a number of advantageous side effects: Chef recipes and Puppet manifests
become simpler without global state, periodic runs are no longer required for service
or configuration changes, and the infrastructure can become immutable since config management
runs require no global state.

38
website/source/intro/vs/cloudformation.html.markdown Normal file
View File

@ -0,0 +1,38 @@
---
layout: "intro"
page_title: "Terraform vs. CloudFormation, Heat, etc."
sidebar_current: "vs-other-cloudformation"
---
# Terraform vs. CloudFormation, Heat, etc.
Tools like CloudFormation, Heat, etc allow the details of an infrastructure
to be codified into a configuration file. The configuration files allow
the infrastructure to be elastically created, modified and destroyed. Terraform
is inspired by the problems they solve.
Terraform similarly uses configuration files to detail the infrastructure
setup, but it goes further, by being both cloud agnostic and enabling
multiple providers and services to be combined and composed. For example,
Terraform can be used to orchestrate an AWS and OpenStack cluster simultaneously,
while enabling 3rd party services like CloudFlare and DNSimple to be integrated
to provide CDN and DNS services. This enables Terraform to represent and
manage the entire infrastructure and it's supporting services, instead of
only the subset that exists within a single provider. It provides a single
unified syntax, instead of requiring operators to use independent and
non-interoperable tools for each platform and service.
Terraform also seperates the planning phase from the execution phase,
by using the concept of an execution plan. By running `terraform plan`,
the current state is refreshed and the configuration is consulted to
generate an action plan. The plan includes all actions to be taken:
which resources will be created, destroyed or modified. It can be
inspected by operators to ensure it is exactly what is expected. Using
`terraform graph`, the plan can be visualized to show dependent ordering.
Once the plan is captured, the execution phase can be limited to only
the actions in the plan. Other tools combine the planning and execution
phases, meaning operators are forced to mentally reason about the effects
of a change, which quickly becomes intractable in large infrastructures.
Terraform lets operators apply changes with confidence, as they know exactly
what will happen before running.

41
website/source/intro/vs/custom.html.markdown
View File

@ -6,20 +6,33 @@ sidebar_current: "vs-other-custom"
# Terraform vs. Custom Solutions
As a code base grows, a monolithic app usually evolves into a Service Oriented Architecture (SOA).
A universal pain point for SOA is service discovery and configuration. In many
cases, this leads to organizations building home grown solutions.
It is an undisputed fact that distributed systems are hard; building one is error prone and time consuming.
Most systems cut corners by introducing single points of failure such
as a single Redis or RDBMS to maintain cluster state. These solutions may work in the short term,
but they are rarely fault tolerant or scalable. Besides these limitations,
they require time and resources to build and maintain.
Most organizations start by manually managing infrastructure though
simple scripts or web based interfaces. As the infrastructure grows,
any manual approach to management becomes both error prone and tedious.
As a result, many organizations begin to home-roll tooling to help
automate the mechanical processes involved.
Terraform provides the core set of features needed by a SOA out of the box. By using Terraform,
organizations can leverage open source work to reduce their time and resource commitment to
re-inventing the wheel and focus on their business applications.
These tools require time and resources to build and maintain.
As tools of necessity, they represent the minimum viable
features needed by an organization, being built to handling only
the immediate needs. As a result they are often hard
to extend and difficult to maintain. Because the tooling must be
updated in lock step with any new features or infrastructure,
it becomes the limiting factor for how fast infrastructure
can evolve.
Terraform is built on well-cited research, and is designed with the constraints of
distributed systems in mind. At every step, Terraform takes efforts to provide a robust
and scalable solution for organizations of any size.
Terraform is designed to tackle these challenges. It provides a simple
unified syntax, allowing almost any resource to be managed without
learning new tooling. By capturing all the resources required, the
dependencies between them can be resolved automatically so that operators
do not need to remember and reason about them. Removing the burden
of building the tool allows operators to focus on their infrastructure
and not the tooling.
Additionally, Terraform is an open source tool. In addition to
HashiCorp, the community around it helps to extend it's features,
fix bugs and document new use cases. Terraform helps solve a problem
that exists in every organization and provides a standard that can
be adopted to avoid re-inventing the wheel between and within organizations.
It's open source nature ensures it will be around in the long term.

8
website/source/layouts/intro.erb
View File

@ -17,6 +17,14 @@
<a href="/intro/vs/chef-puppet.html">Chef, Puppet, etc.</a>
</li>
<li<%= sidebar_current("vs-other-cloudformation") %>>
<a href="/intro/vs/cloudformation.html">CloudFormation, Heat, etc.</a>
</li>
<li<%= sidebar_current("vs-other-boto") %>>
<a href="/intro/vs/boto.html">Boto, Fog, etc.</a>
</li>
<li<%= sidebar_current("vs-other-custom") %>>
<a href="/intro/vs/custom.html">Custom Solutions</a>
</li>