Last night, our partners The Scale Factory hosted a roundtable discussion on the subject of DevOps on Windows. As a co-author of the Continuous Delivery with Windows and .Net book, this event was right up my street. The discussions were under Chatham House Rule and as such no attributions will be made in this post.
The Scale Factory have hosted similar events in the past but they’ve primarily focused on DevOps in a Linux world. The feeling in the room was that DevOps is only just beginning to make waves in the world of Windows and discussions like this help us to share tips, stories and strategies as we bring the culture change to a new set of people.
What’s the Windows equivalent for Configuration Management?
The first question of the evening was asking for parallels in Configuration Management tooling between Linux and Windows. Puppet, Chef and Powershell DSC were all suggested. The room agreed that it heavily depended on what skillsets were already in place. If there’s already use of Powershell for scripting then DSC is worth looking into, although the learning curve is pretty steep. One person said that they tend to teach Puppet at places just beginning to learn about CM. They feel Puppet is the simplest for SysAdmin with no CM experience to pick up and get started with.
Separate tools or Jenkins for everything?
In the Linux world there is a tendency to use Jenkins for everything – build, test, deploy, orchestration, etc. Is this the same story in the Windows world? No-one said they were using Jenkins, but they many were using separate tools for CI and deployment. TeamCity or VSTS for CI and CodeDeploy or OctopusDeploy for deployment. A couple of people were using GoCD to manage everything. The room felt that separate tools were a better approach as they tended to have strengths in certain areas.
Bake vs build?
Baking Windows images is time consuming. An instance must be booted up, have applications and updates installed and then shut down. Even automated with Packer this process can take 30 – 50 minutes per build. As a trade off for these upfront costs, it can save a lot of time at machine startup, particularly if making heavy use of autoscaling. If your fleet is relatively stable, a more generic base image could be used and the application is installed on at deploy time. As mentioned above, many people in this situation are using an agent based deployment method such as OctopusDeploy or CodeDeploy or Puppet to send updates to the machines.
Say No to DevOps Teams
Team structure was also an interesting topic. The room agreed that a DevOps team misses the point of the cultural changes that DevOps entails. Some attendees had seen SysAdmin teams rebranded as DevOps teams as a low investment business effort to join the current trends. This gives the impressions that that particular team “does all the DevOps and all the other teams don’t”. This article from Steve Smith goes into more details between DevOps as a Cult and DevOps as a Philosophy.
DevopsTopologies.com covers various team structure options including the pros, cons and impact of each configuration. We are also hosting a one-day workshop on Team Topologies in Manchester on 24th May, where Matthew will take you through the design process for effective team structures.
Soundbytes from the night
“Containers are not yet ready for Production. There needs to be more questions and answers on StackOverflow”
“AWS Data Migration Service is f*ing painful”
“AWS EC2 Automation is slow and messy”
“Microsoft are more open. They are improving”
Retelling a time this was said by a Finance person to developer: “I see you’ve just spun up an instance in AWS. Did you get you a PO for that?”