Will JavaScript type annotations kill TypeScript?
The creators of Svelte and Turbo 8 both dropped TS recently saying that "it's not worth it".
Yes: If JavaScript gets type annotations then there's no reason for TypeScript to exist.
No: TypeScript remains the best language for structuring large enterprise applications.
TBD: The existing user base and its corpensource owner means that TypeScript isn’t likely to reach EOL without a putting up a fight.
I hope they both die. I mean, if you really need strong types in the browser then you could leverage WASM and use a real programming language.
I don’t know and I don’t care.
Cloud Native Ecosystem / Kubernetes / Open Source

Cloud Native Computing Foundation Takes Charge of Red Hat’s Operator Framework

Red Hat's Operator Framework has joined the Cloud Native Computing Foundation (CNCF) at the incubation level
Jul 13th, 2020 12:22pm by
Featued image for: Cloud Native Computing Foundation Takes Charge of Red Hat’s Operator Framework

Red Hat’s Operator Framework has joined the Cloud Native Computing Foundation (CNCF) at the incubation level, skipping over the sandbox, just as Contour did earlier last week. The project, originally created by CoreOS before the company was acquired by Red Hat in 2018, is an open source toolkit for managing Kubernetes native applications, called Operators, in an automated and scalable way.

“The benefits for being recognized as part of the CNCF landscape are really getting the podium and getting the space to continue to develop this framework, in collaboration with all the other projects and all the other folks that are part of the CNCF ecosystem,” said Diane Mueller, Operator Framework maintainer and director of community development at Red Hat. “One of the main benefits of the CNCF is the nurturing of these projects, plus the dialogue that we can have with other CNCF projects. It is really going to expand the universe for Operator Framework, and we’re really pleased.”

Rob Szumski, a product manager with Red Hat and Operator Framework maintainer, explained that Operator Framework explained the project’s origins.

“CoreOS was very interested in running things that weren’t stateless applications, pushing the boundaries of Kubernetes and starting to get to the third wave of applications; not just stateless, not just stateful, but these things that need a high degree of coordination and most likely, embedded application knowledge and operational knowledge,” said Szumski. “We didn’t want to stop there. We wanted every workload to be expressed this way, and so we had to build up a set of tools to help you do that. That’s where the operator framework was born.”

Operator Framework is made up of two main components: the Operator SDK and Operator Lifecycle Manager (OLM), both of which can operate independently of the other.

The Operator SDK provides high-level APIs and scaffolding to more easily build, test, and validate operators, using the controller-runtime library to make writing operators easier. The OLM provides a declarative way to install, manage, and upgrade Operators and their dependencies in a cluster, as well as the ability to discover, install, and automatically update Operators from “catalogs.” Catalogs are a packaging format in OLM that allows Operators to express dependencies on the platform and other Operators. In addition to these catalogs, OLM further offers Operator discoverability and cluster stability, preventing conflicting Operators from owning the same APIs.

In discussing Operators, both Mueller and Szumski stressed the ‘day two’ aspect of Operators, which can take them beyond the mere install capabilities that might be offered by something such as Helm. With the combination of the Operator SDK and the OLM, they said that Operator Framework can add operational knowledge into software, and pointed to a chart of Operator capability levels in example.

Another key feature Szumski focused on was that of testing, which he said requires a different way of thinking about things from standard applications.

“This is kind of a different style of programming because you’re constantly talking to a Kubernetes cluster whose state is constantly changing. As you know, pods come and go, things are getting scattered around, pods are starting in milliseconds, and this piece of software is reacting to that in order to take remediations. If an important part of the application goes down, for example, it can bring it back up. This SDK helps you both develop that and then test it. As you can imagine, with the very dynamic environment of the Kubernetes cluster, you want to make sure that these things are going to work really well. And so we’ve got some testing tools built into that to help you,” said Szumski.

On that front, he said that the team was working toward a new integration of the KUbernetes Test TooL (KUTTL), which provides a declarative approach to testing Kubernetes Operators.

As for the future of the Operator Hub, that is going to remain separate from Operator Framework and will not be donated to the CNCF at this time.

The Cloud Native Computing Foundation is a sponsor of The New Stack.

Feature image by Gerry Carley from Pixabay.

At this time, The New Stack does not allow comments directly on this website. We invite all readers who wish to discuss a story to visit us on Twitter or Facebook. We also welcome your news tips and feedback via email:

Group Created with Sketch.
TNS owner Insight Partners is an investor in: The New Stack.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.