This document provides an overview of infrastructure as code (IAC). It defines IAC as managing infrastructure through machine-readable files rather than physical configuration. The document traces the history of IAC back to tools in the 1990s and early frameworks like CloudFormation. It outlines benefits of IAC such as cost reduction, speed, and reduced risk from errors. Examples are given of using IAC to create different environments and replicate common infrastructure components.

1. Terraform 101
What’s Infrastructure as Code?

2. A true story

3. You are developing a new API

4. Need an EC2 instance

5. Easy work - 7 steps

6. ‧ ‧ ‧

7. humm, time to googling...

10. After 2 hours of googling...

12. Need an ELB

14. Eventually you will get everything work

15. 2 month later

16. You are releasing the new API to production

17. ‧‧‧‧‧

18. Agenda
● What is Infrastructure as Code? (IaC)
● History of IaC
● Why IaC?

19. What is Infrastructure as Code
The process of managing and provisioning computer data centers through
machine-readable definition files.
Rather than physical hardware configuration or interactive configuration tools.

20. What is Infrastructure as Code - blueprint

21. What is Infrastructure as Code - 3D printer

22. History of IaC - the idea
In 2006 specifically, new challenges were brought to the forefront that shook the
technology industry.
The launch of AWS EC2 and the 1.0 version of Ruby on Rails just months before.
With new tools emerging to handle this ever growing field, the idea of Infrastructure
as Code was born.

23. History of IaC - Continuous Configuration Automation (CCA)
● CFEngine (1993)
● Puppet (2005)
● Chef (2009)
● SaltStack (2011)
● Ansible (2012)
● Otter (2016?)

24. History of IaC - timeline
● 2011-02-25: Initial release of CloudFormation (AWS)
● 2014-07-28: Initial release of Terraform (HashiCorp)

25. Why IaC? - value
● Cost (reduction)
● Speed (faster execution)
● Risk (remove errors and security violations)

26. Why IaC? - cost & speed
● Reduce time costs
○ Change it rapidly
○ Rollback
○ Repeatable (modulize)
● Readability
○ Code as documentation
○ Graph

27. Why IaC? - risk
● Reduce human error
○ Code review
○ Version control
○ Plan (dry run)

28. Why IaC? - use cases
● Create different stages
○ test
○ stag
○ prod
● Create similar resources
○ API: EC2 instance group with ELB
○ Thirdparty S3 bucket
○ CloudFront
○ IAM Users

29. Why IaC - create different stage
● $ ENV=test terraform apply
● $ ENV=stag terraform apply
● $ ENV=prod terraform apply

30. Why IaC - create infra in different region
● $ AWS_REGION=us-east-1 ENV=prod terraform apply
● $ AWS_REGION=ap-northeast-1 ENV=prod terraform apply

31. Why IaC - create similar resources
module "kktv-drm" {
source = "./modules/ec2_asg"
name = "kktv-test-drm"
env = "test"
ami = "ami-xxxxxxxx"
instance_type = "t2.medium"
}

32. Why IaC - create similar resources
module "iam_user_maniacchou" {
source = "./modules/user"
name = "maniacchou"
}

33. Why IaC - diff

34. Why not IaC
● Learning curve
○ You need best practice
● It’s not panacea (帕那刻亞)
○ Resource not supported yet
○ Resource cannot be managed

35. Conclusion
● Agile
● Reduce human error
● Verison control

36. Live demo?

37. QA