First, I don't think anyone notices or cares when I post specifically, so it's hard to really feel like my "general opinion" is well-known enough to not talk about it anymore. I'm no Joel Spolsky over here!

Second, I feel like it's valid to point out that Operators are not really just a method of "packaging", in a post that tries to make it sound like Operators are just a small bit of YAML or metadata. You're writing real, non-trivial Go code that tells Kubernetes explicitly how to deploy and manage the lifecycles of specific types of applications.

At least until now with the "Operator Framework", there wasn't really even anything that firmly defined an Operator as an Operator; it's just what some people called their Go code that manipulated k8s's object handling and lifecycle internals.

But, if you insist, here's one operator I've worked with: https://github.com/coreos/prometheus-operator . This is from CoreOS itself.

Here's a patch I submitted about a year ago: https://github.com/coreos/prometheus-operator/pull/289 . This required updating the way the software handled HTTP response codes in one of its "watcher" daemons (because all packaging methods need those, right?), and fixing the order of operations in the bootstrap scripts.

Some more general info about this repo:

    $ du -sh prometheus-operator/.git
        51M     prometheus-operator/.git

The repo size is 51M.

    $ git rev-list --count master
        1716

There have been almost 2000 commits.

    $ cloc --vcs=git --exclude-dir vendor,example,contrib .
         290 text files.
         278 unique files.
         121 files ignored.
    
    github.com/AlDanial/cloc v 1.74  T=0.82 s (295.4 files/s, 48117.2 lines/s)
    -------------------------------------------------------------------------------
    Language                     files          blank        comment           code
    -------------------------------------------------------------------------------
    Go                              50           1581           1392          20622
    JSON                             9              0              0           6276
    YAML                           132            260            885           4164
    Markdown                        30            792              0           2957
    Bourne Shell                    17             65             58            257
    make                             1             34              2             91
    Python                           1             10              5             40
    TOML                             1             11             20             30
    Dockerfile                       2              8              0             27
    -------------------------------------------------------------------------------
    SUM:                           243           2761           2362          34464
    -------------------------------------------------------------------------------

It appears there are over 20k lines of Go code after excluding vendor libraries and the example and contrib directories (arguably, contrib should've been included).

I dunno, it just feels a little disingenuous, to me, to say that something that involves this much code is just a "packaging method" for a normal application. "Sure, just write an operator to package that up" like it's comparable to a package.json manifest or something. It's not! You need custom daemons that watch files to make sure that your k8s deployment stays in sync, and then you need to exert very meticulous and specific control over Kubernetes' behavior to make things work well.

I think it's demonstrative that it takes north of 20k lines of Go code to package an application for deployment on Kubernetes. What do you think?

-------------

EDIT: And one clarification: my opinion on containers as such is probably not well-known, since you're conflating it with my opinion on Kubernetes.

I like containers conceptually (who wouldn't?) and I run several of them through LXC:

    NAME               STATE   AUTOSTART GROUPS IPV4            IPV6 UNPRIVILEGED 
    axxxx-dev          STOPPED 0         -      -               -    false        
    gentoo-encoder     STOPPED 0         -      -               -    false        
    jeff-arch-base-lxc STOPPED 0         -      -               -    false        
    jeff-crypto        RUNNING 0         -      xxx.xxx.xx.xxx  -    false        
    jeff-ffmpeg        STOPPED 0         -      -               -    false        
    jeff-netsec        STOPPED 0         -      -               -    false        
    jeff-ocr           STOPPED 0         -      -               -    false        
    localtorrents-lxc  RUNNING 0         -      xxx.xxx.xx.xxx  -    false        
    nim-dev            STOPPED 0         -      -               -    false        
    plex-2018          RUNNING 1         -      xxx.xxx.xxx.xxx -    true         
    unifi              STOPPED 0         -      -               -    true    

I believe this is the kind of thing people actually want. Highly efficient, thin "VMs" that are easy to manage and run as independent systems without requiring the resource commitment.

There is a good place for Kubernetes in probably about 1% of deployments where it's used. Most other people are just trying to run something like LXC, but they're confused because everyone who is critical of k8s drops to -4 and gets HN's mods after them. :)