Product
|
Cloud costs
|
released
November 3, 2020
|
3
min read
|

Implementing Your First Cloud Cost Savings

Updated
9/7/2023

The main goal of Harness Cloud Cost Management, a cloud finops tool, is to allow for the shifting down and democratizing of cloud cost information from finance to engineering teams. Now you as an engineer can see the impact of choices on your cloud spend. Getting up and started with Cloud Cost Optimization is pretty simple, especially that you can take Cloud Cost Management for a trial and see that the proof is in the pudding.  

Once Cloud Cost Management is up and running and recommendations start to appear, how do you execute the recommendations? If you are thinking about taking Cloud Cost Management for a trial or starting your journey with the product in your organization, Harness Continuous Delivery can execute those changes for you.

A Kubernetes Tutorial: Deploying a Sample Kubernetes Application

You will get the most mileage having Cloud Cost Management monitoring and recommending findings on an actual application/infrastructure. If you don’t have one at the ready can leverage using a sample application.  The sample application is the same one that we use when we teach our Continuous Integration example in its final form, a Docker Image.

Assuming that you have gone through the Getting Started example, the next step is to deploy an application. An easy way to deploy is leveraging Harness Continuous Delivery, which is in the same UI. Harness Continuous Delivery has an abstraction model that is pretty quick to set up and get running.

First navigate to Setup, click on +Add Application. Give a name like “Expensive App”.

The next piece to configure is an Environment to deploy to. A good spot would be the same Kubernetes Cluster you are leveraging for the Cloud Cost Management example [e.g where you deployed your Harness Delegate].

Setup -> Expensive App -> Environments + Add Environment. 

Once created, you need to define what the Environment is by creating an Infrastructure Definition by clicking on +Add Infrastructure Definition. The Cloud Provider Type is “Kubernetes Cluster” and the Deployment Type is “Kubernetes”. When going through the Getting Started example, you have already deployed a Harness Kubernetes Delegate and set up a Cloud Provider. You can select the already-provisioned Infrastructure to select the Kubernetes Cluster [e.g the Harness Cloud Provider] you want to deploy to.

When the Infrastructure Definition setup is complete, configure the Service, which is the application that you will deploy.

Setup -> Expensive App -> Services + Add Service. The Deployment Type is “Kubernetes”.

The first wiring is to define the Artifact Source by clicking +Add Artifact Source. Harness comes pre-wired with public Docker Hub. The example application e.g Amazing App is in a public Docker Hub repository and can be wired in with the Docker Image Name of rlachhman/amazingapp.

By default, there is not a container resource specification defined for the Amazing App. For the example, you can give a modest to large amount on what you think the Kubernetes resource limit and requests should be. You can modify the deployment.yaml in-line by hitting edit and adding the container resource constraints under Spec, Containers.

      resources:
        limits:
          cpu: "1.5"
          memory: "7Gi"
        requests:
          cpu: "1.5"
          memory: "7Gi"

Once you hit save, can create a simple Workflow to get the Amazing App into the wild.

Setup -> Expensive App -> Workflows +Add Workflow. The Workflow Type is “Rolling Deployment” and the Environment, Service, and Infrastructure Definition is what was created in the previous steps. 

Once you hit Submit, you are ready to deploy. Simply clicking on the “Deploy” button on the top right of the Workflow can kick off the deployment. Select the Build/Version [Docker Tag] you want to deploy and hit Submit to Deploy.

Navigating on the left-side navigation to Continuous Deployment -> Deployments, you can see your deployment.

With an application out of the way, sit back and relax over the next 24 hours if this is a fresh trial, Cloud Cost Management will start to aggregate and analyze cost data.

Recommendations are Ready

After about a day, your Cloud Cost Management Dashboard will be filled with information. Navigating on the left-side navigation to Cloud Cost Management, click on Explorer.

Seems like we have overestimated the firepower that the Amazing App requires; as the author of the Amazing App, it should have all it can get right?

Clicking on the Recommendations in the top right, we can see how overprovisioned we are and the potential cost savings.

Clicking into the Recommendation, we can see what appropriate resource limits should be, which is much less than we originally anticipated.

Clicking on the Workload link, we can see historical data on actuals vs requested resources which is a wide disparity.

Armed with this data, all we have to do is redeploy the application with the resource changes. 

Execute on Savings

With the Cloud Cost Management data in hand, let’s go ahead and make those resource changes.

Setup -> Expensive App -> Services -> “Big Amazing App”. In the deployment.yaml, re-modify the resource limits and requests to match the recommendations by clicking Edit.

      resources:
        limits:
          cpu: "25m"
          memory: "250M"
        requests:
          cpu: "25m"
          memory: "250M"

Then let Harness re-deploy the application. To show another way to deploy, navigate to the left-side navigation to Continuous Deployment, then Deployments. Click “Start New Deployment” and select the Workflow you created for the example.

Click Submit and you are now on your way to saving money.

With the much lower resource limits, your cluster can be free to scale and/or place more workloads. 

Save Money and Resources with Harness Today

The above example might be a little more simplified than your application in production. Saving resources is key even for agility. When creating the example, an unexpected result for me was being aggressive with the resource limits. If you exhaust your Kubernetes Cluster, this can impact you deploying another rolling deployment. The Kubernetes scheduler either needs to be tuned since there is an overage [max surge] which is needed to perform a rolling deployment and if all the resources are taken, even a surge of one more replica might not be fulfilled which unexpectedly happened to me.

Harness is here to partner with you on your journey in the cloud and an important step/realization in that journey is to get the wrangle on cloud costs. The benefits of on-demand infrastructure and cloud-native architecture allow for the next generation of agility. With the agility and ease of spinning items up, costs can certainly creep up. Sign up for a Cloud Cost Management trial and start to democratize cloud costs today!

Sign up now

Sign up for our free plan, start building and deploying with Harness, take your software delivery to the next level.

Get a demo

Sign up for a free 14 day trial and take your software development to the next level

Documentation

Learn intelligent software delivery at your own pace. Step-by-step tutorials, videos, and reference docs to help you deliver customer happiness.

Case studies

Learn intelligent software delivery at your own pace. Step-by-step tutorials, videos, and reference docs to help you deliver customer happiness.

We want to hear from you

Enjoyed reading this blog post or have questions or feedback?
Share your thoughts by creating a new topic in the Harness community forum.

Sign up for our monthly newsletter

Subscribe to our newsletter to receive the latest Harness content in your inbox every month.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Cloud Cost Management