OperatorCon

When and Why Build Operators

In order to meet the increasing requirements of running more analytical jobs to get more insights into organisations data and reap benefits from it it makes more sense to move my Bigdata pipeline to cloud as it meets requirements of building and deploy analytical jobs within seconds with simplified user experience, scalability, and reliability. But Its a huge challenge for Cloud providers to meet all expectations like meetings standards of 99.9999 availability, reduced operations. Kubernetes and related technologies have been really helpful to bring down operations and failure rates but adopting Kubernetes is not only the Mantra which help you achieve all your goals but how you design your components on top of it also mater. One of such component which has been very helpful is Kubernetes operators. The purpose of this talk is to discuss what are scenarios where it make sense to create an Operator.

Build Your Operator With the Right Tool

You want to build a Kubernetes Operator for your software. Which tool to choose? Operator SDK with Helm, Ansible, or Go? Or maybe start from scratch with Python, Java, or any other programming language? And what is the right phase in the Operator Capability/Maturity Model that you should provide?

In my talk I’ll present:

• Different ways of building Kubernetes Operators
• Demo of building the same Operator using different tools
• Methods used by the most popular Operators (Couchbase, Prometheus, MongoDB)
• Operator Capability Model and how it affects your toolkit
• Our journey with Hazelcast Operator

Using an Operator With a Well-Known Java Application Server

I am already for more than 20 years now in the area of Java EE. Since a few years I also got interested in newer technologies and try to see what impact it has on traditional architectures. For various customers I designed their current applications into a cloud ready and modernized landscape think of all the aspects of containerization, microservices, serverless and so on

Containerization of a traditional Java EE Application Server such as WebLogic needs a mind-shift of how applications should be developed an how existing environments can be transformed to a managed Kubernetes Docker platform.

To manage a traditional style platform as a WebLogic Application Server requires managing it with “knowledge from the field” and thats why Oracle developed an operator specialized for installing, configuring and operating a WebLogic Server in a Kubernetes Cluster, such as:

• Simpler WebLogic management in Kubernetes
• Kubernetes resources are allocated for WebLogic domain(s)
• Manages overall WebLogic environment through Kubernetes APIs
  • Load Balancer, Network,
  • Ingress Controllers,
  • Security,
  • HA restart, upgrade, scaling
  • Persistent storage
• Ensurance all best practices are followed

The session will tell you all you need to setup an operator such as these, from a commercial product to what it is now , an OpenSource initiative developed and maintained.

3 Years of Running Operators in Production – A Reflection

In 2016, we were driven by the idea to find a generic way to run Kubernetes clusters everywhere. So far so good….but how exactly? Could it make sense to run Kubernetes in Kubernetes? Well, let’s give it a try. This is how we started to build our first Kubernetes Operator to manage Kubernetes in Kubernetes in a scalable way. Early 2017, we first went into production with about a dozen of clusters on AWS. Meanwhile, we manage hundreds of clusters across large-scale multi-cloud deployments. More than three years after the start of this exciting journey, we look back on what we have learned and show how we plan to extend the operator paradigm to the edge.