Why use modules?

- [Instructor] Your tasked with setting up infrastructure for your company's new project. You need a database, web application service, and some virtual machines for dev, staging, and prod environments. Without models, you end up with one massive configuration file with mixed resource types that's kind of hard to maintain. What if there was a way to organize your infrastructure into logical, reusable components? That's exactly what Terraform models solve. Terraform models lets you bundle related infrastructure resources into reusable components that can be shared across teams and projects. Think of models as functions in programming. They take inputs, which are variables, perform operations and return outputs for other parts of your configuration to use. Terraform has got lots of models in the public Terraform registry that you can use in your configuration, but in this video, we'll learn about creating local models. Every Terraform configuration is a model. When you write your main variables and outputs.tfs in a directory, you are creating what is called the root model, but the real power comes when you create reusable generic child models that can be called from the root models. Some of the benefits of using models are code reusability, and DRY principle. Instead of duplicating your configurations and having one massive configuration file with mixed resource types, you organize them into logical focus components and just reference them in your root model. In this sample config, we reference database, compute, and web app models and deploy each of these resources as defined in each model. Other benefits of using models are first, consistency and standardization. When everyone uses the same database model, you know your security settings, backup policies and compliance rules are identical everywhere. You don't have to manually check or guess if one team forgot a firewall rule. Your model enforces it for you. Second, easier maintenance and updates. You need to roll out new tagging scheme for cost tracking? Just update the model once and every deployment that uses it picks up that change automatically. No more having to hunt through dozens of terraform files. Third is abstraction and simplification. A database model might actually spin up the server, configure firewall rules, enable monitoring, and set up backups under the hood, but your users only see the handful of variables they need to set. Now that complexity stays hidden in the model. Fourth is testing and validation. Instead of writing tests against one giant configuration, you can test each model in isolation. This makes tests faster, more focused, and far easier to debug. Finally, models can even call other models, which is what we call nested models. That lets you build sophisticated stacks, for example, a web app model can pull in your networking, computing, and database models all at once. Now, in large organization, you have multiple teams owning different pieces of infrastructure, like network teams building network models, app teams consuming compute models, and so on. In those cases, you'll usually publish your models in Terraform's private registry. That gives you versioning, governance, and easy distribution across teams. You can wire in automated testing pipelines and force policies centrally and track who is using which model versions. It really streamlines collaboration at scale, so your networking, security and application teams all stay in sync without stepping on each other's toes. All right, let's dive into some best practices for building child models in Terraform. First off, keep each model focused on a single concern, so one for networking, one for compute, another for databases, and so on. That way it's clear what each model does. Next, parameterize everything that could change. Don't add code, IDs, names or instance counts. Make them variables so your model stays flexible. Speaking of variables, give them sensible defaults in your variable.tf file, but always allow those defaults to be overridden. You'll also want to document everything like your input, outputs, any side effects in a README.md file right alongside the model. That makes onboarding new users a breeze. Before you share your model, whether that's tagging a release in Git or publishing to the Terraform registry, always run Terraform Fmt, and Terraform Validate to catch any formatting or syntax errors. Trial discourse will be using models to organize infrastructure within a single team is the most common way teams get started with models, and it's a pattern that can scale even in large organizations.