Forem: Francois Akiki

Unlocking Efficiency: Exploring Churn Rate With Harness Software Engineering Insights (SEI)

Francois Akiki — Fri, 15 Dec 2023 16:32:44 +0000

Improving the effectiveness and productivity of developers is crucial for the success of an engineering team. To achieve this, the team should adopt a metric-driven approach to identify the root causes that scales down the team's productivity. Out of the many metrics that engineering leaders can use to understand an engineering team's productivity is Churn Rate. In this article, you'll learn how high churn rates can impact the team and how Harness SEI can help lower churn rates in your organization.

What is Churn Rate?

In the context of software development, churn rate refers to the amount of work that is added or removed from a sprint backlog during a sprint. It measures the scope change and provides insights into the volatility of the sprint backlog.

A high churn rate indicates a lot of changes in the sprint backlog, which may result in delays in completing the sprint, and may also indicate that the requirements are not well-defined.
A low churn rate suggests that the sprint backlog is stable and the requirements are well-defined.

Why Churn Rate Matters?

Unveiling Sprint Volatility:

Churn Rate acts as a window into the dynamic nature of your sprint backlog. By understanding the scope changes during a sprint, teams can identify and address volatility, fostering a more stable and predictable development environment.

Optimizing Workflows:

SEI's Churn Rate empowers teams to optimize workflows by pinpointing areas of change mid-sprint. This insight allows for targeted strategies, ensuring that the development team can adapt swiftly and stay on course despite evolving project requirements.

Enhancing Collaboration:

With Churn Rate, collaboration between product managers and engineers reaches new heights. The metric provides a common ground for discussions, enabling both teams to make informed decisions and align efforts seamlessly.

The Formula Unveiled:

Churn Rate = (Points added mid-sprint + Points removed mid-sprint + Positive difference of changes in planned issues) / Points committed at the start of the sprint

Points added mid-sprint: The sum of story points for items added during the sprint.
Points removed mid-sprint: Identifies the reduction in story points due to the removal of items during the sprint.
Positive difference in planned issues: Reflects the positive changes in story points for planned issues during the sprint.

‍

Measure scope change in your sprint using SEI's Churn Rate metric

‍

Incorporating Churn Rate into SEI

SEI seamlessly integrates Churn Rate into its comprehensive suite of metrics, leveraging the power of the Trellis Framework. As part of the 40+ third-party integrations, Churn Rate ensures that your software factory's performance is not just measured but optimized, setting the stage for unparalleled efficiency.

Unlocking Potential with SEI's Churn Rate

In conclusion, Churn Rate emerges as a catalyst for transformative change in software development. SEI's commitment to providing actionable insights and workflow automation reaches new heights with this innovative metric. By understanding and harnessing Churn Rate, software delivery teams can not only increase productivity but also build a foundation for sustained excellence.

In a world where adaptability is key, SEI's Churn Rate becomes the compass that guides your software engineering ship through the ever-changing seas of development, ensuring you not only navigate challenges but thrive in the face of change. Experience the power of Churn Rate with Software Engineering Insights – where productivity meets precision.

Engineering teams can leverage Harness Software Engineering Insights to first baseline the people, processes and tooling bottlenecks and then drive a continuous improvement process. To learn more, schedule a demo with our experts.

‍Check out the original blog here!

Introducing the Harness SRM Backstage Plugin

Francois Akiki — Fri, 01 Dec 2023 04:53:28 +0000

We are excited to introduce the latest addition to our suite of Open Source Backstage Plugins - the Harness SRM Backstage Plugin. This plugin is designed to seamlessly integrate with your Backstage Instance as well as with Harness IDP to help with development team's workflow, ensuring that Service Level Objectives (SLOs) and error budgets are not just a metric but a part of your daily development practice.

Why Focus on SLOs?

Good Site Reliability Engineering (SRE) practices hinge on the continuous monitoring and adherence to SLOs. These objectives are pivotal in maintaining the reliability and performance of services. However, in the fast-paced world of software development, it's often challenging for developers to continually engage with separate observability tools. This is where our plugin bridges the gap.

Streamlining Observability

The Harness SRM Backstage Plugin is more than just a tool; it's a solution to a common oversight in the development process. By aggregating SLO data from Harness Service Reliability Management Module, this plugin brings critical insights directly to the developers' dashboard. This integration means that your team no longer needs to switch contexts or platforms to monitor their SLOs.

High Availability of Adequate Information

With this plugin, information about SLOs is not tucked away in a separate tool but is readily available in the Developer Portal. This accessibility ensures that your team is always aware of the current status of your services, leading to quicker responses and resolution if SLOs are at risk of being breached.

Empowering Developers

By making SLO data readily available within the familiar environment of the Developer Portal, the Harness SRM Backstage Plugin empowers developers to take proactive steps in maintaining and improving service reliability. This approach not only enhances individual productivity but also fosters a culture of accountability and ownership within the team.

Conclusion

In summary, the Harness SRM Backstage Plugin will help with how development teams interact with and respond to SLOs. By integrating critical data into the daily workflow, it ensures that adhering to good SRE practices is not an additional task but a seamless part of the development process.

‍Signup today for SRM Module and start using the Plugin to experience the difference this plugin makes in your team's efficiency and the reliability of your services.

‍Check out the original blog here!

Harness Chaos Engineering Faults Landscape

Francois Akiki — Tue, 28 Nov 2023 03:38:11 +0000

Harness Chaos Engineering provides a library of chaos faults using which chaos experiments are constructed and run. It is simple and intuitive to construct the chaos experiments using the given set of chaos faults. Before we delve into the details of the faults, let's look at the anatomy of a chaos experiment and the role of the chaos faults in the chaos experiments.

Quick Review of a Chaos Fault and a Chaos Experiment

A chaos fault is an actual fault or some distress injected around a system resource like CPU, Memory, Network, Time, IO system, Nodes, etc. A chaos experiment is an attempt to measure the resilience of a system when one or more chaos faults are run on it. In Harness Chaos Engineering, an experiment not only runs chaos faults, but it measures the resilience of the system in the context of the faults that were run.

When a chaos experiment is completed running, it provides a “Resilience Score,” which indicates the resilience of the target system against the faults that are injected. The Resilience Score is the % of successful steady state measurements measured during the chaos experiment execution.

Resilience Score of a Chaos Experiment

A developer who is designing and implementing the chaos experiment controls the meaning of a Resilience Score. The higher the number of steady state checks or probes passed during the experiment execution, the more it contributes to the resilience score. The steady state measurements in Harness CE are done through the Resilience Probes. Many resilience probes can be attached to a fault. The more probes you add to the faults inside the experiment, the more realistic the resilience score of the experiment will become.

The Resilience score of a chaos experiment = The percentage of successful resilience probes in the experiment.

Construction of a Chaos Experiment

‍

Chaos Fault Landscape in Harness Chaos Engineering

Faults for Kubernetes Resources

Runs via the Kubernetes Chaos Infrastructure or Agent

Supported Faults:

All Pod related faults, Node faults, http faults, IO/database chaos, network faults and load chaos. These faults are certified for the cloud Kubernetes services like EKS, AKE and GKE as well as for the on-prem versions like RedHat OpenShift, SuSE Rancher and VMware Tanzu.

Faults for VMWare Resources

Runs via the Kubernetes Chaos Infrastructure or Agent

Supported Faults:

Chaos faults are either injected through the VCenter APIs or through the VMware Tools directly on the operating system running inside the VM. Some faults such as VM power off, VM disk detach and VM host reboot are performed at the VCenter Level. Most of the common faults related to CPU/Memory/IO/Disk stress, http, DNS and Network faults are performed through the operating system through VMware tools. All the common faults are supported for the VMs running on Linux or Windows.

Faults for Linux Resources

Runs via the dedicated LinuxChaos Infrastructure or Agent

Supported Faults:

All faults related to resource stress, network and process. DNS error and spoof, Time Chaos and Disk are also supported. With ssh fault, network switches can also be targeted.

‍

Faults for Windows Resources

Runs via the Kubernetes Chaos Infrastructure or Agent

Supported Faults:

All faults related to resource stress, network and process. Time Chaos and Disk fill are also supported. These are supported for Windows instances that are running on Azure, VMware and AWS.

‍

Faults for AWS Resources

Runs via the Kubernetes Chaos Infrastructure or Agent

Supported Faults:

Deep coverage in the chaos faults for EBS, EC2, ECS and Lambda. AZ down faults for NLB, ALB and CLB. Some faults for RDS. All Kubernetes faults are supported for EKS on AWS.

Faults for GCP Resources

Runs via the Kubernetes Chaos Infrastructure or Agent

Supported Faults:

Faults for GCP VM disk and instance. All Kubernetes faults for GKE.

Faults for Azure Resources

Runs via the Kubernetes Chaos Infrastructure or Agent

Supported Faults:

Faults for Azure VM disk, instance and web app. All Kubernetes faults for AKS.

Faults for Cloud FoundryResources

Runs via the dedicated LinuxChaos Infrastructure or Agent

Supported Faults:

Support is extended for Pivotal Cloud Foundry as well as any other Cloud Foundry versions. Faults for Cloud Found App like Delete App, remove routes to app, stop app, unbind service from app etc are supported.

Faults for Spring Boot Resources

Runs via the Kubernetes Chaos Infrastructure or Agent

Supported Faults:

Chaos faults for Spring Boot Apps. App Kill, CPU Stress, Memory Stress, Latency, Exceptions and any chaos monkey fault as wrapper.

Conclusion

Harness Chaos Engineering supports a wide variety of chaos faults that spans across Operating systems, Cloud platforms and Kubernetes. These faults enable end users to verify the resilience of the code being deployed to the target systems or of the systems serving business critical applications. Check out all the Harness Chaos Faults on the Harness Developer Hub.

[

](https://app.harness.io/auth/#/signup?module=chaos&utm_source=harness_io&utm_medium=cta&utm_campaign=ce&utm_content=hero)

‍

‍Sign up FREE to experience the ease of resilience verification using chaos experiments. Harness provides a free plan that enables you to run a few chaos experiments free of charge for unlimited time.

‍

‍Check out the original blog here!

Start or Expand Your DevSecOps Education Journey - Introducing STO Developer Certification

Francois Akiki — Tue, 28 Nov 2023 01:44:17 +0000

As systems grow more distributed, complex, and critical to our daily lives the fog of development starts to set in; no one person has complete end to end visibility into the entire workings of a system. To combat the fog of development, dissemination of expertise across your pipelines is crucial. Security in an application and infrastructure context is a good model of this with the DevSecOps movement.

Software development teams are becoming more tasked with shifting left requirements to produce hygienic software. In the real world, software ages like milk and not like wine, so what was hygienic today might not be hygienic tomorrow. Your CI/CD pipelines are conduits of change and are excellent spots to disseminate expertise and ensure compliance and standards to security posture.

Harness’s Security Testing Orchestration or STO module is purpose built for your pipelines by orchestrating and prioritizing results from a multitude of scanning tools. Most organizations will have more than one scanning tool because tools can be granular or vertical in focus around a few pillars such as intent, language, and distribution. Because of the complexity of modern systems, everyone involved with the development of these systems should take a stake in helping secure these systems.

Security, Everyone’s Responsibility

At Harness, we view security as an important skill to have, we are offering our STO Developer Certification for free so everyone can up-level their DevSecOps skills. Taking a look at our study guide, will provide a great foundation around application vulnerability management.

STO Dev Cert Study Guide

Because so many components are in modern software today, keeping up with the bill of materials / how components age can be tricky. Harness STO can help you identify and prioritize issues that do need to be addressed. Having Harness STO as part of your pipeline is a prudent capability and being certified in Harness STO is a great skill to have.

Study and Sign Up Today

Getting certified at the developer level on Harness Security Testing Orchestration is a great milestone in your DevSecOps journey. Register for the exam from the Harness Developer Hub once you feel comfortable taking the exam.

-Harness Product Education Engineering Team

‍

‍Check out the original blog here!

Architecting for Cost Savings on BigQuery

Francois Akiki — Thu, 16 Nov 2023 23:18:22 +0000

This blog was co-authored by Nikunj Badjatya, Principal Software Engineer and Abhijeet Sharma, Senior Software Engineer at Harness.

‍

At Harness, we leverage our own products extensively in our software development lifecycle, as would be expected from a company such as ours. Our engineering team is responsible for our CCM software architecture, and has direct visibility into our production costs by team and by module (among other views), and we review our cloud costs regularly to find areas for optimization for both our product costs and product performance.

It was during one of these reviews that we began to see our BigQuery analysis costs rising beyond what we were expecting from our rapidly growing installed base. Our CCM product dashboards and reporting are built on top of BigQuery, so each time our users view dashboards or run reports, it consumes on-demand compute capacity (or compute slots by the new pricing), alongside the monthly charges for storing the cost data itself.

What led to starting the project?

As the Harness CCM installed base has grown in both quantity and size of customers, we are seeing an increase in customers for whom we are ingesting GBs of cost data daily. As we began ingesting historical data for a major new customer, we were watching both our query and storage costs spike at an alarming rate. As you can see in the Perspective below, our BigQuery costs were up 73% over a 6 month period!

Customers are getting more mature in their FinOps practices, expanding their reporting among product teams, so we were also seeing an increase in usage of our Perspectives and BI Dashboards. Bigger, longer term dashboard views led to larger and more frequent calls to BigQuery, which was also impacting our costs. For example, one customer wanted to see 2 years of cost data in a single dashboard view. That’s a high volume of data!

Big Query Historical Costs

The quantity of data was also beginning to impact the performance of our dashboards, as queries were taking longer and dashboard response times were slower, especially for customers with large datasets. Our customer experience is extremely important to us, so we knew we needed to take a hard look at our BigQuery structure to improve user experience, while also making a positive impact on our product’s bottom line.

BigQuery Pricing

As an aside, when we started our project to optimize our database structure, we also needed to assess our transition to the new BQ Editions pricing, and how it would impact us. When we first introduced Harness CCM, on-demand compute pricing was the only available option, but Google introduced BQ Editions earlier this year, and given the growth of our dataset, it made sense to assess making a shift.

This became an urgent change once Google announced a 25% increase in on-demand pricing, which would directly impact our bottom line. Our queries were growing in size of data retrieved, but we were looking relatively healthy for our slot usage as it’s billed in BQ Editions. So we made the switch, avoiding an immediate 25% cost increase!

What the Engineering Team Thought

As we brainstormed several different areas for improvement, we realized that we needed even more granular cost information by customer and use case, so we started by building a new BI dashboard to provide deeper insights into BQ costs by customer. This helped us segment BQ costs by customer size as well as activity levels, which allowed us to better characterize our cost drivers.

After reviewing the data, the team determined that we would get the best improvements for both cost and performance if we tackled the following challenges:

Flatten out nested labels to reduce UNNEST operations
Caching data in Looker with Persistent Data Tables
Review data ingestion frequency
Improve gatekeeping by license type

Flattening Out Nested Labels

We ingest customers labels from each of the cloud service providers our customers use, storing them in a BigQuery table as nested labels, as using nesting is a Google best practice to “denormalize data storage and increase query performance” while maintaining hierarchical relationships between labels.

During our investigations we discovered two things: first, that label queries were the single biggest contributor to our BigQuery costs; and second, that the way we had originally implemented our label storage was causing a high amount of UNNEST calls, increasing both response times and data transfer costs.

BigQuery Label Queries Driving Major Costs

By flattening out how we store labels into a columnar format, we could eliminate the need for UNNEST calls which would improve both query performance and data transfer costs. This wasn’t a trivial change, but the effort yielded significant returns for us. We not only improved our immediate cost concerns, but ensured that this part of our database architecture was ready to handle the acceleration of customers adopting Harness CCM.

Looker Persistent Data Tables

Our customer facing Business Intelligence (BI) dashboards are powered by Looker, so that customers have a powerful BI tool at their fingertips for analyzing cloud costs. When we discovered that label queries were driving so much of our BQ costs, we realized that we could reduce a portion of that workload by caching data within Looker by using their persistent data tables (PDT).

We started by implementing them manually for our biggest customers in terms of dashboard usage to assess the impact on query costs and performance. It made a material impact on the frequency of BQ retrievals, so the next step is to automate the creation of PDTs when customers reach a certain threshold of dashboard usage within their account.

Review Data Ingestion Frequency

We always want to provide the most up to date information for our customers, so we pull cost data from the cloud providers multiple times per day to give our customers the most up to date costs. However, as part of this inquiry, we took a look at exactly how often customers themselves were looking at this data, whether through directly accessing the Harness console, or by sending automated, scheduled reports via email or Slack.

We realized that we had anticipated a use case that no one actually needed. Reports are generally sent weekly, or at most every day or two. Our own anomaly detection generally runs once per day well. So we were ingesting data (with the associated data transfer fees to BQ), more often than was needed / wanted, running up our own cloud bills unnecessarily.

We decided that once per day data ingestion from the cloud providers fit the actual use case our customers wanted. Implementing this change contributed a fair amount to our cost reduction efforts.

Improve Gatekeeping by License Type

Gatekeeping is easily one of the most impactful, but sometimes neglected, tasks for managing data, and as we reviewed our dashboards by customer usage, we realized that we were retrieving data into BigQuery that didn’t need to be.

For context, only our Enterprise license customers have access to our BI Dashboards feature for advanced analytics. Anyone using our Free tier, free trial, or engaged in a proof of value (POV) can’t access the BI Dashboards in our console. But we weren’t gatekeeping the data ingestion for our non-paid customers, and were ingesting data that wouldn’t be used.

Implementing a license check prior to ingesting data into BigQuery for Looker reduced the amount of data we were storing, which in turn also reduced our data ingestion fees for our existing customers. More importantly, it is also cost avoidance for the future, especially as our POV activity continues to grow.

Results Speak for Themselves!

After we implemented all of these BigQuery architectural changes, we were very pleased to share with the company that we had reduced our direct BigQuery costs by nearly 45%, while improving dashboard performance for our customers, especially our largest customers with large datasets. And don’t forget that we also had an indirect 25% savings by moving over to BQ Editions pricing.

Cost Savings After BigQuery Architecture Changes

These changes were critical for us as we continue to grow and scale our customer base. We’re now in a better position to keep our BQ costs in control, while giving our customers a better user experience.

Closing Thoughts

This exercise involved numerous technical discussions within our internal teams, several different POCs to prove our theories and test changes, as well working closely with the Google BigQuery team to drive the correct implementation. Without a concentrated effort on the larger groups part, this change wouldn’t have been as successful as it is. We are very appreciative of the work that everyone involved put into this project.

This was just one example of BigQuery architecture changes that can be made to reduce cloud costs and improve performance. You can read about more cloud cost savings strategies we implemented a few years ago in this blog. If you want to learn more about Harness Cloud Cost Management, read about it here!

‍

----------------------------------

Editors Note: This is one of a new series of blogs that are focused on how Harness Cloud Cost Management users are “Architecting for Cost Savings”, highlighting their experiences where cloud architectural decisions and changes have positively impacted cloud costs. Other blog posts in the series: Architecting for Cost Savings at Tyler Technologies

‍Check out the original blog here!

Adventures at MagnoliaJS

Francois Akiki — Mon, 06 Nov 2023 18:56:54 +0000

Last week I had the great pleasure to speak at a very intimate developer community event in Jackson, Mississippi. The event I spoke at is called MagnoliaJS. MagnoliaJS is ran by two great community ambassadors, Kayla & Richard Sween, as well as a great group of volunteers. This year the event was Halloween themed. There were decorations outside the venue, as well as spooky coffee cups, various Halloween candy scattered about, and even speakers and attendees in costumes.

This year's event I did not plan accordingly lol. You would think that the horror fan would have had his stuff together…nope. There was a Spirit Halloween nearby but I felt that next year I could plan better and just talk up my idea to the community. Be on the lookout for what Kayla and I have cooking up.

‍Day One

Day one of the event was everything you could ask for. The day kicked off with opening remarks by the one and only, Kenneth LaFrance. When I say the one and only, I mean he is Kenough! IYKYK lol. Following Ken’s opening remarks, Taylor Desseyn from Gundot.io opened up with content creation

The day was filled with great speakers from Alex Riviere with their talk on design systems, to Rizel Scarlett with an AMAZING talk on breaking down barriers through the use of emerging tech. Rizel is a Staff Developer Advocate at TBD. Make sure you attend a session of theirs if you ever get a chance.

Throughout the day we had talks from Karl Groves, speaking on accessibility, to Pato Vargas displaying immense knowledge on simplifying your codebase with React monorepos. If you get a chance to watch Karl deliver his accessibility talks, and Pato literally talk about anything, don’t sleep on it. Trust me.

Taylor closed out the event with another great talk. Taylor is the former Managing Director of Global Solutions at Vaco. Now Taylor is at Gun.io as a Talent Advocate. To sum up his talk, the abstract below explains it all.

This is a checklist that every leader in an organization needs to check out to be successful in scaling their company when it comes to hiring.

‍Day Two

Day two kicked off like day one with opening remarks from Ken LaFrance. Ken gave yours truly an incredible introduction as I kicked off the conference. I delivered my talk on the relationship between ROI (return on investment) and a11y (accessibility). Of course I opened up with who I was, my role at Harness, and what we do at Harness. I can safely say that 99% of my audience now knows who Harness is and what we are all about. It was eye opening.

Mo Daniel gave their VERY FIRST talk ever. Mo is one of the nicest people I have met in my life. Their talk really hit home when it came to learning. They ended their talk with a positive affirmation and we all stood and clapped for an amazing performance.

I joined in on a talk where I did a voice over as a sea captain along with Abbey Perini and Nerando Johnson. That was a blast to do. My friend Mark Noonan, Senior Software Engineer at Cypress, delivered a talk on front end testing. And we all did voices as characters throughout the talk. I even dropped a Jaws reference and luckily most of the audience got it.

There were a handful of great talks over the two days of the event. I wish I could cover them all here. Todd Libby closed it out with his accessibility talk on Deceptive Patterns & FAST. And in his Halloween, East Coast fashion, he came out of the entrance where the kitchen is, dressed in a Lobster costume and uttered the words, “man is it hot in there!”

If you get a chance to attend or speak at MagnoliaJS, definitely do it. Great people, great talks, great community.

‍

Social image and cover image from the MagnoliaJS Twitter. All images below are from myself or community members.

‍

‍Check out the original blog here!

‍