This is the third and final installment of my daily notes from the 2016 Powershell and DevOps Global Summit. Day 1 wrap-up is here, and Day 2 is here.
9 AM (Don Jones): What DevOps Really Looks Like
Don Jones is an effortlessly entertaining speaker who’s not afraid to eviscerate ideas he finds stupid, sort of like (and I mean this in the best possible way) the Donald Trump of Windows IT. He is also a man who thinks clearly about DevOps, a subject usually buried in fuzziness and hype. (I highly recommend his short e-book on DevOps from an ops perspective.) In this session, he gave a typically animated fireside chat about what a DevOps culture really is: an embrace of the idea – foreign to many ITIL shops – that failure is inevitable and change is good. (He brought down the house with a line about ITIL being IT governance borrowed from the DMV.)
Continue reading “Notes from the Summit: Day 3 Summary”
The Global Powershell and DevOps Summit strikes you as the sort of conference run by people who have spent a fair share of their professional lives attending terribly-organized technical conferences and swearing to themselves that one day, ONE day they would create an event that lived up to their own expectations. They have certainly exceeded mine. As Don Jones said at one point, 90% of this success comes from choosing the right venue. The Meydenbauer Center is centrally located to Bellevue’s hotels and food, the staff is highly organized, and the catered food is extraordinary. The fact that the event is relatively small, not a 20,000-person cattle call, also really helps, as does the fact that there are no third-party vendors trying to sell you stuff. I would recommend this event to anyone who thinks that technical conferences have to be thinly-disguised, poorly-executed sales pitches. It’s just a good experience.
Continue reading “Notes from the Summit: Day 1 Summary”
BELLEVUE, Wa – Ed “The Scripting Guy” Wilson and Joe Levy from Microsoft’s Operations Management Suite (OMS) team presented the current state of their product today as part of the 2016 Global Powershell and DevOps Summit. I was not familiar with OMS before today, but the use case it’s trying to fill is a huge pain point in cloud ops: how do you sanely do configuration management across multiple system types, in multiple locations?
From what I understand, OMS is basically a giant job scheduler in the cloud. You install their agent on your servers (doesn’t matter where the servers are – Azure, AWS, on premise, whatever -as long as your networking rules are sufficiently permissive) and set up configuration scripts to run at scheduled times on different categories of systems. This being the new Microsoft and all, the target machines can be Linux as well as Windows. The OMS service has some nice notification capabilities (it will send you an email if it enforces a configuration change on a server) and also integrates with Powershell’s Desired State Configuration (DSC). (Yep – it’s Powershell as a Service. What a world we live in.)
I liked most of what I saw, though I did have a couple concerns. Microsoft may heart Linux now, but Powershell/Powershell Workflows are still the only runbook types allowed on OMS, so if you really want to manage Linux servers this way, you’re going to be using some clunky third-party SSH workarounds. I asked if support for other scripting languages like Bash or Python would be added soon, but there are apparently no plans for this. The source control integration for the scheduling scripts also seems a little weak; it’s apparently Github-only right now, but I would want to play with this before making a judgment one way or the other.
In short, I think OMS already seems like an awesome configuration management choice for people managing big Windows ecosystems, but the product still has a little way to go before people in hybrid or Linux-only environments are likely to get on board.
Today’s guest post is by Greg Bell. View the full Configuration Management Week schedule here.
Greetings! I’m Greg Bell, a Cloud Automation Developer at the Greenville, SC office of Infor, a software company specializing in Enterprise Solutions. I speak Data Center, Systems Engineering and Virtual Technology. IT is a passion but I @iGeektoLive.
Intro to SaltStack
SaltStack was developed by Thomas Hatch, CTO and co-founder. Tom is one of the most active contributors in the open-source community. I had the good fortune of having lunch with him and several members of his development team on the last day of SaltConf15 in Salt Lake City Utah earlier this year. He clearly has a passion for making the best software available to manage computers of almost any kind. You may have heard of one of SaltStack’s earliest customers: LinkedIn. They have thousands of servers all managed by SaltStack.
Continue reading “Configuration Management Week: SaltStack”
Today’s guest post is by Jon Carl. View the full Configuration Management Week schedule here.
Jon Carl enjoys the outdoors, running, and anything tech, specifically software engineering. In his spare time, Jon is building a new social network, Segment. At the time of this article he is employed by Frontline Technologies where he works as a Junior Software Engineer. Follow him on Twitter @grounded042.
Intro to DSC
PowerShell Desired State Configuration, hereafter referred to as DSC, is a configuration data deployment and management feature in Windows PowerShell. DSC allows one to declare a wide range of configuration options and variables through PowerShell syntax, and apply those configurations to one or many machines with the push of a button. Configurations are made to be re-runable, and can thus be used as a configuration integrity tool by re-applying the configurations as needed. To put it simply, DSC allows the desired state of a configuration to be declared and applied.
Continue reading “Configuration Management Week: DSC”
Today’s guest post is by Luke Seelenbinder. View the full Configuration Management Week schedule here.
Hi! I’m Luke. I write code and design architecture for Spensa Technologies, a precision
agriculture company in West Lafayette, Indiana.
Intro to Ansible
The Ansible Team developed Ansible to meet five design principles: 1) simply clear, 2) simply fast, 3) simply powerful, 4) simply efficient, 5) simply secure.
Those five principles were a result of a common frustration. If a developer writes a deployment script, moves on to other projects, and then returns to it in six months to add a new deployment directive, the complexity of many tools easily make the task impossible. Michael DeHaan wanted to avoid this. (Paraphrases taken from http://www.ansible.com/about.)
Continue reading “Configuration Management Week: Ansible”
Something big is happening
Despite the ever-changing buzzwords, there’s really not much new under the sun in the IT world. After all, today’s cloud-centric environment is not so different from the mainframe/dumb terminal setups of the 1980s. GUI-based management fades in and out of fashion (here’s hoping it stays out this time!). All else being equal, the best way to predict the future of IT is to reimagine the past, just with more smartphones.
But the DevOps trend of recent years has given rise to at least one IT management tool that doesn’t seem to have a clear precursor. Forget quiet installs and lite-touch deployments; we now have a means of automating system state at massive scale, using declarative files that live in a twilight zone between code and configuration. Yeah, I’m talking about configuration management tools – Chef, Puppet and all the rest. And as far as I know, this is that rare IT breakthrough that’s pretty much unprecedented.
Continue reading “Configuration Management Week”