-
Notifications
You must be signed in to change notification settings - Fork 18
Refresh What landing page for Kubecon #35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refresh What landing page for Kubecon #35
Conversation
Clean up technical marketing before Kubecon
Clarify the content after viewing the Netlify preview.
| <h2 class="of-heading of-heading--md">What is an Operator after all?</h2> | ||
| <p>An Operator represents human operational knowledge in software, to reliably manage an application. They are methods of packaging, deploying, and managing a Kubernetes application.</p> | ||
| <p>The goal of an Operator is to put operational knowledge into software. Previously this knowledge only resided in the minds of administrators, various combinations of shell scripts or automation software like Ansible. It was outside of your Kubernetes cluster and hard to integrate. With Operators, CoreOS changed that.</p> | ||
| <p>Operators implement and automate common Day-1 (installation, configuration, etc) and Day-2 (re-configuration, update, backup, failover, restore, etc.) activities in a piece of software running inside your Kubernetes cluster, by integrating natively with Kubernetes concepts and APIs. We call this a Kubernetes-native application. With Operators you can stop treating an application as a collection of primitives like Pods, Deployments, Services or ConfigMaps, but instead as a single object that only exposes the knobs that make sense for the application.</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what I like about the old/existing text here is:
- it better categorizes the activities between day1 and day2, so it's clear that Operator is more than getting things up and running but also covering the operational aspects for day 2
- I prefer "exposes the knobs" better than "ports" since "knobs" conveys the idea of "easy configurable options" better (and "port" could be misunderstood as a socket/port or endpoint, etc).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the feedback. This was a very aggressive edit on the first pass. I will add back the information on Day 1 and Day 2 Operations, though I will try to break it up into a couple of shorter sentences.
| <section class="of-section--largetext"> | ||
| <div class="of-section--largetext__item"> | ||
| <h2 class="of-heading of-heading--xl">Who's building Operators?</h2> | ||
| <p class="of-section--largetext__content">Cluster Admins, Site Reliability Engineers, Software Engineers, and DevOps Engineers encapsulate their shared knowledge into an operator, offering a resilient and robust solution that manages an application in a native Kubernetes way available everywhere OLM is installed.</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(it could be just me) I like the existing single sentence better being more concise and more natural on "available everywhere OLM is installed" than making it a standalone sentence. (but I'm open to other opinions too)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noted. Let me try to rework it a little so I can keep the conversational style of the original intact, and keep it punchy and straightforward.
Clean up technical marketing before Kubecon