From The Enterprisers Project: 4 Facts about Kubernetes Operators

The Enterprisers Project ran a story last week that delves into some of the lesser known qualities of Kubernetes Operators. Read the whole thing here. From the article:

3. Kubernetes Operators aren’t just for databases

A (very) brief history of Kubernetes Operators goes something like this: In its early days, Kubernetes was considered a great fit for managing stateless applications. For stateful applications like databases, not so much – at least not without significant operational burden. Operators to the rescue.

(Again, that’s the CliffsNotes version.)

So Operators in their early days were often focused on database applications and helping to extend Kubernetes’ capabilities to this critical category. Bromhead from Instaclustr led the development of an Operator for Apache Cassandra, for example.

“Back when Kubernetes Operators started, people would create Operators mostly for managing stateful database workloads,” says Yossi Jana, DevOps team leader at AllCloud. “Some of the examples were MongoDB, Cassandra, and Redis. Those databases are more difficult to set up and continuously manage on your own without the proper expertise.”

So, yes, if you scan the OperatorHub.io registry, you’ll see plenty of database-related Operators. But Operators aren’t for databases alone.