We’re thrilled to announce the introduction of our Relay Proxy service for Harness Feature Flags. Users of Feature Flags can now use a proxy to sit between their applications and Harness, allowing for air-gapped environments, and providing additional caching and resiliency for mission-critical applications leveraging feature flags.

Maintaining High Availability and Security Using an External Tool

Whenever teams use a vendor service, they have concerns (rightfully so) around security and reliability. After all, if you’re using something like Harness Feature Flags to manage feature rollout and feature availability in production, you want to ensure minimal risk. For something like feature management, whose use extends beyond a core engineering team into other parts of the business, like product, sales, customer success, and marketing, it becomes even more imperative to have these concerns ironed out.

Let’s look at reliability and availability as the first problem to solve. Before external APIs became a thing, it was very common for dev teams to brush off the concept, saying things like, “Why would I want to add someone else’s downtime to my own?” And why would you? Software delivery has come a long way since then, and teams are more eager to use external tooling in order to speed up their development – while ensuring high availability at all times. For mission-critical applications especially, any new service, whether internal or external, must guarantee uptime.

The other side of the coin is security, and this is of utmost importance for enterprise-level organizations. It’s not uncommon for these organizations to have firewalls between the internal and external. It’s also not uncommon for these organizations to want to minimize their number of open connections to the outside world – an obvious consideration when you look at how large company tech stacks are. Can you imagine having at least one open connection per external API or tool, and more likely multiple? In fact, each new external connection can blow up the number of open connections exponentially. Each of these open connections poses a security risk, and additionally creates another access point that the organization cannot control.

For organizations at scale or that plan to scale, it’s paramount to have as much control over access to internal resources as possible and to maximize availability. In the world of feature flags, this takes on additional meaning. What happens in a feature flags world when something goes wrong in these areas?

• Customers receive the wrong features, or do not receive changes.
• Internal team members aren’t able to change flag configurations.
• Teams cannot validate the data which they receive back from a flag evaluation.
• Lots of open connections that aren’t being used but create costs or risk.

Creating a Single Safety Net to Meet Critical Requirements

To solve these problems, we built the Relay Proxy for Harness Feature Flags. The Relay Proxy takes all of the requirements and problems to be addressed above and solves them elegantly, while maintaining the benefits of using a feature management system.

Why Relay Proxy?

Ultimately, this service solves for two things: security and availability. By deploying the Relay Proxy, users of Harness Feature Flags can achieve the following:

• Air-Gapped Deployments: You can deploy the proxy in your network if you don’t have (or can’t allow) external access to your apps. Local apps connect directly to the proxy, and the proxy has external access to the remote feature flag service to synchronize configuration.
• Offline Mode: This is identical to air-gapped, except that the proxy does not have a connection to the internet. In that scenario, the configuration must be loaded from the outside using configuration files. Configuration files are used to link your programs to the proxy.
• High Availability / Reliability: The feature flag service is extremely reliable. We will fail over to the failover cluster in the event of a major failure. However, in the event of a full network loss, the Relay Proxy ensures that your apps continue to run even after restarts.

By deploying the proxy service, users suddenly find themselves able to minimize the number of open connections to Harness, and relieve themselves of the ever-imposing question of “How will this impact my customers if there is an outage?” Use of the proxy service ensures that Harness customers can meet their security and availability requirements of a feature management service – all of the benefits, with almost none of the risk.

How Does It Work?

While powerful in its value, it’s actually pretty simple how the Relay Proxy works. It lives between the SDKs used by developers and the hosted Harness Feature Flags services. On startup, the proxy service will load the necessary data from the Feature Flags services to ensure that things are completely functional, even if the network connection drops.

What you can see here is that users can now limit themselves to one outbound connection to Harness, instead of one per SDK, as would have been required traditionally. It additionally serves as a sort of configuration store or cache that the system will use to create the right outputs. Now, instead of having to rely on the Harness services, users can create their own safety net and work off of their personal cache at all times (which obviously will get updated both upstream and downstream).

How to Get Started

If you’re already a Harness Feature Flags user, you’ll want to head over to the Documentation for the Relay Proxy, which will describe in detail what it is, how it works, and how to deploy the proxy service in your own system.

And if you haven’t signed up to use Harness yet but want to get started, you can easily sign up for a free trial and see the proxy service in action. Happy developing!

The post Announcing: Relay Proxy Service for Feature Management appeared first on Harness.