Cloud Optimization as Code

Automatically Optimize Your Cloud—Forever

Continuous Optimization That Fits into Your CI/CD Framework

Infrastructure as code (IaC) automates cloud resource selection, but often creates operational risks and high cloud costs.

Optimization as code automates away these problems, seamlessly extending your CI/CD pipeline to enable Continuous Optimization (CO).

Inject one line of code into your favorite infrastructure as code template to link your cloud application instances to the patented Densify™ Cloud-Learning Optimization Engine, Cloe, and your cloud apps get exactly the resources they need at the lowest possible cost, now, and as requirements and technologies change.

Densify’s cloud optimization engine

Introduction to Optimization as Code

Manual Instance Specification Limits the Power of IaC Automation

Infrastructure as code (IaC) tools like HashiCorp Terraform and AWS CloudFormation simplify and automate the process of managing and provisioning infrastructure. But two pitfalls are often inadvertently encountered:

  1. Developers often leverage tribal knowledge to manually size cloud instances, provisioning them larger (increasing costs) or smaller (introducing business outage risk) than required, or even selecting totally wrong instance types.
  2. These incorrect requirements become hardcoded through declarative IaC. Even if you change the instance type and size on the fly, the instance will be kicked back to the original misconfiguration after every restart.
provider "aws" {
  region = "${var.aws_region}"
}
resource "aws_instance" "web" {
  name = "Web Server"
  instance_type = "m4.large"
  ami = "${lookup(var.aws_amis, var.aws_region)}"
}
Hardcoded infrastructure as code definitions trap your apps within suboptimal instances

Effects of Hardcoded IaC Resource Selection

Increased operational risk

Increased operational risk

Underprovisioned cloud resources

Potential business outages

Overprovisioned cloud resources

High cloud costs

Suboptimal instance configurations becoming intrinsic to your IaC definitions

Suboptimal instance lock-in

The Solution: Optimization as Code Continuous, Environment-Aware Resource Selection

Step One: Self-Aware Infrastructure Imagine If Your Cloud Apps Just Knew

What if your cloud apps became self-aware of their exact resource requirements?

The Densify™ analytics engine—Cloe—uses patented machine learning to continuously model your apps’ utilization patterns and compare these models against complete knowledge of offerings from cloud providers. Cloe then generates recommendations for optimal instance types and sizes for each app and workload:

  • Injecting these findings into your cloud instances as tags (optional)
  • Building an Impact Analysis Report for providing transparency to app and business owners and attaching directly to change tickets
  • Documenting recommendations in machine-readable map files (that can be automatically synced to repos like GitHub) for advanced organizations that choose to automate optimization

With self-aware cloud apps, developers no longer need to rely on tribal knowledge when selecting and sizing cloud instances. Densify™ automatically provides a perfect, data-validated recommendation—every time.

What if your cloud apps became self-aware of their resource needs?

Step Two: Continuous Optimization The Next Frontier of Infrastructure as Code

What if your cloud infrastructure became forever self-optimizing?

The next step for organizations that are successfully leveraging self-aware infrastructure is to evaluate Continuous Optimization (CO) as an addition to their CI/CD framework—an approach that makes infrastructure automatically self-optimizing.

By replacing fixed resource assignments in your infrastructure as code templates with calls to reference Cloe’s recommendations, your cloud apps and workloads can be automatically reprovisioned to the best-fit instances. And, as app resource demands change over time or newer instance types are introduced by cloud providers, your infrastructure remains optimized.

When your organization embraces Continuous Optimization, hardcoded instance selections in your IaC templates are replaced by calls to Densify™ to leverage recommendations based on your apps’ exact needs. Your cloud infrastructure becomes self-optimizing, 24/7.

provider "aws" {
  region = "${var.aws_region}"
}
resource "aws_instance" "web" {
  name = "Web Server"
  #instance_type = "m4.large"
  instance_type = "${lookup(local.densify_spec,"appr_type") == "all" ? lookup(local.densify_spec,"rec_type") : lookup(local.densify_spec,"cur_type")}"
  ami = "${lookup(var.aws_amis, var.aws_region)}"
}
Optimization as code dynamically adjusts the instance type, ensuring your apps always get the resources they require

Benefits of Optimization as Code

  • Improves your environment's stability and application performance
  • Significantly increases your cloud cost efficiency
  • Automated, Continuous Optimization as your applications’ demands evolve and change
  • Operational excellence in the way your organization leverages and selects instances and deploys applications in the cloud
  • Tightly fits into your CI/CD pipeline, facilitating a new DevOps paradigm of CI/CD/CO (Continuous Optimization)

Everybody Wins Bridge the Gap Between App Developers, CloudOps, & Finance

Developer

Developers can embed code snippets into their apps to make them self-aware and self-optimizing, freeing them from the burden of determining granular resource requirements

CloudOps

Cloud operations teams can provide API-based optimization services to app teams, enabling them to run a safe and efficient environment

Finance

Finance benefits from the dramatically-improved cost efficiency that comes with machine learning

Achieve Continuous Cloud Optimization

Ready to try optimization as code for yourself?

Start Optimizing—Free!

Optimization as Code for Containers Your Containers Self-Optimize based on Machine-Learned Behavior

The Problem with Manually-Configured Kubernetes Pod Resources

Kubernetes is a powerful container scheduling technology, but it will still run inefficiently if the containers are misconfigured.

Kubernetes Pods consist of a set of containers that run on a common node. Each container specification has a CPU and memory resource request and limit.

It can be challenging for developers to determine precise values for these settings, either because they cannot project how the app will behave once live, or because they are risk-averse and want to play it safe. Both of these approaches make hardcoding the values justifiable, but the efficiency impact on the container clusters can be significant.

resource "kubernetes_pod" "nginx1" {
  metadata {
      name = "nginx1"
      labels {
        App = "nginx"
      }
    }
  spec {
    container {
      image = "nginx:1.7.8"
      name  = "nginx1"
      port {
        container_port = 80
      }
      resources {
        requests {
          cpu = "50m"
memory = "256Mi"
        }
        limits {
          cpu = "500m"
memory = "512Mi"
        }
      }
    }
  }
}
This container Pod is locked into hardcoded resource requests and limits

Self-Optimizing Containers—Powered by Optimization as Code

Densify™ solves this problem by learning the utilization patterns of containers and their Pods and scientifically determining the optimal request and limit values to ensure that the Pods get precisely the resources they need, while at the same time enabling the Kubernetes clusters to run at far higher utilization.

Densify™ also automates the process of updating the container manifests. By supplying one line of code that can be included in popular templating technologies like Terraform, Densify™ makes container applications self-optimizing. This enables developers to focus their apps, and lets infrastructure managers maintain high efficiency and safety by using automation to close the optimization loop.

spec {
  container {
    image = "nginx:1.7.8"
    name  = "nginx1"
    port {
      container_port = 80
    }
    resources {
      requests {
        #cpu = "50m"
        #memory = "256Mi"
        cpu = "${lookup(local.densify_spec,"appr_type") == "all" ? 
        lookup(local.densify_spec,"rec_cpu_request") : 
        lookup(local.densify_spec,"cur_cpu_request")}"
memory = "${lookup(local.densify_spec,"appr_type") == "all" ? 
        lookup(local.densify_spec,"rec_mem_request") : 
        lookup(local.densify_spec,"cur_mem_request")}"
      }
      limits {
        #cpu = "500m"
        #memory = "512Mi"
        cpu = "${lookup(local.densify_spec,"appr_type") == "all" ? 
        lookup(local.densify_spec,"rec_cpu_limit") : 
        lookup(local.densify_spec,"cur_cpu_limit")}"
memory = "${lookup(local.densify_spec,"appr_type") == "all" ? 
        lookup(local.densify_spec,"rec_mem_limit") : 
        lookup(local.densify_spec,"cur_mem_limit")}"
      }
    }
  }
}
This container Pod is self-optimizing—optimization as code ensures proper requests and limits are always applied

Achieve Continuous Cloud Optimization

Ready to try optimization as code for yourself?

Start Optimizing—Free!