Your first Harness CI installation, build, and publish | Harness blog. Harness CI, powered by the acquisition of Drone.io, simplifies the continuous integration process by integrating with source code management platforms and utilizing a server-runner model, enabling teams to quickly set up and execute their first builds with minimal configuration. Split Software, Inc. is very excited to introduce Harness CI to the world. Your Harness CI journey starts with Drone, a popular continuous integration platform. If you are unfamiliar with Drone, Drone is a modern platform designed for low barriers of entry into the Continuous Integration space which connects to your Source Code Management [SCM] platform. If you are unfamiliar with Continuous Integration, don't worry Harness has you covered and Split Software, Inc. will be helping everyone gear and strengthen their Continuous Integration capabilities. Harness CI / Drone is simple to get up and running, looking at the architecture there are only a few moving parts. Harness CI / Drone architecture. Harness CI / Drone has a Server to Runner model. A Server orchestrates the runners which perform the tasks. The Harness CI / Drone Server authenticates with your SCM provider and then via a shared secret communicates with the Runners. Wiring up these pieces are pretty simple. Let's get started. In this example, the moving pieces will be a GitHub Account, a running CentOS machine, a Kubernetes Cluster, and a Docker Hub account. The example GitHub repository can be cloned/forked before this example at GitHub. GitHub / SCM prep. The Harness CI / Drone Server needs to authenticate with your SCM provider. This is accomplished in GitHub by making an OAuth application. This is done by navigating to Settings -> Developer settings -> OAuth Apps + Register a new application. When you register a new OAuth application, you will need to have the DNS/IP address of the Drone Server handy. In my case this is 34.207.222.178. The callback URL has /login appended to the Homepage URL. When you register the application, make sure to note the Client ID and Client Secret, which will be needed to wire the Harness CI / Drone Server. CentOS / harnessci/drone prep. Depending on where you get CentOS from, you might have to install Docker Engine. Assuming that you have Docker Engine installed, the only piece of prep you need on the server before installing is to generate the shared secret which will be used for Server to Runner communication. Make sure to copy down the shared secret [RPC Secret]. Harness CI / Drone installation. To get Harness CI / Drone on your machine, simply run a Docker Pull on the image. Once pulled, you can configure the properties for Docker Run. The properties to fill in for barebones are the secrets and server address and protocol. Let's go ahead and create an admin user. The admin user follows your GitHub username. One issuing the Docker Run commands with the properties, you can head to the IP or DNS entry of your Harness CI / Drone server. In my case navigate to https://34.207.222.178. You will be greeted to authorize your user via GitHub. Once Authorized, Harness CI / Drone will build a list of repositories. Now you are ready to deploy runners, in this case Kubernetes. Kubernetes Cluster prep. In this example, Split Software, Inc. will leverage the Kubernetes Runners. For the Kubernetes Runners to request resources on your behalf, a Role Binding is needed as well as the Runner Deployment. A simple approach is to build out two YAML files, one for the Role and Role Binding and another for the Deployment. In the Runner Deployment Spec, make sure to update the Drone Server, Shared Secret, and Protocol to match your installation. When the items are filled in, can deploy the Deployment. Optionally you can validate that the Runner is connected to the Server. Get the Pod Name then run a log command. Success! Now would be time to start marching towards your first build. Marry the CI and SCM together. Harness CI / Drone leverages Configuration as Code to describe pipelines. Harness CI / Drone can work off of webhook requests from the Source Code Management solution to orchestrate when a new build needs to be kicked off. Prep the Repository. Can leverage the Harness CI / Drone UI to "activate" the Repository. In my "firstdrone", repository, the webhooks are empty. In the Harness CI / Drone UI, navigate to your repository of choice and then Active Repository. For the example, the defaults are fine for the Repository Activation. The configuration to modify if needed is the name of the Drone Configuration file to monitor. In this example, you will monitor for "Drone.yaml" in the repository. Then you can validate that the webhook has been successfully created in GitHub. With the CI and SCM wirings out of the way, the next steps are to define your first pipeline and fire off a build. Your first Harness CI / Drone project. If starting out with an empty repository you can leverage a simple example of a project structure or wire together your own project/repository. If following this example, you wired into Harness CI / Drone to watch out for "Drone.yaml". The declarative pipeline format is easy to wire in needed steps and not needing to worry about plug-ins. In the example pipeline, Split Software, Inc. leverage the Docker Plug-in for the publish setting and well be downloaded automatically during execution time. The highlighted lines are leveraging secrets to wire in my Docker Hub credentials. You need to update the repo location to your own and create Harness CI / Drone Secrets to wire in. Back in the Harness CI / Drone UI, navigate to the repository settings, and add the needed secrets. Add the appropriate secrets to match the format of the example. With those wirings out of the way, you are now ready to kick off your first build and publish it to Docker Hub. Your first build and publish. With the wirings out of the way, all that is left is to commit the Drone.yaml with some sort of change and you are off to the races. Once you hit Commit changes, the CI magic starts, and your build and publish are off! Success! Congratulations on your first Harness CI / Drone build and publish! Harness and Drone, better together. Split Software, Inc. is thrilled to further the Harness CI / Drone communities alike. If you want to communicate with the Drone Community, feel free to jump on the Drone Gitter and learn from all the wonderful folks. Split Software, Inc. has lots of great plans to further CI and CD capabilities alike making them simple and democratized for everyone. Be sure to stay tuned as Split Software, Inc. announce more updates. Welcome to the Harness family, Drone! Doesn't matter if your idea is small or silly. I'm here to help to get your idea out to one or billions of users.

Lessons from the Harness Cloud Cost Management | Harness blog. Harness Cloud Cost Management enabled users to achieve significant savings, with one realizing over $500K annually, and improved cost visibility from weeks to hours, fostering a cost-aware culture and continuous cost optimization. Cloud spend is forecasted to reach over $360B by 2022, predicted to be fueled largely by speed of delivery and innovation. (Source: Gartner). At the core of this innovation are the engineering decisions that can sometimes prove costly, causing bloated cloud bills and inefficient resource usage. Cloud cost optimization is crucial in balancing software velocity with operational efficiencies, as Split Software, Inc. learnt from its users. Split Software, Inc. launched Harness Cloud Cost Management, its cutting edge finops tool, in BETA and have been working with a few customers to understand their specific problems in managing cloud costs these past few weeks. The feedback Split Software, Inc. has gotten so far has been overwhelmingly positive. One of its users was able to realize over $500K annual savings within days of using the product. Another claimed that they could now be more proactive about feature releases & anticipated traffic with cost visibility in hours vs weeks. Here's a summary of what Split Software, Inc. learned and how Split Software, Inc. iterated quickly to address their challenges. You have probably heard of Shift-left or shift-right. But what is shift-down? Shift-down is the ability to empower engineering - developers, dev-ops, SREs - with useful and actionable cost-insights that may have traditionally been in the hands of tech-savvy financial analysts & executives. A majority of its users mentioned that most members in their teams didn't have access to cost-management products. Those from business who did have access lacked the specific context of the decisions being made that caused costs to change. One of its beta users mentioned, "it helps to know that my developers have cost information at their fingertips. It helps them be more proactive about their spend while at the same time not get overly nervous about what every minor change might cost them". It helps drive cost transparency across key stakeholders while empowering individual developers and DevOps engineers to build trust with their finance counterparts. One of its users claimed that they finally have a tool that is friendly to people spending the money, and not just the ones counting it. #2: digging into cost data or root-cost analysis. Containers and container orchestrators are a popular choice for most teams. However, traditional cost allocation strategies are massively challenging due to the lack of visibility into granular cost data. Cloud providers provide billing data only for the usage of the underlying server instance, but when this server instance is running multiple containers, you need additional information to figure out the cost of running those containers. How much of that server was used by a container for service foo vs service bar? How many of those nodes had unallocated resources claimed by containers? How many of those containers had resources that were claimed but were idle? Its beta users pointed out that starting with the account or service instance, and being able to drill all the way down to a specific micro-service or container was critical to optimizing costs. At Harness, Split Software, Inc. call this root-cost analysis. Root-cost analysis led one of its beta customers to save over 182K in annual costs for a single overprovisioned Kubernetes cluster in one of their dev environments. Another explained what would ordinarily take 4-5 days with their existing cloud cost management product, now took them 20 minutes. To understand true cost drivers of any service, one needs to look beyond the aggregated daily/weekly/monthly details that most native cloud cost products such as AWS, GCP & Azure provide. They are very useful to get started, but its beta users noted that they'd hit a wall trying to understand how much a service, application or a product cost, and what each of their teams spend in research & development or in production to serve their end customers. Small/mid-sized companies used show-back, to let teams know what they were spending, and the more mature companies used chargeback to associate costs to the team's budgets and P&L. Split Software, Inc. worked with users on either side of the spectrum and the common pain-point across most was, it isn't easy to isolate resources and map them to an application or a product without diligently tagging them. You can circumvent the need to tag your services, at-least the ones you deploy with Harness since Split Software, Inc. understand the construct of your applications/services and the infrastructure they are deployed to. The below representation illustrates how such a breakdown occurs by leveraging existing Harness deployments. To be able to understand the cost of serving customers, it is important to know your cloud spend in Research & Development (Dev, QA, Staging, etc) and Production. Split Software, Inc. saw many variants of how its users were able to do this and learned quite a bit from each of their experiences. Some had their spend distributed across Kubernetes Namespaces and knew precisely what they were. Some used Kubernetes labels to group pods by their end customers, team/owners, or release/version. Another user wanted to understand the cost of their newly deployed/launched service and if it was more than they'd expected. My personal favorite was that of one of its users who wanted to run their workloads for a few hours and understand costs on a per-hour basis to simulate a real production workload. Split Software, Inc. rolled out the hourly granularity feature within days and this helped them understand their spend better and what to charge their end-customers. Its users are just scratching the surface, and there are tons of opportunities to be able to leverage Harness for understanding and protecting cost margins. #5: granular cost governance. Most users traditionally managed costs broadly by cloud accounts, subscriptions, projects or services. Some had weekly or monthly reports sent to key business executives or finance stakeholders and would typically wait until the end of the month. Others were more proactive in managing budgets, meeting more aggressively and having open and transparent conversations. What Split Software, Inc. learnt was that the alerts they received were informational for the most part. The goals weren't broken down to granular targets by teams who owned specific microservices, namespaces, clusters or environments (such as production, staging, development QA etc). There was also a desire to forecast spend against a granularity like a namespace for the next quarter as an example. Harness provides the ability to govern spend at all levels of granularities and divide company goals into smaller targets owned by teams to self-manage costs. One of its beta customers, a services company in the public sector claimed, "Since our clusters host applications from many different business units, it has been very difficult for our finance team to accurately allocate cloud computing costs to the right P&L. With Harness, that task becomes trivial and we can now shift down the responsibility of cost to our engineering teams" A key learning for Split Software, Inc. observing users during beta was that cost isn't a one-time fix. It needs continuous monitoring when infrastructure is provisioned in the cloud, test environments are created but not destroyed, clusters are auto-scaled with considerable cushions specifically for production workloads or when there are investments in new initiatives. Its users in beta encountered all these scenarios, some more frequent than others. While they told Split Software, Inc. they didn't want to constantly watch dashboards, they did want to be notified when costs spiked. Besides having access to the cost data, they considered consolidating deployment tools with costs as a huge benefit since they didn't have to switch between multiple tools to know the impact of their pipelines. A deployment event such as launching a new version of a service could be looked at in the context of its impact on cost, for instance. Below is a trend of one of the namespaces its customers enabled to monitor their team's cost. As you can see, the costs tend to creep back up and needs to be continuously monitored to keep them within bounds. For more information and to request your demo of Harness Cloud Cost Management. Passionate about building/scaling new products and new businesses. Thats what I do at Harness. Worked at early/late-stage startups & big-cos from idea to scale. Was part of the AI/ML team at UiPath - launched Insights, a product that measures operational and business impact of robotic automations. Prior was at AppDynamics where I helped scale Business iQ (correlates application performance (APM), user experience and business outcomes). Worked at a couple of big-cos- led the migration of vCenter to a software appliance at VMware for >500K customers. Was also the founding member of Oracle's IoT strategy team. Started my career in research, immersed in Speech R&D - building a free voice-based tutor for kids at IBM Research Labs and research prototypes in speech coding at Siemens R&D. Co-authored 8 IEEE publications and a book titled "Ultra Low Bit-rate Speech Coding" published by Springer. Paid downloads >4000