Adds docs for Getting started

Author: beingadityak

README.md

@@ -17,7 +17,7 @@ Terraform Labs brings you tutorials that help you get hands-on experience using
 
 # Terraform Workshop/Labs
 
-- [Getting Started: Why, What & How about Terraform?]() - Not Started
+- [Getting Started: Why, What & How about Terraform?](getting-started/README.md) - In Progress
 
 - [Beginners Track](https://github.com/collabnix/terraform/blob/master/beginners/README.md) - In-Progress
 

getting-started/README.md

@@ -0,0 +1,10 @@
+# Getting Started - Terraform
+
+This section is all about how to get started with Terraform - what is it & why it is needed.
+
+Following topics are covered in this section:
+
+- [The problem of provisioning everything manually](the-problem.md)
+- [The concept of Infrastructure as a Code (IaC)](iac.md)
+- [Where terraform comes in?](terraform.md)
+- [Use cases of Terraform](use-cases.md)

getting-started/iac.md

@@ -0,0 +1,17 @@
+# The Concept of Infrastructure as a Code (IaC)
+
+Infrastructure as a Code (IaC), as the name suggests, is a way of managing your entire infrastructure in the form of code. It helps us to solve several problems such as:
+
+1. **Reproducible Environments:** By using code to generate infrastructure, the same environment can be created over and over. Over time an environment can drift away from its desired state and difficult to diagnose issues can creep into your release pipeline. With IaC no environment gets special treatment and fresh new environments are easily created and destroyed.
+
+2. **Idempotence & Convergence:** In IaC, only the actions needed to bring the environment to the desired state are executed. If the environment is already in the desired state, no actions are taken.
+
+3. **Easing Collaboration:** Having the code in a version control system like Git allows teams to collaborate on infrastructure. Team members can get specific versions of the code and create their own environments for testing or other scenarios.
+
+4. **Self-service Infrastructure:** A pain point that often existed for developers before moving to cloud infrastructure was the delays required to have operations teams create the infrastructure they needed to build new features and tools. With the elasticity of the cloud allowing resources to be created on-demand, developers can provision the infrastructure they need when they need it. IaC further improves the situation by allowing developers to use infrastructure modules to create identical environments at any point in the application development lifecycle. The infrastructure modules could be created by operations and shared with developers freeing developers from having to learn another skill.
+
+All combined these benefits make IaC a staple in DevOps practices.
+
+***
+
+[< Previous](the-problem.md) [Next >](terraform.md)

getting-started/terraform.md

@@ -0,0 +1,21 @@
+# Enter Terraform
+
+**Terraform is a tool for building, changing, and versioning infrastructure safely and efficiently.** Terraform can manage existing and popular service providers as well as custom in-house solutions.
+
+Configuration files describe to Terraform the components needed to run a single application or your entire datacenter. Terraform generates an _execution plan_ describing what it will do to reach the desired state, and then executes it to build the described infrastructure. As the configuration changes, Terraform is able to determine what changed and create incremental execution plans which can be applied.
+
+The infrastructure Terraform can manage includes low-level components such as compute instances, storage, and networking, as well as high-level components such as DNS entries, SaaS features, etc.
+
+Following are the key features of Terraform:
+
+1. **Infrastructure as a Code:** As discussed earlier, Infrastructure is described using a high-level configuration syntax. This allows a blueprint of your datacenter to be versioned and treated as you would any other code. Additionally, infrastructure can be shared and re-used.
+
+2. **Execution Plans:** Terraform has a "planning" step where it generates an _execution plan_. The execution plan shows what Terraform will do when you call apply. This lets you avoid any surprises when Terraform manipulates infrastructure.
+
+3. **Resource Graph:** Terraform builds a graph of all your resources, and parallelizes the creation and modification of any non-dependent resources. Because of this, Terraform builds infrastructure as efficiently as possible, and operators get insight into dependencies in their infrastructure.
+
+4. **Change Automation:** Complex changesets can be applied to your infrastructure with minimal human interaction. With the previously mentioned execution plan and resource graph, you know exactly what Terraform will change and in what order, avoiding many possible human errors.
+
+***
+
+[< Previous](iac.md) [Next >](use-cases.md)

getting-started/the-problem.md

@@ -0,0 +1,16 @@
+# The problem of provisioning everything manually
+
+Whenever we have the need to setup any infrastructure we always tend to go towards the manual approach by clicking and going through the steps in the UI provided by the major public cloud provider (AWS, Azure, GCP), cloud provider (Linode, DigitalOcean etc.), DNS provider (CloudFlare, Route53, DNSimple etc.) and many such services.
+
+One way to approach this problem is to use scripts. But with that comes another set of challenges such as:
+
+- They're idiosyncratic - if I wrote a script, the other person might not be able to understand the steps being performed.
+- They're not idempotent - if I ran the script multiple times, it might not provide me the same result.
+- Compatibility issues - if I developed the script on a Linux machine, the other person who is using Windows might not be able to use the script and vice versa.
+- The scripts are only for one task. If you want to deploy something else, you need to develop them again.
+
+So, how to automate the setup process without having to deal with the hassles of developing a script? That's where the concept of Infrastructure as a Code (IaC) comes in.
+
+***
+
+[Next >](iac.md)

getting-started/use-cases.md

@@ -0,0 +1,29 @@
+# Use Cases of Terraform
+
+We can specify some use-cases which can help you with the applications of Terraform as an IaC solution:
+
+## Heroku App Setup
+
+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 set a CNAME, or setting up Cloudflare as a CDN for the app. Best of all, Terraform can do all of this in under 30 seconds without using a web interface.
+
+## 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 use a database tier. Additional tiers get added for API servers, caching servers, routing meshes, etc. This pattern is used because the tiers can be scaled independently and provide a separation 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 dependencies between each tier are 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, elastically scaling with load becomes trivial.
+
+## 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 be 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 be easily disposed of. Terraform can help tame the difficulty of maintaining parallel environments, and makes it practical to elastically create and destroy them.
+
+## Multi-cloud Deployments
+
+It's often attractive to spread infrastructure across multiple clouds to increase fault-tolerance. By using only a single region or cloud provider, fault tolerance is limited by the availability of that provider. Having a multi-cloud deployment allows for more graceful recovery of the loss of a region or entire provider.
+
+Realizing multi-cloud deployments can be very challenging as many existing tools for infrastructure management are cloud-specific. Terraform is cloud-agnostic and allows a single configuration to be used to manage multiple providers, and to even handle cross-cloud dependencies. This simplifies management and orchestration, helping operators build large-scale multi-cloud infrastructures.
+
+***
+
+[< Previous](terraform.md)