If you can, doesn’t mean you should - lessons learned terraforming clouds

Video: https://www.youtube.com/watch?v=S79nEFZN7xA

We all love automation; the fewer steps needed to get something deployed - the better. Even if it means abstraction layer on top of abstraction layer - we all love our abstraction layers. Terraform, modules, wrappers and orchestration tools allow for an increasingly more sophisticated code - but where do you draw the line?
In this talk, we explore the boundaries of infrastructure as code and look for the balance between abstraction and maintainability.

Transcript

1. If you can, doesn’t mean you should Natalie Godec Staff Cloud Engineer Babylon terraform apply --target
2. Who am I? • Natalie Godec • Cloud/Platform/DevOps/Systems Engineer • Interested in Infra, Data and Security • Also photographer • Socials: @ouvessvit
3. Automation & Abstraction Are Awesome Where do you draw the line? twitter: ouvessvit
4. Here? storage_bucket_access = merge( merge([ for user, access in var.access : { for bucket in access.buckets_ro : "${replace(user, ".", "_")}_${bucket}" => { member = "${user}@domain.com" bucket = bucket roles = ["storage.objectViewer"] } } ]...) ) twitter: ouvessvit
5. Here? storage_bucket_access = merge( merge([ for user, access in var.access : { for bucket in access.buckets_ro : "${replace(user, ".", "_")}_${bucket}" => { member = "${user}@domain.com" bucket = bucket roles = ["storage.objectViewer"] } } ]...) ) twitter: ouvessvit
6. Or here? $ terraform state list | wc -l 2051 twitter: ouvessvit
7. Terraform is a configuration language: You describe the desired end state of your infra twitter: ouvessvit
8. • Dependency loops • State drifts • Inconsistency • Security holes • “Off the road” implementations Risks: twitter: ouvessvit
9. Overly complex configurations • kitchen sink in one module • attempts at abstracting every use-case • transformations and conditions everywhere twitter: ouvessvit
10. Procedural flows • local execs • VPC peering (╯°o°)╯︵ ┻━┻ • K8s on cloud: EKS, GKE, AKS twitter: ouvessvit
11. All-in-one states • all DBs in one state • all IAM roles and policies together • targeted deployments •`_´• twitter: ouvessvit
12. Define a single point of deployment twitter: ouvessvit
13. Single points of deployment All the infrastructure needed for a service Group of resources used by a single team Standalone, complex infrastructure twitter: ouvessvit
14. All the infrastructure needed for a service Client profiles: - RDS instance - RDS parameter group - Security group - Security group rules - Cloudwatch logs - Cloudwatch alarms - SNS topic for alarms - IAM roles + policies - KMS key twitter: ouvessvit
15. All the infrastructure needed for a service Client profiles: - RDS instance - RDS parameter group - Security group - Security group rules - Cloudwatch logs - Cloudwatch alarms - SNS topic for alarms - IAM roles + policies - KMS key Group of resources used by a single team GCP project for AI team: - The project :) - Network, DNS - Cloud Armour rules - Bigquery datasets - Storage buckets - IAM roles - Cloud Run - Vertex AI twitter: ouvessvit
16. All the infrastructure needed for a service Client profiles: - RDS instance - RDS parameter group - Security group - Security group rules - Cloudwatch logs - Cloudwatch alarms - SNS topic for alarms - IAM roles + policies - KMS key Group of resources used by a single team GCP project for AI team: - The project :) - Network, DNS - Cloud Armour rules - Bigquery datasets - Storage buckets - IAM roles - Cloud Run - Vertex AI Standalone, complex infrastructure module Opensearch cluster: - The cluster (d’oh) - Security group - Security group rules - Cloudwatch logs - Cloudwatch alarms - SNS topic for alarms - IAM roles + policies - KMS key - Lambda for Opensearch config twitter: ouvessvit
17. Characteristics of components in a single point of deployment • change together • evolve together • no conflicts or dependency issues • can be tested and deployed together • independent from the rest of the infrastructure twitter: ouvessvit
18. Design patterns, guidelines and guardrails twitter: ouvessvit
19. Design patterns Easy to use, understandable, consistent modules as building blocks Clearly documented and communicated standards, integrated in CI/CD Checkov, Terraform Compliance, GCP Org Policies, AWS Config, Azure Policy Guardlines Guardrails twitter: ouvessvit
20. twitter: ouvessvit CICD integration lvl 1: format and validation
21. twitter: ouvessvit CICD integration lvl 2: Checkov
22. twitter: ouvessvit CICD integration lvl 3: Terraform Compliance
23. twitter: ouvessvit CICD integration lvl 999: Infracost
24. twitter: ouvessvit
25. ✧ﾟRemember KISS ✧ﾟAlways ask “Why?” ✧ﾟUnderstandability * credits to Anton Babenko twitter: ouvessvit
26. Thank you twitter: ouvessvit