SaltStack, a pluggable messaging and automation framework for large server farms, have just made some more announcements around their partnership with SuSE.

Confusion and comfort factors

“Chef, Puppet, Salt and Ansible” are DevOps tools available to engineers who are planning, managing or operating big server environments. My frustration with this (and probably for the vendors too) is that these tools are not really comparable. It’s like saying “a horse, skateboard, plane and banana boat” are all forms of transport. Yes, if you can use all 4 to get from one point to another, but probably with varying comfort and speed. I would love to see someone charge into battle on a banana boat. Teams decide they want to “do DevOps” but because they have no experience they don’t really know how to assess one tool over another, then down the line those ill-made decisions become architectural debt.

Chaaaaarge!

You can use each of these tools to achieve similar goals like configuration management, eventing, automation and auto-remediation but the approaches they take are vastly different. One of the key differences is the way that the master server communicates with the devices you’re managing. At small scale this doesn’t really matter, but when you get into the 1000’s, it makes a huge difference.

A characteristic I’ve noticed is that many engineers ‘discover’ DevOps whilst learning these tools. As a consequence they all have a very loyal fanbase, many engineers whom have had their lives impacted by being able to automate with ease some task or issue that used to plague their lives. You really don’t get such levels of passion for monitoring, CMDB tooling as you do with DevOps. The problem with this is that it’s hard to distinguish between whether a tool is popular because it’s the one engineers tried first or because it is genuinely the best option.

I urge everyone to try out every option in the DevOps space and come to your own conclusions, because the ideal solution is likely going to be more than 1 tool. SaltStack can certainly do a lot, which can be overwhelming for beginners but once you get over the learning curve you understand how powerful it is. The biggest mistake people make is to learn it by comparing it with Chef, if you’ve been paying attention, then you hopefully won’t do that!

What makes Salt unique?

If you pay super-close attention to the way users talk about “building on Salt” instead of “managed by Salt” or “configured by Salt”.

At this years SaltConf in Utah there were a lot of talks on configuration management patterns, I managed to avoid all of them because I find the subject very dull and it’s not my job (thankfully!) to worry about those problems. There were however, some brilliant tracks showing what people had built on the Salt platform. It’s really important when assessing Salt to understand what it can do and whether you could develop on it’s platform now or in the future.

At the core of Salt are 2 things- a secure, reliable messaging framework (built on ZeroMQ) and a module loader. Everything in Salt is a module, everything is abstract-able.

The next layer down are abstract sub-systems built on the module loader and messaging framework like the state manager, the reactor (for responding to events), beacons (for emitting events) and some newer ones. These sub-systems are essentially a set of interfaces and example implementations, you can plug in your own module anywhere in Salt. You can even replace out the messaging protocol with your own implementation.

The place I would love to see Salt evolve into in the future is breaking it’s pigeon-hole of configuration management and evolve into a platform demonstrated by companies to build their systems management on, build their automation frameworks on or build their new micro-services platform on.

I’ve recently witnessed a design for a micro-services platform, where the architects have been building the messaging layer, the business logic and systems to respond to messages, emit alerts and respond to system failures. All this was built into Salt.

Salt already has all of the components to built upon, it just needed some implementations to show what it was really capable of.

Software defined datacenter

SuSE, the company current known best as the owners of the Linux distros SuSE Enterprise Linux (aka “Slez”) and OpenSuSE have just announced a progression of their partnership with SaltStack to build SuSE manager 3 on Salt.

I was a big user of SuSE before they forked into the Enterprise and OpenSource distros. At college I used to hike over to the out-of-town computer store to buy a boxed edition of SuSE every time they released a major update. Mainly because it came with some fantastically written manuals, but secondly because it had the stability of Debian/BSD but with the modern package management and systems tools that RedHat had.

One of the best features was YaST, their configuration management tool. It still kills me to fiddle with text files on the odd RedHat server when it was so easy on YaST. That heritage has carried nicely into their modern systems management tools, they are simple to use, well thought through and built for Enterprise scale environments.

What does this mean for Salt?

Salt is Apache 2 licensed, unlike some of their competitors, which means more software vendors can start building on Salt, creating amazing management tools (not just configuration management!), and most importantly — pick their own commercial strategy! SuSE have decided on a per-system enterprise license with support, which makes total sense for them and their clients. I’m glad they were the first ones to take the step and show what Salt can do,

I can’t wait to see where this goes in 2017.