When all you do is work with Chef, the only logical thing to do is to try automating all the things. I know that I am guilty of trying to use chef in every instance possible. sometimes, to my own detriment. However I will say that for most organizations adding the use of Chef would be a excellent long term investment.
In the short run, it is more difficult to say how it will work. You can always say that everybody has to work with Chef. The short run raises further questions.
- How much are you going to change your workflow?
- Who is supposed to start the process of learning Chef?
- Who will ultimately own the infrastructure as code?
- How will you teach other people to use other components of Chef?
- How will you get the people you have taught to actually use Chef?
These are answers that have to be determined individually for your organization, but there should be a formulaic thought process associated with it. I don't know what that is, but I do have a couple of thoughts.
How much are you going to change your workflow?
If you are doing this correctly a lot, if not completely. After all, you are changing from installer scripts to having all of your infrastructure as code. This means a complete revamp in not only the installation steps, but the way you install and how you make sure it is installed properly. The reality is you will probably find a middle ground for how much you can change. An example of things to have to think about
- Lets only chefify all the code that will be used and can benefit from it. After all, there is no point in creating cookbooks that can't be connected to the network and will only be updated once.
- Lets not include things that are not going to provide monetary benefit. Such as systems that are planning on being phased out in less than a year, peoples pet projects, etc.
- Let's make sure that we have processes in place that will accomodate the changes instead of just flying blind. Gameplans are good.
Who is supposed to start the process of learning Chef?
This is a tough answer to give effectively. There is a lot to determine who adopts it. Things to factor in.
- How big is your IT organization? If it is one, then it's obvious who takes it.
- Who is willing and interested in learning the tool?
- Who is the most capable of actually picking up the information? If the intern or disgruntled senior person wants it so they can have skillsets for the next job, then forget about it.
For us and likely most other organizations, this will be taken over by the operations team in the long run. It would seem in the best interest of everybody to just put it into the hands of those who will use it in the long run. But rather than completely interrrupt the workflow of everybody in the operations department, it should be done by a few people on a crack team.
Who will ultimately own the infrastructure as code aspect of your company?
This is one where it is going to be the operations team in the long run, but it has to be accessible for your entire group. If a certain department is being run under their own chef organization, then they need to own all the code that comes out of that deparment. There should be an implementation team for production at all times that owns the main responsibility of teaching everybody.
How will you teach other people to use the components of Chef?
I don't have a solid answer on this one, but I do have a couple of thoughts.
- Chef is not the easiest thing to start learning, so it's not something that can be learned overnight by other people
- Trying to learn advanced components of chef requires tailoring your knowledge of and teaching specific examples, so it is not the easiest to learn advanced concepts.
The only solution that would seem to make sense in this scenario would be to make it a small operation. Take highly trained computer commandos to teach a small team at a time the ropes of Chef, and in that way make it small batch sizes of imparting knowledge. After that, you now have two small teams of replicating their knowledge sharing across the board.
How will you get the people you have taught to actually use Chef?
We all know that the new years habits of humans. They say they are going to eat right, exercise, and quit all vices. They try to change too much and end up going back to the same way they are doing things. Following this logic, it would make sense to increase the positive feedback loop and allow for improvements
- Don't try to take on too much at once. Keep it small in how many peoples workflows you are going to change.
- Give them positive reinforcement that it will work for them. Have your crack commando team show a working example.
- let them know that it was hard. After all if it was easy, everybody would be doing it already. Give them that understanding.
- Have a management push that this is going to be an end goal. We are typically quarterly driven, and management needs to understand that if they abandon it to meet a quarterly deadline, then they are giving up before really seeing the benefit.
- Allow for "cheat days" Every good diet allows for a couple of cheat meals to reward a person who is pushing to get better. Don't be afraid to allow such things. Allow for the use of manual steps if need be. Allow for a sometimes implementation of non-idempotent scripts in the recipe. it's okay, as long as you stick with the plan and replace it eventually. this also allows you not to get stuck on points that really don't matter.