After spending last week at the IT Dev Connections conference, I thought I should share some insight.This was the first time I attended the conference, and I must admit it was a nice substitute for Microsoft Ignite which I was not able to attend. Key take away from the sessions and content presented is:
- Automation and integration – do more work with less effort
- Hybrid cloud is here to stay
- Azure is removing dependencies (System Center) ASR
- OnPrem presence is still substantial
- Containers – Docker and Docker for Windows
- IT Dev Connections – A great conference
IT Dev Connections
First off, this was held in a great place (Las Vegas). The venue (Aria) was perfect with nice auditoriums (not to big) and very good internet connection (Aruba rules). By my estimates, there were around 1500 participants (I do not have an exact figure). Compared to Ignite, which is around 20.000, it is more personal than those big conferences. They also managed to mix the agenda with a nice blend of Cloud/Azure/VMWare, Office365 and pure developer content.
They also created a smartphone app where you could build your own schedule and give your feedback to the sessions you attended! They even included a map of the conference area. I loved the app!!
My only complaint was that sessions I wanted to attend was scheduled to run at the same time, which is inevitable for such a conference. Only way to prevent this is to repeat sessions which I understand can be a challenge. Anyway all the sessions was recorded and can be watched online if you bought the premium (executive insight) package.
Automation and Integration
Powershell and Azure Automation
In full disclosure, I like Powershell and the things you can do with it, however it is my unbiased and objective opinion that you learn and/or ramp up your skills on tools/things like:
- Powershell and Azure Automation
- Source control (GitHub, BitBucket or Visual Studio Online (VSO))
- JSON
- Windows Powershell Desired State Configuration (DSC)
- Unit Testing/Test-Driven-Developmen(TDD)
- Any Cloud consumption (Azure, AWS, Google, Rackspace etc)
Some person I spoke to (sorry I do not remember his name) was amazed that almost every session he attended spoke of Powershell and integration with some product/cloud service. I think that is a perfect summary of where we are going.
When Microsoft released Windows10 they included the preview of production ready and supported content in Windows Management Framework 5 (WMF5). It includes a whopping list of 70-ish modules for your pleasure only. Also worth noting is that they included the Powershell Pester Unit Test module which is a module created by the community. Version 5 of the Management Framework is still in preview and is expected to reach production with the release of Windows Server 2016 later this year or early next year.
The day before the conference started, Microsoft announced that Azure Automation now supports Pure/Native Powershell. I feel for the speakers at the conference because even if this has been an announced feature, the exact time was not known and they had to change their presentations in the last minute to be up to speed. Kudos to the speakers to be able to implement the changes (Trevor Sullivan, David O’Brien and Aleksandar Nikolić and other people too).
Native Powershell support in Azure Automation is a small but very important step to enable the world to embrace automation in the cloud. Combine that with the fact that it supports on-prem workernodes (or runbook/powershell runspace hosts if you like) and you have a nice package that should make you able to receive a nice ROI on you current Powershell skills and not worry about the annoyances in Powershell workflows. Further Azure Automation now supports source control like GitHub, which should make you feel warm and fuzzy.
Unit testing
 |
| Test-Driven-Deveopment process |
Yep, it is coming to the IT-Pros as well. Traditionally this has been something the software developers has cherished or ignored depending on their company policy and personal preference. As I mentioned above, Microsoft now includes a Unit Test framework for Powershell in their supported version of Windows10. Needless to say that this module also is present in Windows Server 2016. This begs the question: Why?
Apparently, Microsoft thinks that you should Unit Test your Powershell script. If your Powershell script makes changes to your production infrastructure, it makes perfect sense. Just saying, “I have tested this, it works”, just does not cut it any more. Prove it with Unit Tests and you confirmed your statement. Which person would you hire to do some Powershell work for you that would affect your production platform? A guy that says it works or the guy with the unit tests that proves that it works?
Who is JSON?
JSON is a way of representing data structure in a way that is easy to consume (my definition not the official one). It became a standard in javascript and has almost completely replaced XML in asynchronous browser/server communication. It is also the data format the Azure Resource Manager (ARM) understands and consumes in its quest to provide you with cloud resources.
The cloud community has created a nice “Quick starter JSON templates” repository for you on GitHub. In there you will find ready-made templates that will configure the cloud resource for you. They are also a great starting point if you want to create your own templates to spin up or scale resources you will have running on Azure.
(Powershell can convert TO/from JSON)
Source control – Why should you use repositories
Source control tracks changes made to files/content, tags the change with the person who made it and commits it to the active branch (Master/Development/whatever) of your repository. I have been using source control for my Powershell scripts since 2012 and it has saved my bacon a couple of times. It is a perfect match for agile and quickly changing environments that gives you control of the source and at the same time documents changes that have been made.The screenshot above is from Atlassian’s SourceTree application that runs on Windows and Mac. GitHub has an application that is called GitHub. You can use both to connect to BitBucket or GitHub repositories.
The most popular Source Control systems out there and those that I have used is:
- BitBucket
- GitHub
- Visual Studio Online(VSO)
They have slightly different pricing strategies, so use the one that fits your needs. Bitbucket has up to 5 users for free and GitHub is free if you only use public available repositories.
Writing scripts, JSON-template files or Unit Tests is like writing a program. The process is very similar. You have a “Development/Test” branch that is your work in progress and a “Production/Master” branch that is production quality code/content that should run or is running in your environment. As your work progress, things flow from one branch to another, like it should, however remember:
“Before you move a feature/Fix/Patch from “Development” branch and into “Master” you make sure that the Unit Test are up to date to reflect the changes and that they pass.”
This is where it all comes together and you might understand why Microsoft have a Unit Test module for your pleasure in their OS. It just makes perfect sense in a DevOps world to prevent unwanted downtime and a quick way of identifying the changes that broke your production system or application.
Windows Powershell Desired State Configuration (DSC)
Linux has been doing configuration management for years with software like Chef and Puppet. People think that DSC is a Powershell feature, however it is a Windows feature first implemented in Powershell. It is built upon WSMAN, CIM, OMI (WMI for Linux). DSC now also supports Linux and Chef has integrated their management tools to support DSC on Windows. Currently there is over 100 DSC resources that you can use to build your infrastructure and make it idempotent and scalable. You can even create your own DSC resources using Powershell scripts or c# code if you prefer.
There is currently a handful of Resources built into Windows10, however the majority of the resources created by the Powershell team are marked experimental and sadly not supported by Microsoft, yet. Sometime in the future this will change, nevertheless I dare not to speculate on when those will be officially supported by Microsoft. That said, I know Stack-exchange (the website) current rely on DSC for their production infrastructure. So what is your excuse for not implementing this in your dev/test/staging area if not production?
There are a number of repositories on GitHub that contains resources for DSC. Microsoft’s repository for experimental DSC resources is here (not officially supported by Microsoft):
https://github.com/PowerShell/DscResources
PowershellOrg also has a repro on GitHub with their community resources. There you will find some nice features created by Steven Murawski who was the lead architect when StackExchange implemented DSC in their production environment:
https://github.com/PowerShellOrg
Why should software companies/vendors care about DSC?
They should care about DSC the same way they care about their customers consuming/buying their software. I cannot remember how many times in the past I spent more time collecting all dependency software for a particular system, than installing the software it self. Not to mention the time consuming process of configuring software after in has been installed and making sure it does not change unless you want it to.
Would it not be better if you provided a Desired State Configuration for your system that collected all dependencies, scaled the system to the customers needs and presented a configuration for the base setup of the system? Makes perfect sense to me. I realize that it is a big investment for anyone wanting to provide this for their customers, however think about the competitive edge you will build in the market. I would be very surprised if you did not receive a good ROI after making the right decision.
A fair warning if you plan to embark on the DSC journey. Currently the documentation on teched regarding DSC is to put it mildly lacking. I am confident that this also will change and receive a massive update thanks to the constant request and references to the missing elements by my friend Trevor Sullivan (you should follow him on twitter @pcgeek86).
My automation insight
If you have a cloud strategy and/or a hybrid cloud strategy, you are doing it wrong if automation and integration is not a key element of your implementation strategy. The cloud is built to scale and and is designed to be easily automated. That is why it has several APIs for you to work with (REST, Pyton, Ruby, .Net and of course Powershell).
If you want to create a successful career or business going forward, you need the skills/tools I mentioned above. Like with any huge shifts in technology, you will have early adaptors, mainstream adaptors and late adaptors. A competitive edge and/or success is usually not created by the contenders in the latter category.
In part 2 we will jump into Hybrid Cloud, talk about the missing link (see my previous blog entries about the subject) and take a deep dive into MAS (AzureStack). Is it still missing? Stay tuned!
Cheers
Tore
Thank you
ReplyDelete