independent and reusable
Modular coding enables the use of “independent” code. Instead of creating a monolithic structure of code.
The advent of Service Oriented Architecture focused on creating independent and discrete services instead of a monolithic design. Architects and lead engineers began to see the benefit of writing code in such a fashion as to allow teams to write code independently. Then use program interfaces to pass data, or queries, or instructions between the services. Writing modular code is the same idea of writing independent services but instead, we are writing independent modules. The idea is simple, break code into sizeable and manageable blocks of code. Each block of code becomes a file and the files within a folder become a module. We then piece together different modules to achieve infrastructure that supports the deployment of IT resources.
When writing Infrastructure as code, we are code to deploy resources in AWS, GCP, Azure, and other cloud providers. We can either write a long block of code that deploys a VPC, Security Groups, file storage, load balancers, front-end application servers, back-end databases, email interfaces, monitoring, application firewalls, and the list goes on. This becomes one massive file if we write everything into one file. The problem with large monolithic code is when you have hundreds of lines of code that fail, then when you troubleshoot, you’ll have hundreds or even thousands of lines of code to figure out the root cause. Troubleshooting a failure amongst hundreds of lines of code takes time, and possibly becomes a tediously daunting task. Equally, when it comes to testing the code, a huge monolithic code structure causes a requirement to create a large test plan that must test every function, and the test itself can become time-consuming.
Modular code is all about writing code into smaller files. We then publish the functional bits of code so that it is reusable in other deployments.
Consider a Bastion host (I call it a “Controller” as I use a Bastion host to run Ansible code sometimes). I have a module that sits in a separate directory. I deploy my controller only when I need it. My module for deploying a controller has no relationship or purpose when I’m writing other code deployments. Therefore, it is not usually required as part of my cloud development. Instead, it is a block of code that I have written to support me when I need to reach into my cloud environment for troubleshooting or inspecting resources using SSH via my bastion host. It’s a perfect example of a module (a block of code that is independent and deployable by itself).
Hashicorp’s Terraform has a registry of Terraform modules written and supported by a community of developers. It is a perfect example of modular code being published for use as independent modular code ready for you to include in your library of modules. I highly recommend perusing the registry of modules.
The Secret ingredient to modular terraform (Outputs, Inputs)
Output/Input -The secret to modular and reusable Terraform code is wrapping our heads around the idea of creating code into a folder that becomes a module and instructing the code to output parameters; as inputs to other code. Hence, we are passing data between modules. For example, code to create a VPC will include an output of the “VPC ID,” Other modules will know the “VPC ID” by essentially getting the ID from Terraforms “Output.”
Location, Location, Location – The other secret is to put Terraform Outputs in a shared area for additional modules to use “the outputs”, as input “data.” for example, putting Terraform Outputs in Terraform’s remote state within an S3 bucket.
Using Remote State for Modular Code
See my post Using terraform remote state for modular code
An example of creating and implementing Modular Code with Terraform
See my post Creating and implementing Modular code using Terraform