Patrick Debois ran the Config Management Camp panel "Next Steps in Configuration Management", featuring Luke Kanies, Puppet author and Puppet Labs CEO, John Keiser, development lead at Chef, Thomas Hatch, Salt author and Salt Stack founder, and Mark Phillips, director of business development at Ansible.
Patrick: If you could go back in time what would you change to fix a mistake you made?
John: I would change it so the people in the movement would need to be more distributed between developers and operations.
Thomas: The fact that, if we can not change something externally, how do we model those systems to be applicable to the correct audiences. I look back and, when writing Salt, we were much more focused around probably the sysadmin perspective. Now that I see what has happened, I am increasingly convinced that what we should have done, and what we are trying to do, what we are doing now, is more on the lines of creating tools which are dynamic enough to fulfill the needs of a wide audience so that we can facilitate the communication between groups that generally do not communicate well.
Despite everything we have said and done "bla bla bla DevOps" IT people and developers still seem to hate each other just as much if not even more than ever. Really, it is more along the lines of how to build tools that actually give them a bridge between those two worlds, how to build tools so that a developer can create and manage things in a development mindset and hand them over to an IT person and the IT person is not going to vomit all over. And I think that is quite a challenge.
Mark: I would not change things from the past but I would learn from them. I would say, just learn from those things, not change them, but make things today open and flexible enough so that tomorrow we can cater for something we did not foresee.
Patrick: How do you think immutable infrastructure, containers or micro services are changing the future of config management? or do they take you all the way around?
Mark: It is a bit of a chicken and egg. I remember in the mid 90s I would build things and thrown them away. We have the same thing today, we build things that we throw away instead of fixing, instead of look out for something and nurture it. In config management we may have grown a little bit, but we are still doing these things.
Patrick: Is a good thing to try to build everything around config management, like orchestration? do we have to separate it in different parts into the future?
Thomas: When we start looking into configuration management it is very easy to say, this is the extent by which you are doing things right in configuration management, but at the same time it is very easy to impose logical limitations on top of it. One of my prime philosophies is that we can not see the future, that the best way to think about the future is to build as flexible, as modular systems as we can. That is why, if you are familiar with Salt, it is ridiculously modular.
Patrick: That could be seen as premature optimization.
Thomas: That could be premature optimization. Now, the reality is that everything is changing at such a rapid pace. It all comes into, some people may come back and argue, is it just image management vs configuration management playing out the classic switch over the past many many years? or are they really going into something new? The main thing I wanted to say about the diversity of the toolset, is that there are a lot of people preaching the idea that, if you do it certain way, you just ignore certain aspects of the infrastructure. Or that they say, these are disposable. But, they might not ever be disposed. And simply changing the level of abstraction of the application it sits on, does not inherently solve the management problem and it creates complexities that need to be addressed again within their own scope.
John: I agree that there are definitely some techniques that ignore some of the complexity of the underlying systems. Sometimes it is actually useful and it is easier to convert the problem into a nail that you can hammer. If you have a hammer everything looks like a nail, and sometimes that is ok, and makes it easier. It is not going for everybody, some people are going to need screws, and I do not think that is going to change.
When I hear people talk about the future of config management, I am confused about what they mean, because it is not putting files and packages and services in a machine. Configuration management serves two purposes. First, it exists to describe the stuff that you have, in a common language that everybody can understand. It does not mean that it has to go all the way deep to describe every configuration setting, but things like your accounts, the services that you have,... Secondly, it is a way to make easier to configure things that are a pain in the ass. Sometimes we use configuration management as a way to configure the applications that should be doing a better job themselves. That can go away as applications get better but you are always going to need the way to describe what you have.
Luke: If there is one thing I would change, is that every config tool is writing their tools from scratch, with a totally new stack. In some cases there are good excuses, like I did not like the runtime, I want to use Python instead of Ruby, and in some cases I do not know what the excuses are. Why do we need to compete with all the parts of the stack at the same time? I would collaborate with other tools to built lower parts of the stack, we are not going to make big leaps unless we find a way to collaborate.
I do not believe in gigantic steps forward. The hardest thing is to get people to use it. You can do the biggest technological leap in the world and nobody use it, and it is not because you are stupid or they are, it is because new stuff is fundamentally hard, the world just does not change like that. The changes we have to do in the community, we have to transition from files and packages and nodes into applications. From static state to dynamic. It is not going to happen like that, but it is the trend that, if you ask us, all of us will say more dynamic, less static. More application oriented.
Patrick: Is there any trend in the IT environment that would put some pressure in configuration management? anything that would change the trend of config management or rethink it? something like the Internet of Things
John: The desire for speeding the environment, the speed at which companies fail is terrifying to the people at the top, even the biggest companies in the world realize that they can fail very quickly now and that is because of technology. A lot of products just fall into a big hole if the technology is not working, the technology need to get really fast, developers need to make awesome stuff very quickly, and has to be stable when it is deployed, it means that DevOps really has to work. The primary pusher is to make things easy enough for me and ops to actually build the software they need really, really, really quickly.
Luke: Our technology in general works on powerful systems. We are really slow and require a lot of expertise. Everything in the world, every piece of software requires management, and none of us are building software that can be used to manage the software that run in tractors or things like that. It is not putting pressure on us, it is just passing us by. It is not showing pressure, it is showing irrelevance, which is sad.
Patrick: With a lot of things becoming services, are we still running config management ourselves? or move to services externally? We used to have the full control but now it is out in the open, how do you handle that?
Thomas: The problem we are into, is one that Luke nicely highlighted, everything that we have developed is standing on the shoulders of those who came before of us. One of the problems we are into, somewhat inherit to open source and the way the industry works, is that we are compelled to create fundamentally competing components. If I can make a quick comment about the Internet of Things, I am very excited to be involved in IoT applications. There are a number of things that we were involved with, we are used to manage large deployments of weather monitoring devices in South Africa, and I think configuration management needs to be constructed in such a way that it is sufficiently flexible to be able to handle these things. But I do think that is exceptionally difficult for us to do, given that we can not see the future.
Patrick: Docker was a leap for me, I have never seen some technology irrupt so fast.
Mark: I disagree, everything in life is circular. Fashion, food, tastes, technology,... Everything happens again and again and again. Docker is built on things learned in the past: FreeBSD jails, Solaris zones, containers,... You do not know what is going to happen in the end, you do the best you can to keep flexibility. We are trying to have the flexibility to get to a future we can not yet see.
Thomas: Docker is a fantastic piece of technology, but it is an evolutionary technology.
Luke: Imagine Docker happening in 2000, nobody would notice. Docker could have only came out after VMware spent 15 years virtualizing the world. VMware spent billions of dollars convincing you about virtualization, and now everybody is like wow!, everybody has this perspective so now we can begin to move faster. The fact that VMware did not invent Docker is VMware problem. Timing is incredibly important, every technology moving as fast as Docker moves has to be evolutionary, because if it was not, it could not move as quickly.
John: This topic, evolutionary vs revolutionary, it does not seem super useful honestly. There are going to be huge leaps in technology that people will have to catch up and there are going to be huge leaps in the way people's jobs change, how are they developing and deploying software, how they work together, and technology will have to catch up. I think there are sudden leaps happening all the time, and we still have gaps that we have to cross, some of them with leaps. We still failed at DevOps, honestly, we got a lot better, we made really great tools to deploy things rapidly and repeatedly, but we tried to make dev and ops work together and they still think that the other guy is kind of useless, mostly.
Patrick: What do you think about using more and more external services?
John: In terms of services, you are still building services. You are seeing things like throwing away machines, and it is a reflection of the things we do not want to care about, which is everything except for our applications. What is going to have to change is that operations and developers act together, developers have to be surrounded by infrastructure while they are developing and operations need to have input into how the infrastructure is deployed while development happens. But you are still building applications.
Luke: I think the whole SaaS thing is a misnomer. The point is not that the number of servers I have is going down. In Puppet Labs we use Box, HipChat, Salesforce,... we have fewer servers today, fewer applications inside our firewall because we pay other people to have more applications inside their firewalls. They also use Puppet, they also have servers. Yes, those servers tend to be more dynamic, more focused. It is a shift, it is not a removal. It used to be that every sysadmin had to be competent about backups, mail servers, CRM software,.. Now, because you use SaaS companies, you do not need to worry about all those things because you pay other people to take care of them, you get to focus on things you care about most and pay other people to also focus on things they care about most. Nobody reduces the number of servers that matter to you, the servers are not going away, they have more now than ever, you are much more specialized, much more focused, and that is great because we can move faster than in the past.
About the Panelists
Patrick Debois is and Independent IT-consultant, bridging the gap between projects and operations by using Agile techniques both in development,project management and system administration.
Luke Kanies is Puppet author and Puppet Labs CEO. Luke founded Puppet and Puppet Labs in 2005 with the goal of producing better operations tools and changing how we manage systems.
John Keiser is development lead at Chef.
Thomas Hatch is the creator and principal architect of SaltStack. Tom’s knowledge and hands-on experience with dozens of new and old infrastructure management technologies helped to established the vision for Salt. For his work on Salt, in 2012 Tom received the Black Duck “Rookie of the Year” award and was named to the GitHub Octoverse list in both 2012 and 2013 for leading a project with the highest number of unique contributors, rubbing shoulders with projects from Android, Mozilla and OpenStack.
Mark Phillips works for Ansible Inc, based out of London, UK. With over 20 years experience of infrastructure engineering, Mark has built automated environments at every level - from a handful of hosts for startups, to the tens of thousands in Investment Banks.
