Sessions

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.)

I also liked his takedown of the “Infrastructure as Code” buzzphrase: the accurate term really should be “Infrastructure from Code.” The difference isn’t just semantic; it’s time IT people get used to the idea that if they still want jobs down the road, they have to start thinking of themselves as infrastructure service developers. (Jones made the fascinating point that an IfromC approach basically eliminates the “second-level IT engineer” – the guy who messes around in GUIs when a problem is escalated from help desk – leaving only basic user support and a small group of highly-skilled people who write the infrastructure automation.)

Jones also reiterated a point from his e-book that I’ve observed in practice at my own workplace: if you claim to want a DevOps culture, you have to be willing to actually put Dev and Ops people together on projects and let them work out their differences. Retaining traditional silos and putting a “DevOps team”as a mediator in between mutually opposed groups is missing the whole point of what DevOps is supposed to accomplish: “Dev and Ops working together to shorten the path between coder and consumer.”

Session Grade: A

10 AM (Richard Siddaway): DevOps, Powershell and Windows Containers

This two-hour session was spent on a general overview to the new Windows/Hyper-V containers that will be available in Windows Server 2016. This is a new topic to just about everybody, including me, so I learned a lot, but rather than try to summarize Windows containers at a high level I will point you to Mark Russinovich’s excellent article from last fall. (Seriously, stop reading this blog and go read that. It’s essential.)

OK, I’m assuming you’ve read that and are now back. This was a packed session with a ton of questions (“How do I join these containers to an AD domain? Do files in a shared folder get saved into a container image?”). Here’s a couple observations that struck me as especially useful:

The containers are only available on Nano/Server Core 2016 right now, but should be available on Windows 10 soon, meaning that developers can use them locally and ship them onto production servers.

Potential scary thing: every container OS image must be EXACTLY the same version as the host image. This will make patching a bit tricky.

There are a ton of new container cmdlets in Powershell 5. This technology will either be a breeze to automate or a horrifying blizzard of poorly-documented, overlapping functionality. Here’s hoping for the former!

Interestingly, to manage a Windows container remotely in Powershell, Siddaway had to do the equivalent of a double hop: creating first a remote session on the container host, then another one in the container itself. I saw it happen in front of my eyes with no authentication issues, but I feel like this is the sort of thing that would take awhile to get right in a new environment.

Session Grade: B+ (the second hour devolved into a live demo that rambled a bit)

Building unconventional SQL Server stuff with Powershell was basically my job description for about eighteen months, so naturally I was intrigued by the title of this session. The fact that it was taught by Mike F. Robbins, who may know more about SQL Server + Powershell than anyone alive, didn’t hurt my expectations.

The session was organized as a funnel of SQL Server/Powershell approaches from “most to least conventional”; starting with the good old SQLPS module, Robbins moved on through SQL providers and direct SMO objects, then custom .NET Framework implementations and beyond. You can check out all his code here; I think it’s worth a look.

Of course, the specific techniques demonstrated in the session are trivial compared to the essential question: Why manage SQL Server in Powershell at all? Isn’t regular T-SQL good enough? The answer, as Robbins reminded us, is that it depends on what you are trying to do. If you would like to use the results of your SQL queries in another system, such as ActiveDirectory, Powershell is your friend. If you need to programmatically generate huge chunks of dynamic SQL, Powershell can be a great choice. Working with multiple SQL Servers is easy in Powershell: no linked servers needed, just query one server with a cmdlet and pipe the output to another.

Also, props to Robbins for including a bunch of resources (including QR codes on the powerpoint) for further reading at the end of his talk. I wish every speaker did that.

This was a good session – Murawksi works for Chef and speaks with a lot of authority about DevOps-y practices. The material was intentionally basic, especially if you have worked in this type of environment before, but I still took away some good thoughts and reminders. However, my brain is kind of melting at this point in the week, so rather than try to create coherent paragraphs I’m just going to provide some random highlights underneath the essential DevOps topics that Murawski hit.

Source Control

“The number one indicator of a high-performing IT ops team is whether they use source control.”

Functional (Test larger pieces of code; can have side effects; a bit of a gray area between unit tests and integration tests)

Integration or Acceptance (Black box testing: test the system like an end user)

Centralized Logging

Required logs must not be only on the box. I personally use SumoLogic as a log aggregator, but there are plenty of other solutions out there – including, apparently, Microsoft’s up-and-coming OMS.

Service Monitoring

What does it mean for a service to be healthy? (In the cloud, it shouldn’t have to mean that every individual node is online.) IT organizations need to be proactive about solving the monitoring problem for their specific infrastructures.

Like Robbins, Murawski finished his session with a recommended reading list – awesome! Even better, it’s on his website.

Session Grade: A

Final Thoughts

Overall, I’m really glad I attended this year’s Summit. I think the quality of presentations was higher across the board than last year, and honestly the quality of attendees, both in terms of skill level and outspokenness, was better too. I have a bunch of new thoughts and techniques to take home and chew on! Maybe next year I’ll even try to get on the speaker list.

I hope these recaps were helpful, especially if you didn’t get a chance to go to Seattle this year. Please hit me up on Twitter @forrestbrazeal if I can answer any questions.