Why we built Resourcely

Written by: Travis McPeak
Published Date: July 16, 2024

Three primary trends have influenced the software industry over the last 15 years: the rise of the cloud, a shift from waterfall to continuous development, and DevOps practices.

These trends have all shifted more responsibility to the developer: deployment, security, and configuration are now the responsibility of software engineers. Software teams who were once only responsible for designing and creating applications are now expected to be infrastructure and deployment experts as well. You can read more about the history of security and configuration here.

Developers owning infrastructure inevitably results in rampant misconfiguration: improper parameters for cloud infrastructure that are costing companies millions. When a database, virtual machine, or SaaS application is configured incorrectly, there are two results:

• incidents, breaches, and outages
• wasted developer time

We built Resourcely to eliminate misconfiguration, stemming the tide of needless incidents and tackling the hours of waste we observed throughout the industry.

Frankly, we were frustrated by the status quo of cloud infrastructure configuration, and we decided to do something about it. Our experiences at top-performing cloud-based companies like Netflix, Robinhood, and Databricks taught us how to solve this problem, and Resourcely is a product of those learnings.

It allows security, ops, and platform teams to give developers a paved road to production, generating secure and compliant Terraform that is deployed as part of your existing change management tooling. We didn’t stop at bespoke, customizable templates that give developers an easy button to deploy infrastructure. Resourcely also features a novel cloud resource policy language that acts as a safety net: making sure that any Terraform deployed meets the standards that you define.

With these tools, developers no longer loathe deploying infrastructure, and security teams look like superheroes by empowering secure defaults built into developers.

Status quo of configuration

Cloud resources are misconfigured across all software organizations every day. Developers who aren’t Terraform experts are asked to deploy heterogeneous services that they are unfamiliar with. These developers are faced with a trade-off: ship misconfigured infrastructure, or ship slowly. In many cases, businesses are pushing developers to ship faster at the expense of misconfiguration.

What does that developer experience look like? Developers are forced to research the individual cloud services they want to deploy, learn about configuration best practices for them, write Terraform that matches their mental model, and then push that Terraform in a PR. Often they are asked to use a specialized, internally-developed tool to accomplish this. While many individuals start offthinking that only a single resource will be required, they slowly realize that multiple cloud resources are always required (IAM, networking, storage, etc.). At every step along this path there is friction and opportunity for misconfiguration.

Security teams are only compounding the problem with long lists of vulnerabilities flagged by CSPMs and a reactive modus operandi. These vulns end up on a long list, handed to developers, who never get around to fixing them anyway.

So why does it matter?

These dynamics result in two primary issues costing companies millions of dollars each year:

Incidents

Improper configuration inevitably results in incidents, vulnerabilities, and breaches. Let’s consider two scenarios: a security vulnerability, and an internal application that goes down.

Security vulnerabilities can threaten the very lifeblood of a business. Consider the most simple of examples, where an S3 bucket is left accessible to public access. This is actually somewhat tricky to get right, as we’ve written about before.

Inadvertent exposure of data, or server access, or firewalls, or anything sensitive can result in public-facing breaches that cost upwards of millions of dollars. As of 2023, the average cost of a data breach in the US was around $9.5M.

Misconfiguration doesn’t only have to be about security and data breaches. Consider an internal application that is used to support customer service agents for an airline. Let’s say you have a database misconfiguration that results in queries to that database failing for several hours during peak travel season. This has directly impacted your customer satisfaction, retention, and future revenue prospects.

Developer productivity

In the same way that incidents have a quantifiable impact on your business, so does developer productivity - especially for businesses with software as a core product. Deploying and configuring infrastructure is a significant impediment to the speed at which developers move. To successfully do this they must:

• Research cloud resources to use
• Figure out the correct configuration, which is challenging to get completely right without being an expert
• Write Terraform or use a Terraform module
• If they use a module, they’re often fitting a square peg into a round hole
• Push that Terraform to production

Frequently, the Terraform they’ve written is bounced back to them by a reviewer, which further compounds the developer productivity problem. Maintaining, updating, triaging, and changing their infrastructure can result in even more hours than they spent on the initial project.

Let’s say you have just 100 developers pushing infrastructure to production, with an average infrastructure deployment that make infrastructure changes 2/week. If your developers spend 4 additional hours each time they deploy researching Terraform and (trying) to get the configuration right, and they cost $275,000 fully loaded, you’re looking at $5.5M in annual cost and an incalculable amount of opportunity cost (from projects they could be working on instead).

👉 (100 developers) * (2 infra deployments/week) * (52 weeks) * (4 hours/deployments) * (275,000/year / 2,080 hours in a year) = $5.5M annually.

Secure defaults and the Resourcely answer

So you’ve got a problem costing you millions of dollars a year, and your cost almost triples each time you have an incident. We had these same issues at Netflix, Robinhood, Databricks, and other companies that our founding team worked at.

We solve this problem is by removing humans from the loop as much as possible. We implemented secure-by-default frameworks across the business, and gave developers a paved road to production that would allow them to get what they need without friction.

Asking humans to configure infrastructure, when we already know what best practices and company-specific requirements should be, is an outmoded practice rooted in years of on-premise and legacy security practices. Instead, we should be asking machines to make configuration decisions for humans. (Check out this episode of the a16z podcast where our CEO Travis discussed this concept)

Resourcely tackles misconfiguration at the source: turning security teams into proactive superheroes, and unleashing developers from DevSecOps hell of the past. How do we do it?

Guardrails

Guardrails govern how infrastructure can be created or changed, preventing inadvertent misconfiguration. These are policies, managed and written by security, ops, or platform teams, and enforced as part of your existing change management/GitOps workflows.

Imagine you write the following policy:

GUARDRAIL "Require prefix on all S3 buckets"
   WHEN aws_s3_bucket
       REQUIRE bucket STARTS WITH "resourcely-"
 OVERRIDE WITH APPROVAL @securityops

Resourcely will:

• Let the developer know they are violating a guardrail if they don’t start an S3 bucket with resourcely-
• Guide the user about how they should be configuring the resource
• If the developer still chooses to continue, Resourcely will route the PR to the appropriate approver specified in the guardrail
• The PR will always fail without approval, if the S3 bucket is not appropriately named Guardrails limit accidental public exposure, oversized infrastructure, inadvertent deletion, and more - all in an easy-to-read policy language remarkably similar to SQL.

Blueprints

Resourcely Blueprints are configurable templates, customized by security, ops, or platform teams, that give your developers a paved road to cloud infrastructure resources. They provide a UI with context, selection criteria, lists, and more.

Once published, blueprints are available in a service catalog that developers can use to bundle the infrastructure they want to deploy. Guardrails can be attached to blueprints, ensuring that your policies are enforced.

After submission, Terraform is generated and deployed through your existing change management and review processes.

Configuration platform
Over the next few weeks, we’ll be announcing the General Availability of Resourcely, covering how our customers are using it to build a secure-by-default platform for deploying infrastructure, and showing you how anyone can do the same.

The misconfiguration problem is widespread and hugely impactful. Adopt the premier configuration platform to eliminate misconfiguration, reducing millions in developer waste and bidding goodbye to incidents & breaches that average $9.5M of impact. Get started with Resourcely today, and follow along on our GA launch journey over the next few weeks!