Tutorials/5-physical-environments.md

Physical environments and versioning

Now that we have a logical map of some of our Applications we can start documenting their physical deployments. Operations, Developers, Testers and Architects are interesting in the infrastructure.

We take the previous matrix we have done and manually enter the applications, their versions, their DNS / urls. In the future we will derive this information automatically.

Environment Matrix

ApplicationLocalDevelopmentTestQuality AssuranceProduction
Company Websitelocal.company.comdev.company.comtest.company.comqa.company.comwww.company.com
Customers APIlocal.customers-api.company.comdev.customers-api.company.comtest.customers-api.company.comqa.customers-api.company.comcustomers-api.company.com
Customers Databaselocal.customers-database.company.comdev.customers-database.company.comtest.customers-database.company.comqa.customers-database.company.comcustomers-database.company.com
…

Versions

ApplicationLocalDevelopmentTestQuality AssuranceProduction
Company Website3.0.157.02.1.117.02.1.102.02.0.122.12.0.122.1
Customers API2.3.12.02.3.12.02.3.12.02.0.8.02.0.8.0
Customers Database4.2.99.44.3.1.44.1.0.14.1.0.14.1.0.1
…

Note: DNS for databases / internal API’s would only be available internally.

Physical environment documentation Most cloud systems (Azure, AWS, Google Cloud) automatically provide an interface which describes your physical environment. i.e all your servers, their IP addresses so it is redundant to documentat the same information. What is important though is to map how those physical environments relate to your logical environments. It is likely a few of your environments are breaking the rules and conventions.

Physical Envrionments

Physical/Instance EnvironmentLocalDevelopmentTestQuality AssuranceProduction
AzureAzureDevAzureSITAzureUATAzureUATAzureProd1, AzureDR
Local MachinesAWS-US-Dev02, AWS-US-Dev01(old)AWS-US-Prd
Melbourne Datacenter (SIT)Melbourne Datacenter (PRD)