Sierra-Cedar's Customer Journey With Scalr

Sierra-Cedar is a consulting and managed services company historically focused on the implementation, migration, and hosting of Oracle ERP software like Oracle Cloud, PeopleSoft and Oracle eBusiness.

Sierra-Cedar is a gold Scalr partner. Sierra-Cedar’s DevOps Services division assists clients in planning, implementing, migrating, and managing Infrastructure-as-Code in AWS and other major cloud service providers. Sierra-Cedar provides a wide range of services from the design and architecture of new cloud services to retrofitting existing infrastructure with Terraform, policy-as-code with Open Policy Agent (OPA), and the configuration of and subsequent migration of Terraform to the Scalr platform. I recently had an opportunity to talk with Sierra-Cedar about the background of its relationship with Scalr. Here are my questions and Sierra-Cedar’s responses.

How and why did you start using Terraform?

As Sierra-Cedar began to adopt cloud technology for our hosted/managed services clients, we knew early on that there were going to be limitations on how effectively our teams could manage infrastructure via the cloud providers’ consoles. Our choices were limited, and we were attracted to Terraform due to its declarative language (what to build rather than how to build).

However, as we scaled out our hosted client environments into the dozens and hundreds, we quickly realized that we would need a way to collaborate more effectively across teams and business hours – running Terraform from the command line simply was not going to get us to the “next level” that we desired. So, we invested some time and effort internally and built a Terraform Automation and Collaboration (TACO) tool that helped with visibility in our client pipelines.  

What prompted you to build an internal tool to manage your Terraform pipeline?

The simple answer is that other tools didn’t exist. Our tooling was built well before TACOs like Scalr, Terraform Cloud, and others were available in the market. It’s not an effort that we wanted to take on, as it required a significant lift from our already overburdened development teams, but if we were to be successful in this space, it was a necessity.

Once we started tracking the emergence of the TACOs that exist today, it was clear that we would not be able to keep pace with the market, and we made the decision to focus our efforts on our core business and mothball our internal tools in favor of Scalr. The simplicity of the migration effort and the favorable cost model were perfectly aligned with our needs.

Why didn’t you go with a standard CI/CD option instead of DIY?

We certainly went down that road and it worked well – for a while. The major version control systems (GitHub, GitLab, BitBucket) all support extensive CI/CD capabilities, including the ability to run Terraform. However, when we scaled out the number of repositories (and clients) that we were managing, we lost the single-pane-of-glass visibility into “what is happening/has happened in our environment?”. We also couldn’t easily decouple the approval process of merging code into the main line from applying the code during a maintenance window, which is something that Scalr makes simple.

What prompted you to decide to look at TACO (Terraform Automation and Collaboration) products?

At Sierra-Cedar, we regularly scan the market for new tools and methodologies to continuously improve the services that we offer. We viewed the emergence of TACOs as confirmation that the need for such tooling was real and widespread in the market, and we could shift our attention and resources from the development of the tooling back to the core business by adopting the right TACO platform.

Why did you select Scalr?

The organizational hierarchy with the logically related environments / workspaces was exactly the type of flexibility we were looking for – it allows for flattened deployments, a strict hierarchy with isolated deployments, and any mix of the two. For any enterprise client looking at the segregation of duties, this is necessary, and Scalr makes it easy to manage.

Support of multiple cloud service providers was a necessity, and integration with major version control systems was a must. We also require single sign-on integration with multi-factor authentication, which is simple to integrate and configure in Scalr.

During our proof-of-concept testing with Scalr, we also experienced the best support turnaround times and time-to-resolution, which is important to us as a Scalr client that is using the product to support our own clients.

Cost at scale was a key factor in our decision as well – Scalr allows us to scale our client infrastructure out with a predictable metric that makes sense (Terraform runs/month).

We evaluated all the main players that had some form of TACO offering and we simply found that Scalr was most aligned to our business needs in terms of cost, capabilities, flexibility, organization, support, and responsiveness.

What best practices would you recommend for new Scalr customers?‍

Plan, plan, plan!

Organize your Terraform code in a way that supports modules/submodules and the isolated workspace layout that Scalr provides. This up-front work will set you up for scalable long-term success.

Think about how to organize – by business process? by teams? by project? a hybrid approach? Each one has its own benefits and drawbacks, and how you organize your role-based access control will dictate how much flexibility you’ll have down the road. Scalr's flexibility covers all use cases, no matter what you end up picking.

Everything as code! Scalr has the ability to control itself via a Terraform provider to set up Scalr environments, workspaces, and other configuration elements. Use it!

How did you mitigate security concerns around using a SaaS platform, like Scalr, to control cloud deployments?

We approach security as an onion, first looking at how we can harden the outer layers and then working our way to the components at the core. Each layer has different requirements and must be considered independently secure in addition to secure as part of the greater system.

In Scalr, a notable example of this is the ability to use AWS IAM Roles for access to AWS environments. Instead of requiring access keys that would need to be manually rotated like some other platforms do, we can simply specify an IAM Role that is secured with an external ID and manage the lifecycle and permissions of that Role with Terraform. This process also works well in a highly automated account “vending machine” type of environment, where we may want to allow users to spin up/down accounts as needed.  

Scalr also has fine-grained access control to its functions, from the ability to view/edit environments and workspaces to the ability to view logs, execute runs, manage credentials, and many other functions. Combined with Scalr’s ability to integrate with ADFS for SSO and MFA, and the ability to use the Scalr Terraform Provider to manage the Scalr configuration, we are able to attain a high degree of automation and security on the platform.