Introducing Harness Continuous Delivery for Microsoft .NET and Azure

Harness extends its Continuous Delivery platform for both traditional .NET applications (IIS) and Cloud-Native Microservices (Azure & .NET Core).

By Steve Burton
November 15, 2018

It’s just over a year since Harness came out of stealth. In that time, we’ve created multi-cloud support for our Continuous Delivery platform across AWS, GCP, PCF, Kubernetes, and OpenShift.

Today is the final major piece of that puzzle with comprehensive support for Microsoft .NET technologies and the Microsoft Azure Cloud. We’ve already seen early .NET customers like iHerb migrate to the cloud using Harness and Kubernetes.

Support For Traditional and Cloud-Native .NET

One thing we noticed from speaking with .NET customers is that microservices and public cloud adoption are still very much in their infancy. The majority of customers we’ve spoken to only have a handful of .NET core applications running in AWS or Azure.

As a result, most customers have requested Harness support for traditional on-premises IIS applications as well as their cloud-native microservices apps. Just like Harness supports traditional Java apps like Tomcat & JBoss, we also now support your “vintage” .NET applications:

dotnet_artifacts

This level of support is very valuable for large enterprises that have a big mix of .NET/Java applications in addition to the new cloud-native applications that encompass Docker, Kubernetes and Serverless technologies (which Harness also supports).

Linux, Windows, On-Premises, AWS, Azure, GCP or Whatever

With your .NET services/artifacts now supported out-of-the-box, we further extended our .NET infrastructure, compute and container orchestration support to:

  • Amazon Web Services (EC2, EKS)
  • Microsoft Azure (AKS)
  • Google Cloud Platform (GKE)
  • RedHat OpenShift
  • On-Premises Data Center (Direct Kubernetes, SSH for Linux, WinRM for Windows Servers/Hosts)

For example, in just a few minutes you can create a new environment in Harness. Simply pick your artifact, deployment type, and a cloud provider account (E.g. Azure below) and Harness will dynamically pull and reference all your cloud provider compute configuration:

env_dotnet

Harness is a true multi-cloud Continuous Delivery platform, so it doesn’t matter if one service is .NET core running in Azure AKS or an IIS service running in AWS EC2 or your own data center. You can model (and deploy to) hybrid clouds in minutes with Harness.

Getting Ship Done With Harness

If you’re familiar with the Harness platform, then it’s business as usual for deploying .NET applications.

Harness has 5 core concepts that construct a typical deployment pipeline:

  1. Services – the artifacts you wish to deploy (e.g. Container, IIS Website)
  2. Environments – the infrastructure mapping for a given service (e.g. Dev, QA, Prod)
  3. Workflows – deploy one or more services to a given environment (e.g. IIS Website-Canary-Prod)
  4. Pipelines – stitch together workflows as stages across your various environments
  5. Triggers – execute pipelines based on a condition (e.g. new version of artifact)

For example, below we have created a new IIS Website Service called todolist-app whose artifact source is linked to an AWS S3 bucket. Harness also supports Azure Container Registry (ACR), Google Container Registry (GCR), Docker Hub, and JFrog Artifactory.

service_dotnet

Harness has automatically generated all of the standard deployment scripts (Download artifacts, Expand artifacts, Create AppPool, Create Website) required to deploy this artifact.

If required, you can edit these default Powershell scripts or simply import your own via the Harness template library.

After defining your services, you then need to create workflows that will deploy those service(s) to a given environment. For example, you can create a canary deployment that deploys your .NET service in phases to the target environment or users.

When your .NET deployment workflows and pipelines execute, you can watch/debug step by step them using our real-time analytics:

dotnet_workflow

 

GitOps & Configuration-as-Code

Harness also offers comprehensive GitOps capabilities via a YAML API and Git integration for building and version controlling deployment pipelines. You can either build/manage everything through the Harness UI or drive everything as code via your applications source code repository.

Here’s a quick screenshot of what Harness configuration-as-code looks like for a .NET application:

yaml_dotnet

 

Auto-Verify Deployments With Continuous Verification

In addition to automating the deployment of .NET services, Harness can also automate the verification and health checks of .NET services once they’re deployed. We call this process Continuous Verification, and it integrates with all your existing application performance monitoring (APM) and log analytics tools to automatically identify performance or quality regressions using unsupervised machine learning.

Bottom line: Harness will tell you the business impact of all .NET deployments, and if need be, will automatically roll back the application to the last working version should it detect performance (e.g. response time) anomalies or quality (error/exception) regressions.

Here’s a quick preview of what Continuous Verification for performance looks like with AppDynamics:

We also support New Relic, Dynatrace, Datadog, Prometheus and custom time-series data for performance verification.

From a quality perspective, our verification can also detect quality regressions by flagging new errors/exceptions (red dots below) that were introduced to the .NET service post deployments.

Here’s a preview of what this support looks like for Splunk:

Users can click on any red dot and immediately see the stack trace of what caused the regression.

We also support Sumo Logic, Elastic, Logz.io and Scaylr for quality verification.

Signup For Your Free Harness Trial

Sign up here for your free trial of Harness.

Cheers,

Steve

@BurtonSays

 

➞ Back to Blog

Leave a Reply

avatar
  Subscribe  
Notify of