Product
|
Cloud costs
|
released
March 5, 2019
|
3
min read
|

Harness uses Kubernetes for On-Premises Deployment

Updated

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.

Kubernetes On-Premises Diagram

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.

Harness Kubernetes On-Premises Upgrade Steps


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.

Deploying On-Premises 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 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.

Sign up now

Sign up for our free plan, start building and deploying with Harness, take your software delivery to the next level.

Get a demo

Sign up for a free 14 day trial and take your software development to the next level

Documentation

Learn intelligent software delivery at your own pace. Step-by-step tutorials, videos, and reference docs to help you deliver customer happiness.

Case studies

Learn intelligent software delivery at your own pace. Step-by-step tutorials, videos, and reference docs to help you deliver customer happiness.

We want to hear from you

Enjoyed reading this blog post or have questions or feedback?
Share your thoughts by creating a new topic in the Harness community forum.

Sign up for our monthly newsletter

Subscribe to our newsletter to receive the latest Harness content in your inbox every month.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Continuous Delivery & GitOps