by Corey Quinn | Senior Technical Consultant at Taos
This past week, I had the honor of being invited to speak at SaltConf 2015. I additionally was asked to serve on a panel that discussed using multiple configuration management systems in the same environment.
The panel got me thinking about what DevOps in 2015 means (from a technical sense; the cultural shifts and methodologies will have to wait for another blog post someday!). I believe I’ve narrowed it down to four primitives, which I term the Four Horsemen of DevOps. Since I was at SaltConf, I was naturally thinking in terms of Saltstack. It struck me that each one of these four primitives is served rather well by various Saltstack components.
1. Configuration Management
It’s well understood that configuration management is no longer optional. You need a way to ensure consistency between machines; this is where the “Pets vs Cattle” trope comes in. You want your systems to all look identical; if one exhibits a problem, you want to be able to knock it down and replace it with a pristine version. This has become no less central a concept in the wake of the “Cloud” revolution, that sees an uptick in the use of ephemeral instances in various providers, both hosted and on-premises.
This is the aspect of “spinning up new environments.” When you need to spark up another 50 servers, doing this by hand is… sub-optimal. Worse, if it’s a manual process, the potential for error creeps in. There were some very impressive demos of Salt-Cloud being used to instantiate instances in AWS, Google Compute, and Openstack this past week.
3. Remote Execution / Orchestration
Salt started life as a remote execution bus. In fact, as I mentioned both in my talk and my panel, I feel it’s a grave mistake to classify Salt as a configuration management solution at all– rather, I see Configuration Management as an application offered atop of the Salt platform. This informs the concept of orchestration– when an event happens on one node, it can fire an event; Salt’s reactor subsystem can catch that event and signal an action on another node. This is a giant step in the direction of self-aware clusters.
4. Service Discovery
This is an emerging field, historically dominated by the likes of Zookeeper, etcd, and Consul. However, Salt has begun to make some steps in this direction with the introduction of the Salt Mine– ways for minions to publish small bits of data to the master. While this is still rudimentary, it opens the door for future expansion. Picture a scenario in which you spin up a new web server, and it publishes that it offers a web service. From there, the load balancer sees this publication, and automatically adds it to the load balanced web pool. While simplistic, this example hints of things yet to come.
As I stated in the panel discussion, I feel like calling Salt a “Configuration Management Solution” is a red herring. While it introduced a new system in terms that people were already familiar with, the true power of Saltstack’s platform goes far further than merely making sure that all of your systems look alike. Or, as I put it into a microphone, “Salt was a visionary product far ahead of its time. In fact, I’d hazard that Saltstack was the answer to a question that nobody was asking. And now four years later, people are starting to ask it.”