Why you shouldn't build a Kubernetes Operator
2019-11-16, 12:00–12:30, The Gallery

Since its origins at CoreOS and flowering at Red Hat, the Operator pattern has seen lots of explication and promotion -- rightly so. It's a pattern for extending Kubernetes, built from key Kubernetes components and concepts. But it's not right for every application in every case. This talk will help developers make informed choices about when they do, and when they don't, need to extend Kubernetes to get the features their app needs.

Kubernetes scales and manages stateless applications quite easily. Stateful applications are trickier. Databases, caching systems, and file stores must be dynamically managed with data intact, and often come with their own notion of clustering. Operators are Kubernetes agents that know how to deploy, scale, manage, backup, and even upgrade complex, stateful applications. But not every stateful case needs an Operator; from ConfigMaps to StatefulSets, core Kubernetes abstractions overlap with lower-level Operator functionality, and sometimes an application-specific Operator isn't the right choice. This talk will compare and contrast the Operator pattern with native abstractions to help you know why you shouldn't (or should) build a Kubernetes Operator.