Extending GitOps to Hybrid IT with Second Generation RPA

Cloud native computing is a new paradigm for enterprise IT that takes the cloud's core elasticity and scalability benefits and extends them to the entire IT landscape.

At the core of this new paradigm is the declarative representation of the IT environment that represents an abstraction between the operations (Ops) team members and other users who manage and run applications and the underlying infrastructure that supports those applications.

At the heart of the cloud native movement is Kubernetes, an open-source container orchestration platform that provides rapid elasticity and massive horizontal scalability for software running as microservices in containers.

Ops personnel control Kubernetes itself via a declarative abstraction layer, which is predictably cloud native in its architecture. However, there is no requirement that cloud native infrastructure leverage Kubernetes or containers and microservices in general.

Many of today’s cloud native deployments include traditional VMs and serverless functions as well as containers, extending declarative control over infrastructure beyond Kubernetes.

As a result, there are two contrasting interpretations of the term ‘cloud native’ in everyday use – the narrower, Kubernetes-specific sense and the broader, hybrid IT-centric approach.

The conflict between these two interpretations is particularly stark within conversations about GitOps, a rapidly maturing set of best practices for implementing continuous deployment (CD) for cloud native applications.

While GitOps applies to the broader sense of cloud native in theory, it has grown to be Kubernetes-specific in practice. As a result, extending GitOps to application deployments across all of IT is becoming an increasingly important challenge.

The Challenge of GitOps

At the core of GitOps is the open-source source code management tool, Git. When implementing GitOps, the deployment team should place all declarative representations of the desired infrastructure configuration on the production environment into the Git repository.

Furthermore, there should be an automated process for ensuring that the production environment matches the state that the representations in the repository describe. As a result, if a team member wishes to deploy a new application or update an existing one, all they must do is update the Git repository, and built-in automation takes care of the rest of the deployment.

The most popular approach to implementing such automation follows the pull-based deployment strategy. Pull-based deployments depend upon an operator, which is a Kubernetes-specific software agent that continually compares the state in the repository with the actual state in production.

If there are differences between the two (what we call ‘drift’), then the operator automatically updates the infrastructure to match the information in the repository.

Much of the innovation in the GitOps space today centers on these operators. There are numerous active GitOps operator projects and commercial products, including ArgoCD, Flux by Weaveworks, Jenkins X, and Helm Operator. 

The challenge with all of these products is that they are Kubernetes-specific. The underlying operator architecture is part of the Kubernetes specification.

GitOps, however, is not supposed to be Kubernetes-specific. GitOps specifies the declarative representation of infrastructure configuration and the processes that Git supports. How, then, should organizations extend GitOps to the broader hybrid IT-centric notion of cloud native computing?

How Gen2 RPA Solves the Problem

Extending the powerful functionality of the Kubernetes GitOps operator beyond Kubernetes to the whole of the hybrid IT landscape is a Herculean task. 

For each piece of application infrastructure an enterprise has in production, there needs to be a software agent or ‘bot’ that can discern its particular configuration, compare that configuration to a specified one in a repository, update the configuration in production to match the specification, and then monitor it to ensure it remains in conformance.

Furthermore, the deployment team must be able to manage the bot following GitOps best practices by managing and versioning it with Git. The fact that I called this operator-like software agent a ‘bot’ gives away the answer. Robotic process automation (RPA) should be able to handle this admittedly difficult automation task. 

Traditional Gen1 RPA vendors primarily automate interactions with user interfaces for applications that don’t support other forms of automation. Unfortunately, these solutions are not particularly well-suited for building GitOps bots that work like Kubernetes operators, as they focus on user interface automation and are also brittle, thus requiring ongoing maintenance.

Second-generation or ‘Gen2 RPA’ is a different story. Open-source vendor Robocorp has pioneered this Gen2 approach to building bots in Python, a popular language for creating automations - giving developers complete control over bots, including the ability to manage and version them with Git.

Perhaps most importantly, Gen2 RPA doesn’t focus on user interface interactions. Instead, bot creators can automate any interaction with any piece of software in the hybrid IT landscape.

The Intellyx Take

Given the variety and diversity of software in today’s enterprises, creating bots that can automate GitOps isn’t an easy task - and vendor who says they can provide such automation out of the box is likely overselling their product.

Gen2 RPA avoids this pitfall, though. Robocorp provides a straightforward approach for building task automations that is both developer and GitOps-friendly. Of course, someone still has to do the work, but with Robocorp, it’s possible to extend the benefits of GitOps to large swaths of the hybrid IT landscape.

Copyright © Intellyx LLC. Robocorp is an Intellyx customer. None of the other vendors or projects mentioned in this article is an Intellyx customer. Intellyx retains final editorial control of this article.