Balancing Developer Freedom and Governance with OPA 

There is no trendier buzzword in enterprise software than “developer experience.” It’s been amazing to see the evolution over the last decade from an Ops-centric mentality to a Dev-centric approach as organizations move towards a DevOps model to increase velocity and achieve greater business agility. The shift towards a developer-centric approach has also driven large investments in cloud and platform engineering. 

Improving developer experience in the enterprise is a very challenging task. Historically, in most enterprise environments the time it takes for a new developer to get productive is typically 6+ months in order to understand the tooling, systems, and processes needed to start being truly productive in an enterprise environment. 

What Makes a Developer Happy? 

Besides good beer, the next biggest component in developer happiness is to have access to the tools and processes to get their job done quickly and effectively. Historically, in most enterprises, developers had to use bad legacy tooling. They were bound to sluggish on-premise infrastructure and tried to byzantine change review processes that would slow down production releases to annual or quarterly events. 

There is a new breed of developer that has only known the cloud-native world with instant access to infrastructure and pipeline automation and no longer accepts the paradigm of the past where developers had no control over delivery automation. These “born in the cloud developers” are what enterprises are trying to attract and struggling to keep. 

So, why not just give developers everything they want with no strings attached? 

The Platform Engineering Dilemma 

Platform engineering teams building out software delivery services want nothing more than to give developers the keys to the kingdom and get out of their way. The challenge is giving teams control while enforcing security, governance, and availability. Historically, it was very difficult for platform engineering teams to give developers freedom. Harness helped solve part of that problem back in 2017 introducing CD as a service with enhanced governance controls. However, even with fine-grained role-based access control and templates, in most regulated environments any pipeline stage that touched production was tightly controlled. So what are the levels of maturity when it comes to shared services for software delivery? This blog will highlight the different phases of delivery maturity and the characteristics of each phase. 

Software Delivery Maturity Phases

Phase 1: Free for All 

This level of maturity is rarely seen except in the early stages of startups, but it was pretty common when continuous integration (CI) was first adopted. Each development team had its own software delivery tooling with little to no standardization or governance. If other teams were involved in the delivery process, it was not unusual for artifacts to be thrown over the wall with little to no documentation about how to run or troubleshoot them effectively. 

Phase 2: Lockdown

After something happens with a phase 1 shop, usually a major production incident, the next level of maturity is a complete lockdown of software delivery. This is where a platform engineering team takes over the process, but business-facing teams have little to no control over the process. Any pipeline change involves a ticket to platform engineering as well as long wait times. In fact, one of the motivations for Drone founder Brad Ryzenski to build a CI tool was the months-long wait times for library changes to static Jenkins runners at the bank he was working at. This type of software delivery scenario is still very common in many regulated organizations today. 

Phase 3: Ankle Bracelets

This is probably the most common software delivery scenario for larger enterprises with a platform engineering team that has adopted purpose-built tolling for continuous delivery (CD). They have entitlements in place to allow developers to modify pipelines to customize for their needs, but any pipeline or pipeline stage that touches production-level environments is heavily regulated. Developers can modify lower environment stages, but only a select few modify production pipelines. This leads to a lot of friction between business units and platform engineering, and typically slows release velocity. 

Phase 4: Policy-Driven Self-Service

This is the highest level of maturity a platform engineering team can achieve for software delivery. At this level of maturity, the path to production is driven by a policy-based approach to governance that defines the requirements for a production release. Security scans, functional testing, change management approvals, and any other requirements for a production release are defined as a policy-as-code. Business units consuming the software delivery service have complete control over their delivery pipelines, and enforcement of governance is managed centrally by their policy as code. 

Getting to True Developer Self-Service with OPA 

So if getting to true developer self-service just requires adopting policy-as-code, why is this not widely adopted by platform engineering teams? There are a lot of things that can hold organizations back from adopting policy as code. Until the creation of Open Policy Agent (OPA) as the standard for policy code, there wasn’t an easy way to implement policy-as-code in software delivery.  Another thing holding back policy-driven self-service is the fact that CD in most organizations is still CI tools orchestrating scripts in most organizations. Having a declarative approach to CD is a requirement for policy-driven software delivery.

OPA is a powerful, declarative way to define policy as code and separating security policies from application releases to enable true policy-based governance at scale. Harness is the first software delivery platform to have an OPA-centric approach to governance. Before Harness, the only way pipelines integrated policy-based checks was with plugins or source code repository hooks, which typically led to a disjointed user experience and stifled adoption. 

In the Harness platform, OPA policies are a first-class citizen to help enforce governance across our entire platform. Policy authoring is built natively, and the ability to enforce policies on both the save and run of a pipeline gives organizations the ability to prevent non-compliant pipelines from being created in the first place. 

Policy-as-code goes beyond the pipeline across other capabilities of the Harness platform. A great example of OPA enforcement outside of the pipeline is Harness Feature Flags. Most enterprises are just starting to adopt a shared service approach to feature flag adoption, and managing standards across different business units can be very challenging. With OPA policies and Harness Feature Flags, shared service teams can enforce flag naming standards and requirements. 

One of the most popular policies we have seen adopted is the ability to prevent the enabling of a flag in production that is not enabled in specific lower environments. There have been many widely publicized examples of an untested feature toggle causing an outage (or, in the case of Knight Capital Group, bankruptcy) so policy-based governance is a must for any organization adopting feature management. 

Free Your Devs with OPA

It’s a developer-centric world, and a solid platform engineering foundation is a differentiator in keeping developers and product owners happy with high release velocity. The ultimate level of maturity in software delivery is a policy-based approach to governance to give developers the freedom to modify their own path to production with guard rails. Harness is the only software delivery platform in the industry that is taking a holistic approach to policy-based governance by adopting OPA as a native capability. 

To learn more, see a demo of our Harness OPA capabilities.