diff --git a/website/source/intro/vs/boto.html.markdown b/website/source/intro/vs/boto.html.markdown new file mode 100644 index 000000000..c991fc740 --- /dev/null +++ b/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. + diff --git a/website/source/intro/vs/chef-puppet.html.markdown b/website/source/intro/vs/chef-puppet.html.markdown index d3f594bdc..1ed02ff64 100644 --- a/website/source/intro/vs/chef-puppet.html.markdown +++ b/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. diff --git a/website/source/intro/vs/cloudformation.html.markdown b/website/source/intro/vs/cloudformation.html.markdown new file mode 100644 index 000000000..9e3451487 --- /dev/null +++ b/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. + diff --git a/website/source/intro/vs/custom.html.markdown b/website/source/intro/vs/custom.html.markdown index 994304a24..244819e44 100644 --- a/website/source/intro/vs/custom.html.markdown +++ b/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. diff --git a/website/source/layouts/intro.erb b/website/source/layouts/intro.erb index c31ed5bf1..01b51cea1 100644 --- a/website/source/layouts/intro.erb +++ b/website/source/layouts/intro.erb @@ -15,6 +15,14 @@