We are truly grateful for everyone who made our second {unscripted} Conference a success! Day two was jam-packed with great sessions, panels, and several announcements from Harness. Since the inception of Harness, we’ve been on a mission to allow everyone to deliver software simply, smartly, and scalably. 

Simple, Smart, Scalable 

Day two was kicked off by Jyoti Bansal, Harness’s CEO. Core to engineering efficiency and building confidence in software delivery is the Developer Experience (DX). The experience of the engineering teams when building and delivering features has a direct impact on those features and the organization overall. 

Jyoti discusses the importance of DX.

Jyoti, having built several organizations, elaborates on how scaling the Developer Experience can be complicated and requires a lot of effort across the organization. Complexity can creep in and become a burden, creating toil for engineering teams.   

Jyoti explains how multiple disparate pipelines, tools, and platforms to handle disparate concerns are incredibly hard to scale and produce a bad Developer Experience. 

As practitioners and leaders alike strive for better experiences and gains in engineer efficiency across the organization, the skills of the entire team continue to improve. As individuals continue their journey into leadership, the ability to instill confidence is key and is certainly not acquired overnight. 

The Road to Leading With Confidence

When talking to leaders in the software delivery space, certainly a rising tide in confidence raises all ships. There is no one path to leadership. Gaining the necessary skills, embracing, and championing a positive culture does not happen overnight. Especially in the DevOps space, change and culture take time. 

In the leadership panel, the panelists were very open and candid about their first forays into leadership roles. Going from a participant in a one-on-one meeting to leading one-on-one meetings with staff was a learning experience for all of the panelists. 

{unscripted} 2021 Leadership Panel
The DevOps Leadership panel discusses their journey to leadership and offers tips for those aspiring to become leaders. 

Leaders are there to help inspire and build confidence throughout the team and organization. Where there are modern challenges, leaders can help focus and channel the collective innovation of the team. With the ongoing push for many organizations into the public cloud, unforeseen and unforecasted costs can erode confidence.  

The Public Cloud, Designed for Cost Unconfidence?

There are a myriad of reasons why organizations are pushing into the public cloud. For the quick availability, agility, and elasticity of infrastructure to a reduction in capital expenditures, there are many great use cases for leveraging public cloud infrastructure. 

A challenge with the public cloud is a two-fold problem; underutilization of provisioned resources drives up the cost. Even if infrastructure is sitting idle or overprovisioned, cloud vendors will bill you regardless if fully utilized or not. No one team owns all the institutional, engineering, and financial knowledge to optimize cloud spend, which requires a cultural shift to be enabled with FinOps; similar to what DevOps has done. 

Shelby Lewin of Relativity discusses how product managers can embrace FinOps thinking in their products. 

Similar to how DevOps is removing silos between engineering disciplines and teams in organizations, FinOps hopes to achieve the same with cloud utilization and spend. FinOps learnings and principles span several teams and disciplines. Having a culture and practice of shared ownership is key. 

FinOps is an emerging space. Thought leaders in the space who are implementing FinOps cultures and capabilities in their organizations talk through the challenges and potential gains. 

Shelby Lewin of Relativity discusses how product managers can embrace FinOps thinking in their products. 

 Core to any modern practice is the ability to experiment and garner feedback which boils into optimization. Enabling iteration and experimentation allows for organizations to build confidence, even in relatively new spaces such as cloud cost optimization. Traditionally though, experimenting with software has been difficult. 

Experimentation

In previous paradigms, experimenting with software was fairly difficult. Because of long lead times to deploy changes or the ability to limit the blast radius (e.g. impacted users), it definitely was a challenge to experiment.

On the flip side, businesses have been experimenting for a long time. From product placement in retail stores to adjusting credit requirements for a loan, businesses have been using hypothesis-driven methods for a while. 

Now, this experimentation is more widely available in technology stacks because of Progressive Delivery and Feature Flags. Starting out primarily with mobile development, Feature Flags can traverse a wide swath of an implementation stack. 

Sam Hall from Metrikus walks through the journey that Metrikus took around Progressive Delivery and Feature Flags to reduce feature failure.

Metrikus was an early adopter of one of the several announcements that we were really excited to announce at {unscripted}. 

Harness Announcements

At Harness we have been hard at work executing on the vision of democratized software delivery for all. Finding and alleviating bottlenecks and items that erode confidence in the SDLC was the guiding principle. Build/deployment cycles having execution times increases due to test coverage sprawl is one example of a problem Harness has solved today. 

Test Intelligence 

A common distributed system fallacy is that one person understands the entire end-to-end of the system. This is not true. When adding new features or expanding test coverage, we are prone to a Big Ball of Mud pattern, both in development and test-wise. Execution times and complexity of test suites potentially increase with every new change. 

The Harness Platform now has the ability to provide intelligence around test coverage and execution times. Similar to the Harness Platform learning what is normal for a running application with Continuous Verification, these capabilities are turned towards engineering experience and test intelligence. 

Harness Continuous Integration Enterprise
Showing time saved by executing test coverage in an intelligent manner. 

Test Graph

Core to understanding the complexity and relationships between test execution and test coverage, the Harness Platform now has the ability to graph and model test coverage. With this modeling, tests can intelligently be run, making sure that only the tests needed to cover the appropriate change are run. This can result in huge gains in execution time and detangling the potential spaghetti of automated test additions. 

Test Graph models the test cases to cover specific code blocks/methods. 

By reducing the amount of time build and deployment cycles take, organizations can support more iteration. Focusing on the experimentation that iteration brings, Harness advances experimentation capabilities with Feature Flags.  

Feature Flags

Harness is pleased to announce the availability of the Feature Flags capability inside the Harness Platform. The ability to create, manage, and instrument feature flags are simple in Harness FF. 

Harness Feature Flags
Creating a new feature flag in Harness FF.

Feature Flags can be created and modified by a UI. Changing rules and scope can be performed by non-development resources. 

Harness Feature Flags Configuration
Configuring a new Feature Flag in Harness FF.

From a product manager/analyst standpoint, gathering data on a feature flag performance (e.g. adoption or invocation) can be challenging. Harness FF provides statistics out-of-the-box to help drive data-driven decisions. 

Harness FF provides metrics around a feature flag.

One last challenge that Harness wants to solve for you at {unscripted} is the second half of autostopping your workload/infrastructure; actually starting them back up for you. 

AutoStopping and AutoStarting

Terminating infrastructure and/or workloads by itself is easy. Though, a big objection to turning something off is, “What if I need this again?” Especially around lower/non-prod environments where confidence-building and development of new features takes place, recreating infrastructure can be a burden.  

Harness has been hard at work solving this problem. Not only the ability to create and fine-tune auto stopping rules, if the auto stopped infrastructure gets a request, the Harness Platform can now spin those workloads/infrastructure back up. This represents a leap forward to actually take into account actual usage vs static scaling rules, for example based on time.

Looking at a dashboard across AutoStopping Rules. 

At Harness, we continue to work every day to help every organization to democratize software delivery by removing toil. We are excited for what the year still has in store for everything we are working on – and looking forward to {unscripted} 2022. 

See You at {unscripted} 2022

We’re bidding everyone farewell for now, but like always, feel free to engage after the conference and come back to Harness for the latest and greatest around software delivery. We will surely have announcements throughout the year to help everyone achieve greatness in software delivery. 

Cheers!

-Kari, Tiffany, and Ravi