The Operator Pattern: domain knowledge distilled.
The concepts of resources and objects as well as controllers and reconciliation loops should now sound somewhat familiar. We recall that we can plug custom resources and controllers into a cluster.
We probably do not yet see how useful and less of a niche use-case than initially thought this actually is. These last few years, however, had seen the emergence and wide-spread adoption of a design pattern now commonly referred to as the "operator pattern".
An "operator" is technically a set of CRDs and controllers, bundled with the promise of adding operational functionality to a Kubernetes cluster, pretty much turning conventional workloads into managed services.
That promise is made on the grounds of such custom controllers often being imbued with advanced business logic inside to go with and targeting their well-defined set of custom resources, and delivered on by a number of technical tasks carried out autonomously by the system.
The selling point is that these are well capable of implementing things we only need to describe on a higher level, letting the system bear the brunt of the maintenance overhead, lifecycle management included. They can deploy, configure, take backups of or even upgrade an application. That means that such a software product may embody - and, to a certain extent, substitute - hands-on experience and precious operational knowledge stemming from that. You will definitely need to know your way around a product managed by an operator, but most chores shall be dealt with on your behalf. Operators usually have to do with running multiple, individually configured instances of stateful applications but vary in complexity as do the use-cases they cover, ranging from relational databases via software-defined storage to cloud platforms. Some of them are commercial products in their own right.
To give you an idea: imagine having an "ApplicationCluster" resource ready to use. Imagine deploying such an application cluster by way of instantiating an object like you would with any other resource. Imagine this to also include regular off-site backups, automatically taken. Then imagine upgrading that application via simply changing a value of a key (e.g. spec.appVersion) to a higher number. (Following an upgrade path supported by both product and operator in question, of course.) Imagine this API-driven, tightly integrated automation as part of a commercial product offering. Now think of its implications, business impact and consider its worth to your organization or customers.
The above train of thought hadn't been meant to convince you of anything, rather to emphasize the importance of automation based on first-hand experience and shed light on one practical and well-founded manner of its application.
Not everything lends itself to this purpose, though, as feasibility is always to be factored in, but such considerations remain outside the scope of this article. An official, open-source SDK supporting multiple approaches exists to foster development. You will probably not need to start your own projects straight away as a steadily growing selection of operators is readily available from a number of freely accessible sources (for example here), but do bear in mind their maturity and feature parity - overall quality, so to speak - will most certainly also vary. As with any software, rigorous testing remains paramount.
As cheap a bottom line as this may seem: bad automation is actually worse than having none at all. That said, proper automation always was, is and will remain a gamechanger in any field of industry.
Brace yourselves, content is coming.
