Scalr is a remote operations backend for Terraform. What does this mean in basic terms? It executes Terraform operations and stores state, regardless of the workflow, in Scalr itself allowing for easy collaboration across your organization. That means you can easily onboard an existing GitOps or native Terraform CLI workflow into Scalr with little to no modification to your actual code.
We agree that Terraform is a phenomenal open-source tool and the de facto standard for infrastructure as code, but it comes with challenges as your usage grows. These challenges don’t only apply to open-source Terraform, but also to the solutions (Blob storage, CI/CD tools, OPA integrations, VCS actions, etc) that are bundled together to create an equivalent to Scalr. Scalr was created to alleviate these scaling issues and provide new concepts and features already built for you as you progress through the DevOps journey.
Our goal as we continue to build Scalr is to allow you to centralize your Terraform administration while decentralizing your Terraform operations. The majority of our customers have a platform team that manages the overall Terraform strategy, which enables the developers or application teams to focus on the actual Terraform code/execution and not the platform or process surrounding Terraform. Scalr enables this through:
- Flexible workflows with the ability to execute Terraform through the native Terraform CLI, PR automation, or the Scalr Module Registry.
- Native integrations with tools like Open Policy Agent, Datadog, Okta, and Slack.
- Reporting on runs, Terraform versions, OPA results, and more across all workspaces.
- A unique organizational model that provides isolated environments per team, inheritance, and assignment of objects like variables, credentials, and OPA policies.
- Best-in-class security with custom RBAC roles and the most flexible provider credential solution with provider configurations.
All of these concepts and more are documented in detail in the remainder of the docs and you will find everything can also be managed through the Scalr Terraform provider, which we highly recommend.
Typically, there are a few stages depending on your Terraform experience and the scale at which you are operating. Standardizing and operationalizing don't follow a specific order:
Get familiar with creating a run in Scalr and what your workspace options are. Once you create a run, you get a good feeling of how you can collaborate with your colleagues in Scalr. Features to use:
- Create a VCS provider to enable PR automation.
- Create provider configurations to pass credentials to the runs
- Create a workspace
- Create a run
- Implement RBAC for any user type
- Create environments, which is a way to segment teams and workspaces.
Now that a workflow is in place, start creating standards for the deployments. Features to use:
- Once you understand which structure fits best, scale it by automating the deployment of it through the Scalr provider.
- View reports to understand usage and identify outliers.
- Add modules to the registry for consumption across your organization.
- Create OPA policies to enforce standards.
When you hit a certain scale you'll want to ensure smooth Terraform operations: Features to use:
- Integrate with Datadog to analyze Terraform events and react quickly.
- Integrate with Slack to notify users of run events and approve/deny runs directly from there.
You’re always welcome to open a Support Ticket if you have any questions or issues.
Updated about 2 months ago