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.

By Rushabh Shah
March 5, 2019

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-Prem 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-prem installer
  • Kubernetes based connected on-prem 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.

More details of our Docker-based Connected On-Prem setup is available here.

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

Harness Connected K8s On Premise architecture

The high-level architecture of Connected-On-Prem K8s 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 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 to accommodate subtle variations that may be present for different customer environments for their K8s cluster/ingress controllers/networking configurations for their load balancers etc.

Another advantage of this architecture is that no secrets/credentials leave the customer premises. The credentials for eg. the docker registry credentials, the Kubernetes service account 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 24×7 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 1 update per week and this can be customized as per the customer requirements.

Deploying Harness-On-Prem using Harness Cloud

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 allows us to onboard and support new customers without linearly increasing the size of our Customer Success team.

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.

➞ Back to Blog

Leave a Reply

avatar
  Subscribe  
Notify of