What is the different between Platform.sh and Terraform?
Platform.sh and Terraform are similar in that they both subscribe to the idea of “infrastructure as code”.
Developers on Platform.sh use a collection of YAML files that define the behavior of their application (how it builds and deploys), its services, and its routes. Since configuration is written in files, they can be version controlled such that changes to infrastructure can be tracked and observed over time as the application evolves.
What these files contain is different because Platform.sh is a Platform as a Service provider, whereas Terraform is a tool for provisioning resources with an Infrastructure as a Service (IaaS) provider like AWS and Azure. Learning everything you need to know to manage each resource on an IaaS your applications depend on is a lot of work, and Platform.sh and Terraform provide different solutions to that problem.
If you want to deploy a Drupal application on Platform.sh, you would take an existing code base and include the three configuration YAML files that tell Platform.sh
- how to build and deploy it
- what services it relies upon
- how it should handle incoming requests to the application
You push to Platform.sh, and a remote repository is created that contains both the application code and its configuration files. In this way, Platform.sh ties the histories of both your application and your infrastructure into a single commit history. Once you have configured those files correctly, you’re ready to go. Even if you’re on a region that is actually deploying to Amazon AWS, you never have to have known that to get started. This abstraction makes it so developers can deploy on Platform.sh, because we do all the heavy lifting to keep it running on an IaaS elsewhere.
Terraform is very different. It does not host your application code, but is rather a tool to help you host it somewhere else. It has a collection of configuration files, but those files don’t refer to the application itself - how it should be built or what needs write access - at all. Those files also do not need to exist in the same repository as your application, but are often kept in a separate Git repository so that a commit history of your infrastructure can still be observed.
The content of the files themselves focus purely on how infrastructure should be provisioned on an IaaS, using a common syntax that communicates with AWS’s (or Azure’s, etc.) API in order to do so. Because of this, developers do not deploy on Terraform - they can download Terraform and use it as an abstraction tool so that they can deploy directly on an IaaS themselves more easily.
1 Like