website: vs pages

website/source/intro/vs/boto.html.markdown

@@ -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.
+

website/source/intro/vs/chef-puppet.html.markdown

@@ -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.

website/source/intro/vs/cloudformation.html.markdown

@@ -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.
+

website/source/intro/vs/custom.html.markdown

@@ -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.
 

website/source/layouts/intro.erb

@@ -15,6 +15,14 @@
 				<ul class="nav">
 					<li<%= sidebar_current("vs-other-chef") %>>
 					<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") %>>