ISSUE 227: Red Hat Operators

“By moving from a ‘forecasting’ to a ‘scenario planning’ mindset, it is possible to determine no-regret moves that enable action with confidence today, while building out the playbooks to give you a head start on shifts required for the future as it unfolds.”

The Kubernetes era has made scaled-out applications on multiple cloud environments a reality, but it has also introduced a tremendous amount of complexity into IT departments.

The guest on this episode of The New Stack Makers podcast is Andreas Grabner from software intelligence platform Dynatrace, who recently noted that “in the enterprise Kubernetes environments I’ve seen, there are billions of interdependencies to account for.” Yes, billions.

Red Hat Operators

Is the operator model too closely aligned to Red Hat? 

This is a question that has been swirling around "cloud native Twitter" as of late. We’ve covered the operator model since it was first conceived by CoreOS back in 2016. It made sense to offer something to ease the deployment and management of complex applications on Kubernetes. When Red Hat acquired CoreOS in 2018, if there was any doubt that the technology would get lost in the shuffle, those fears were quickly squashed as Red Hat soon made the operators a fundamental cornerstone in its Kubernetes and OpenShift strategy. 

One person not happy with operators, or at least Red Hat’s implementation of it, is Darren Shepherd, chief technology officer and co-founder of Rancher (which itself is in the news as Rancher is being acquired by SUSE). The operators concept itself is fine, serving as an introduction for developers to the Kubernetes controller, he said on Twitter. 

But the Red Hat Operator Framework, and the associated Operator Lifecycle Manager [OLM] and Operator Hub, are too closely aligned with Red Hat’s preferred cloud native architecture, muddying the whole concept of operators he argued. 

Rancher itself has declined to use operators, given what Shepherd sees as weaknesses in the model, but now the company is getting criticism for not “supporting” them. That’s a relatively small issue, he admitted.  

“The bigger issue with OLM/Hub is just that the model doesn't make sense to me for an enterprise to adopt. Operators is just a small set of k8s components that need to be managed. Why does an operator need a specific path to be managed? Why can't I just manage operators using a consistent approach for all k8s components. OLM/Hub is creating a weird fracture in how you manage k8s. The concept is just not useful in the bigger context.”

What do you think? Is the Red Hat Operator implementation muddying the waters, a redundancy when we already have Helm? We’ll be covering this issue in more detail in the weeks to come, so let us know at editorial@thenewstack.io.

Best Practices for Deploying Jaeger on Kubernetes in Production

According to the recent DevOps Pulse report, Jaeger is used by over 30% of those practicing distributed tracing. Many companies realize the need for distributed tracing to gain better observability into their systems and troubleshoot performance issues, especially when dealing with elaborate microservices architectures. In this contributed post, Logz.io developer advocate Dotan Horovits walks us through the process of setting up Jaeger in production settings.

Snyk Seeks to Sharpen Distinction Between Low-Priority and Urgent Security Alerts

DevOps teams often continue to struggle with the balancing act between security tools that are either too tight or too lax. Opting for overly sensitive security monitoring tools typically results in a deluge of alerts and false positives. On the other hand, a security tool that is supposedly designed to highlight only those alerts that deserve immediate attention all too often bury important vulnerabilities and even word of potential breaches. Now, security company Snyk wants to make better distinctions across potential vulnerabilities, with “instant prioritization” and “deep application context” capabilities on its security platform.

This Week in Programming: Linux Kernel Keepers Mull In-Tree Support for Rust

Last week saw a Linux kernel developer, Nick Desaulniers, suggesting that Linux should offer in-tree support for the Rust programming language, in effect allowing developers to write extensions to Linux using not just C, but Rust as well. We’ve covered before how Rust is a safer language than C — the idea has been floating around for a while, but now it appears to have the approval of Linus Torvalds, who in an email response, didn’t trash the idea of using Rust, but worried about having the necessary tooling at the compiler.