This is rare, me blogging. I always feel that someone else can always explain it better than me.
In the past few weeks, I have spoken to people about the importance of understanding and starting to work with containers. Containers as they relate to Docker, Hyper-V 2016 and so on.
Creating PowerShell Workflows is something that is becoming much easier for people now that the new version of the Microsoft Azure Portal has been out (Beginning of May 2o15 timeframe). The ability to graphically create workflows was done very well.
Also, creating PowerShell Sessions mainly used with JEA is getting a lot of traction. JEA helps secure and trim down the needs for access to all of the resources in your environment.
Assuming you are following the trail, Containers, Workflows, Sessions you should be able to see where I am headed. Lets look at workflows first.
In System Center Orchestrator / SMA (Service Management Automation) / Azure Automation you have the perfect opportunity to use container technologies! All of these are stale scripts, functions, compiled code that is waiting to be deployed and executed. The way I see it, Azure Automation is just an interface to Docker that is a container itself. When your workflow draft is merged to your source, the code gets compiled to a new container. Once you are ready to run the workflow, the container gets deployed. Sounds pretty simple! Once the life of the container is over, the management container is updated. Taking this just a little step further, we will want more than just stop and start information from the workflow, not to mention checkpoint data. Currently, my imagination takes me to Microsoft Azure EventHubs for status and notification. The scale and history time frames are already there to use the EventHub as a central feed. The possibility to push workflows down to on premise devices that support containers is not an issue. Storing the checkpoints is where things get a little fuzzy to me, since these containers may run on Hyper-V, would we not just take a production checkpoint combined with replication(?), I am just not sure about that at all. The idea of this post is not to have all of the information but to plant the seed, if not already out there. If you think about AzureStack running locally with little need for System Center while requiring Windows Server 2016 (Technical Preview 2), the thought of this may just be cold coffee.
[sorry no pictures, maybe I will add some later to give you a graphic view]
Now lets look over at PowerShell Sessions! Let me start at security, and just say that remote (heck, local for that matter) sessions running in a private runspace container kinda sounds like a good idea. All of the information needed to spin up a new PowerShell environment is provided in the PowerShell Session configuration. This means that the required modules and other items required should be able to auto load/pull into a container upon start. The number of supported concurrent sessions is provided so we know how many containers we can start up as they start being used. I do see some issues with built-in remoting security being transitioned over. Again, I don’t have all of the answers, I am just taking what we have and applying a new spin on it.
Hopefully I will blog again soon! Next up would be Azure Active Directory and Windows 10 joining, do you realize that on premise Active Directory was just moved form a permanent position to a contract position in your organization!