Why you shouldn't build an operator! http://bit.ly/cn_reject

CNrejects.html

<section data-markdown>
  ## Why You Shouldn't
  # Build an Operator! 
  
http://bit.ly/cn_reject

</section>  
<section data-markdown>
# WHAT?
 * custom resource definitions
   * spec vs status (custom controller logic)

</section><section data-markdown>

"kubernetes, go left, go right"

vs

"kubernetes, take me home!"

</section><section data-markdown>

# WHY NOT?

 * security
 * consistency

 * no need for a custom control interface?
 * no need to extend the cluster?

 * namespacing, adv cluster proliferation...

</section><section data-markdown>

# WHY?

 * security
 * consistency
 * community (shared support via TSANet)
 * updates (updates via OLM)

 * sourcing a distribution full of services from CNCF landscape, available on any K8s via operatorhub.io

</section><section data-markdown>
### Productivity

Productivity requires:
 * reproducibility (service availability)
 * observability (logs, metrics, traces)
 * using the right tool for the job

</section><section data-markdown>
### Productivity

Production-like environments provide the best reproducibility, observability

1. Kubernetes provides a reproducible platform for cloud-native solutions
2. OpenShift provides a PaaS-like environment whith active management for cloud-native solutions (with maintainers, patch streams)
3. Portable app code from the neck up

</section><section data-markdown>
## OperatorHub

OperatorHub.io
</section>
<section data-markdown>

## OperatorSDK

learn.openshift.com/operatorframework

</section>
<section data-markdown>

### Ways to get started with the OperatorSDK:

* go
* ansible
* helm charts

</section>