\n
![](\"https:\/\/i0.wp.com\/www.rsoftsolution.com\/blog\/wp-content\/plugins\/RSSPoster_PRO\/cache\/76287_gettyimages-163907219.jpg?w=640\")
<\/p>\n
\n<\/p>\n
CoreOS<\/a> introduced a new container management concept today known as Operators<\/a>, which they say will advance the Kubernetes project by offering more automated container management. What\u2019s more, they are open sourcing the technology.<\/p>\n \u201cWe are introducing the concept of an \u2018Operator.\u2019 It\u2019s a concept for taking a lot of the knowledge an engineer [or developer] has inside of a script or run book \u2014 domain-specific knowledge \u2014 and writing software that can do a lot of that automatically,\u201d CoreOS CTO Brandon Philips explained.<\/p>\n Kubernetes<\/a> is Google\u2019s popular open source container management project. Containers are small, micro services <\/a>that enable developers to break down complex applications into discrete pieces and run complex applications in a much more efficient manner than traditional programming delivery techniques.<\/p>\n What CoreOS is attempting to do with Operators\u00a0is not a trivial matter. It involves taking a series of complex tasks and reducing them to a whiteboard view of your project. It\u2019s going to need a cluster made up of 3 servers. This could involve manually locating the\u00a0IP address of each server, creating a\u00a0configuration file and copying\u00a0it to all three machines. It\u2019s the kind of task that takes a lot of developer time and requires manually adjusting when the plan changes. Operators can reduce all of that manual work to a declarative statement: \u201cLaunch three\u00a0clusters<\/em>\u201d and the Operator will handle the rest.<\/p>\n This is particularly important when launching complex applications like databases or monitoring tools. Kubernetes to this point has been great at scaling simpler, stateless applications, Philips explained, but when it comes to more complex stateful applications, it required this heavy scripting to make it work. Operators have the potential to eliminate that layer of complexity.<\/p>\n In fact, in a TechCrunch CrunchNetwork guest post last year, I want to run stateful containers too<\/em><\/a>, Dean Peterson, co-founder of abecorn and a solutions architect for the State of Minnesota at the Department of Employment and Economic Development, lamented his inability to do just that.<\/p>\n At this point, my notion is that stateful applications, such as MongoDB, should run in containers alongside stateless clients and services. I didn\u2019t know that makes me foolish. Like a naive dreamer, I thought the value of containers was to make your entire app easy to scale.<\/p>\n<\/blockquote>\n With today\u2019s announcement Peterson\u2019s naive dream takes its\u00a0first steps toward becoming a reality. It involves launching and open sourcing two Operators. The first is the etcd Operator<\/a> for creating, managing and distributing etcd clusters. etcd is the Kubernetes keystore created by CoreOS. The second is the Prometheus Operator<\/a>, which is designed for use with the open source Prometheus monitoring tool to monitor your Kubernetes resources.<\/p>\n Philips says the company hopes the launch will motivate the community to begin to build others \u2014 and he\u2019s pretty sure they will after they see what these two can do.<\/p>\n \u201cThe Kubernetes community built a lot of this foundation, and we are tying it together for the first time and presenting a vision how domain specific-knowledge can be managed on top of Kubernetes. We have a pattern and we hope people follow it because it\u2019s useful,\u201d he said.<\/p>\n <\/p>\n\n