In the era of cloud and containerisation, infrastructure as code (IAC) is invaluable. In this talk, we will explore the evolution of Infrastructure practices and tools. We will further look at the practices and tools before the emergence of the clouds. Then we will explore how the rise of the cloud changed the infrastructure automation practices and made the IAC a mainstream practice. We will also explore what it means to treat infrastructure as code. We will talk about Code vs Configuration, versioning, Configurability vs Standardisation, Modularity and code organisation for infrastructure code.

1. Uncover the mysteries of
Infrastructure as code
(IAC)!
- Prashant Kalkar

2. Evolution of Infra Practices and Tools

3. Why understand evolution of practices?
◎ Understand the need for newer tools and practices.
◎ Right tool for the right job
◎ Previous good practices might not work in new
context.

4. Configuration Management
◎ OS configuration
◎ Installations of application runtimes (java, python, go)
◎ Supporting applications installations (RabbitMQ,
Mongodb, prometheus etc).

5. Before Clouds

6. Self owned Servers, manual configuration

7. ◎ High risk manual changes.
◎ Repeat changes for every server / environment.
◎ Different servers look completely different (changed at
different time)

8. Scripting

9. Scripting cont...

10. Scripting Cont...
◎ Server state matters (Different start state require
different steps to reach desired state).
◎ Idempotent steps.
◎ Imperative and error prone.
◎ Difficult to understand state of the server.

11. Configuration Management Tools
◎ Chef, Puppet, Ansible.
◎ Declarative (Desired State).
◎ Tools takes care of what changes to apply (diff)
◎ Widely successful and works great.

12. Configuration Management Tools - Challenges
◎ Configuration Drifts
◎ Automation gaps due to manual changes.
◎ Afraid to run automation.
◎ Difficult to reproduce from scratch

13. Moving away from Physical Machines
◎ Virtualisation
◎ Software defined Networking (SDN)

14. Rise of clouds

15. Clouds changed the game.
◎ On Demand infrastructure
◎ Dynamic infrastructure
◎ Service discovery, Private DNS
◎ Self service & API based.
◎ Elastic infrastructure
◎ Disposable infrastructure

16. Configuration management in Cloud

17. Infrastructure Provisioning
◎ Dynamic infrastructure requires provisioning.
◎ Tools like Terraform, Cloud Formation created.
◎ Instance lifecycle management at Runtime
(Autoscaling).

18. Immutable infrastructure
◎ Configuration at build time (AMI)
◎ Configuration at runtime time (user-data)
◎ Changes by replacing servers instead of updating.
◎ Reduced configuration drift.
◎ Manual changes reverted next deployment.

19. “
Disappearing servers is a feature
not a bug.

20. ◎ Highly dynamic.
◎ Completely immutable.
◎ Build time configuration management (dockerfiles).
◎ Standardized deployment (Public Helm Charts,
Operators etc).
◎ Open application model
Container Orchestration Platforms (K8s)

21. IAC - Software engineering practices
for Infra code

22. IAC
◎ Everything is code (Infrastructure, Configuration,
Pipelines etc).
◎ All infra code in version control.
Are we managing Infra code as application code?

23. 12 Factor App

24. Codebase
One codebase tracked in revision control, many deploys
Same code, different versions for environments.

25. Config
Store config in the environment
Different configuration per environment.

26. Code And Config for Infra code

27. Code vs Configuration
Code same for all environments
Configuration different per environment.
Code version is deployed to environment
No versioning required for Configuration (always latest)
Overridable defaults
Environment config change should not require code
promotion.

28. Violations

29. Per environment branches / folders

30. Shared (Same) code for all environment

31. Non-Violations

32. Tool supported versioning (or Git Tags)

33. Branch for versioning

34. Versioning anything with Git Tags
Kops Cluster Template versioning with Git Tag

35. Code vs Configuration - Summary
Terraform modules with Registry or Git tags (versioned)
Helm chart with helm registry (versioned)
Versioned Ansible Roles with Git tag
Versioned Kops template with Git Tags
Versioned Deployment scripts with Git Tags

36. Some more practices

37. GitOps
◎ Git as source of truth.
◎ Git changes to trigger pipelines.
○ No build with parameters
○ No manual builds
◎ Continuously sync between Infra and Git state (not
only on commits).
◎ K8s operators (Pull based model)

38. Apply changes continuously not only on Change
◎ Keep the infrastructure in Sync with automation
◎ Keep things up today (versions, security patches etc).
◎ Auto update things only at entry level (First
environment).

39. Code - Configurability vs Standardization
Highly configuration modules - Be careful.
Some examples
◎ Different AMIs
◎ Different docker images

40. Practices to keep in mind
◎ Name collisions
◎ Create before destroy (or rolling deployments)
◎ Handle Graceful shutdown
◎ Naming strategy for dynamic environment (terraform
workspaces)
◎ Plan for output values as well

41. Modularity vs Orchestration
Independently deployable
Different modules for different infra component.
Orchestration Module dependencies.
Well defined input and outputs for composable modules.

42. Conclusion
Use right tools for the right job.
Follow the same CI/CD practices for Infra code.
Reduce drift between code and Infrastructure
Keep the IAC code modular while managing the
orchestration.

43. Thank you!
Questions?