This is the final (non-bonus) part of a series on the Terraform E+A pattern. If you've arrived here first, I suggest reading from the beginning to understand what this is all about.
Throughout this series we have seen how we can use Terraform to deploy a set of applications across multiple deployment environments so that a system can be effectively duplicated for pre-production testing and other purposes.
An environment gives us a set of shared infrastructure that provide the applications somewhere to run and a means to communicate. The applications themselves can then use these resources in conjunction with their own and those of other applications to produce a modular system.
A key benefit of using Terraform in this manner is to facilitate communication within and between teams in an organization.
Terraform as a Communication Tool
Many uses of Terraform are oriented just at making a particular team more productive: rather than manually managing resources or hand-rolling provisioning scripts, we can describe our infrastructure with Terraform and free ourselves from worrying about all the details of how that infrastructure gets wired together.
The E+A Pattern embraces Terraform for a loftier purpose: to create interfaces between systems, and thus in turn between teams. As technical organizations grow they often divide into multiple teams with different responsibilities and/or skill-sets, and we are confronted with the problem of how to connect together many small parts created by different teams into a cohesive whole.
The system architecture that was the archetype for the E+A Pattern was one where a small group of technical specialists established some shared infratructure (the environments) and then many small, frequently-changing teams built and deployed co-operating applications on that infrastructure. Most applications in this system are using EC2 autoscaling, but some of the subsystems have benefitted from extensive use of AWS Lambda and various higher-level AWS infrastructure services such as Kinesis Firehose and Simple Notification Service.
Terraform is a boon here because it codifies both the infrastructure within a subsystem and the connections between subsystems. When one team needs to provide a subsystem to be consumed by other subsystems, Terraform makes it easy to orchestrate the integration of those systems without manual wiring. As team structures shift over time due to development priorities change, new team members can quickly understand what an application is "made of" by seeing how its own infrastructure is created and how it connects with that of other systems.
Terraform's generality is also a benefit, since a team can become familiar with one tool and then apply it to a variety of different situations where different technology is appropriate. Rather than each subsystem having its own deployment solution, or forcing all subsystems into a narrow set of technology constraints, Terraform can allow each application to use the technology best suited to its problem while reducing the chances of creating "knowledge silos" where engineers have difficulty shifting between teams.
The E+A Pattern aims to create a structure in which Terraform can most readily provide the above benefits, separating concerns so that Terraform can scale to meet the needs of larger teams and more complex systems.
Where to from here?
The main parts of this series up until this point have described through example a very general design pattern. This provides a framework for creating a practical system, but leaves many details as an exercise to the implementer.
In the sixth and final section of this series we'll discuss some "bonus patterns" that build on the E+A pattern either to solve additional problems or to specialize the general pattern to a more specific situation.