Harness uses Kubernetes for On-Premises Deployment

Our goal at Harness is to enable our customers to deploy their software as fast as possible. Our customers love us for the ease with which they can confidently deploy their code to production using Harness. We take this goal very seriously and strive to incorporate that objective as part of our everyday effort. That means the Harness R&D team is constantly pushing out new features at a breakneck speed. This means pushing code out multiple times a day. As a result, our Cloud solution is always up-to-date with our latest and greatest features.

However, this becomes challenging to manage our On-Premises version of Harness. Anybody who has worked in the enterprise software space is aware of the difficulties that we face with respect to releases and upgrade cycles. On-Premises solutions of any enterprise software are upgraded sparsely, maybe a couple of times a year, sometimes even less frequently.

There are multiple reasons for this behavior:

• A customer does not have a cadence to upgrade more frequently
• Management of the upgrade is an overhead
• Why touch something that is working fine?

From the enterprise software developer’s perspective, this can introduce other issues:

• Managing multiple releases over a long period of time can become expensive
• Dealing with bug fixes on different versions is a nightmare and can significantly eat into the R&D team’s overall time
• Longer release cycles mean more breaking changes being pushed out, entire R&D team is on edge at releases
• There is always a lag between release and adoption, code maintenance overhead increases significantly.

These problems are exponentially compounded when you release frequently multiple times a day.
So how should we balance the slower On-Premises releases with the more frequent Cloud based releases?

To address this challenge, we at Harness have adopted the Connected-On-Premises model.
Connected-On-Premises is our preferred delivery mechanism for our customers who like to have Harness installed in their environment as an On-Premises solution.

The central idea of this architecture is that Harness will install/upgrade and manage the on-premises version of Harness in the customer’s environment. There is an agent running in the customer’s environment whose sole purpose is to manage the on-premises installation of Harness. We call this agent the Harness Ambassador.

The ambassador regularly checks with Harness Cloud if any upgrades are available and then upgrades the downstream On-Premises Harness installation.

The Connected On-Premises installation are available in 2 flavors:

• Docker-based connected on-premises installer
• Kubernetes based connected on-premises installer

The Docker-based connected on-prem installer is for customers who currently do not have a Kubernetes cluster in their environment.

Both the flavors provide High Availability and can be scaled up/down to suit the customer’s requirements.

The rest of this blog will focus more on the Connected Kubernetes-based On-Premises Installer.

Harness Connected Kubernetes On-Premises Architecture

The high-level architecture of Connected-On-Premises Kubernetes Harness architecture is shown as above. The customer has to install the ambassador inside their firewalled DMZ environment. The ambassador is essentially a Harness Delegate whose sole purpose is the manage the customer’s Harness Kubernetes On-Premises installation.

The ambassador is installed on a box in the DMZ which has outbound connectivity to Harness Cloud, from where it can pull updates and artifacts and inbound connectivity to a private Docker repository and the Kubernetes cluster which is provisioned for the Harness microservices. It can be totally blocked from accessing any other internal networks.

Once the artifacts are pushed into the private Docker repository, the ambassador coordinates the Harness installation/upgrade into the Kubernetes cluster in the configured namespace.

This architecture is flexible. It can accommodate subtle variations that may be present for different customer environments. For example, in their K8s cluster/ingress controllers/networking configurations for their load balancers.

Another advantage of this architecture is that no secrets/credentials leave the customer premises. The credentials (e.g. Docker registry credentials) lie on the ambassador box. The ambassador will simply use the credentials to perform the installation/upgrade tasks.

Customer Wins:

The customer gets the best of both the worlds - the speed of Cloud with the comfort of On-Premises:

1. Since the software is installed on-premises, the apparatus can satisfy security requirements such as artifact scannings, monitoring.
2. Customer’s data never leaves the premises.
3. Since Harness is installed on K8s, we get all the benefits that K8s has to offer.
4. Updates can be pushed out as per the customer’s schedule.
5. Customers get the latest and greatest features without any long upgrade cycles which are typical of any enterprise software.

Harness Wins:

1. Installing Harness for a new customer is super easy and super fast. Most installs take less than an hour from start to finish.
2. Harness can push out software updates for customers with a click of a button (This is how you can push updates for your software if you are using Harness. Essentially, Harness on-premises is using Harness to deploy. It is so meta, I know )
3. No longer do we need to maintain older release branches/deal with compatibility issues. This makes our development cycle simpler and we are more efficient with our resources
4. With our unique verification service and 24x7 service guard, we never have a nail-biting release.

Using this architecture, we are currently able to push updates to our customers at an average rate of one update per week and this can be customized as per the customer requirements.

If a customer needs an urgent update for any reason, pushing out the update is as simple as a click of a button.

This architecture is not limited to deploying only Harness. You can leverage Harness using this model to deploy your on-premises enterprise software to your customers.

Ease of software delivery is our mission and we think delivering Harness to our enterprise customer using this model is a testament to the ability of Harness to move fast without breaking.

Cheers!
Rushabh Shah.