We’re currently past our 50% registration point. Right now, only 4-day registrations are available. Register at https://eventloom.com/event/home/PSNA16.
In just a few days, on February 1st, we’ll open all remaining seats for both 3- and 4-day registrations (same registration URL).
Registration ends during the first week of March. At that time, we’ll review the situation, and may be able to open additional seats. However, the price will go up a bit. Our absolute final date for registrations will be March 20th.
So you’ve got about 3 days before 3-day registration opens, and from there about a month to sign up. After that, if we have additional space or can make additional space, we’ll open more seats - but the price will be higher. If you’re attending, don’t forget to head over to http://www.zazzle.com/collections/powershell_devops_global_summit_2016-119347973985746667 to pick up an official conference t-shirt, hat, coffee mug, or notebook to bring with you! We also have commemorative tiles available, and will offer a new one each year for you to collect.
Our January 2016 puzzle comes from MVP Adam Bertram. We’re actively interested in receiving Scripting Games puzzles from members of the community - submit yours, along with an official solution, to us at admin@ via email!
We learned today that The DevOps Collective, Inc., (the company that officially owns and runs PowerShell.org, the PowerShell + DevOps Global Summit, etc.) was accepted by the US Treasury as a 501(c)(3) public charity. That means that the company is quite literally owned by the American public now, and run by its Board of Directors. No human or business entity owns the company and its assets, which is exactly our intent. Further, no human or business entity can profit from the company, which is also our exact intent. Regardless of who’s running it, it’s now big-time illegal for any Director (for example) to just partake of the organization’s money. Previously, it was merely unethical, but completely legal, as the company was technically for-profit. So we’re right where we want to be. Donations to the corporation are now tax-deductible, charitable contributions. However, a donation is when you get nothing of value in return; unfortunately, Summit registration fees - since Summit itself is of considerable material value - are not charitable contributions. Your registration is likely still deductible as a business expense (namely, education, along with your travel expenses), something you or your organization’s accountants should determine. Sponsorships - given that sponsors don’t receive anything of material value from us - are considered deductible contributions in most cases. I’m very proud to have brought the organization to this point, and I want to point out that it’s due in part to Microsoft’s own recent activities, such as bringing Core CLR, the WS-MAN stack, DSC client, and other bits to non-Windows operating systems, as well as their progress in open sourcing so many critical pieces. Those activities - and our expanding focus on DevOps in general - have taken us away from being an organization that supports a commercial product (MS Windows) to a much broader organization that was qualified for this beneficial status. I also want to offer a big shout-out to my fellow Directors, and especially Jason Helmick, who put in a lot of work with our own accountants to get this all in order for the IRS. For the organization itself, it means our main revenue activity - Summit - is now nontaxable for us. That means we get to keep all of our money to spend on organizational operating expenses, instead of losing some of it to taxes. That gives us a 15-25% boost in being able to operate our TeamCity public build server, this very website, our TechSession webinars, and other activities. This new status also, I believe, places us firmly on a path toward long-term existence. PowerShell.org is now, in a very binding legal way, something _we all own, _and something it’s on all of us to continue growing and supporting. Thank you for that support, and Happy New Year!
Hopefully, you’re aware that Microsoft is moving to UserVoice for accepting feature requests and bugs. DSC in particular has 30-odd suggestions at present, and I thought I’d run through some of my fav’s. Log in and up-vote the ones you like, or add comments to expand the discussion!
Change the Pull Server database to SQL Server. Broadly, this is a great idea. In theory, you should be able to modify the web.config file and direct it to a SQL Server already, but nobody knows the database schema that the pull server expects.
Refactor the LCM’s validation logic. This is another of mine, and it’s crucial. Right now, only the LCM can validate multiple partial configs and tell you if there’s a validation problem like a duplicate key. This means our only possible point of failure is the target node, which is the worst possible place for that to be. Factoring the logic out would let us built a pull server that could combine multiple configurations _server-side, _and spit out a combined, pre-validated MOF for the target to consume. We could also use the configuration logic to manually combine and validate MOFs in a test or RSoP mode, perhaps with a cmdlet.
There’s plenty more - have a look, vote for ones you like, and add your own suggestions! And there’s a lot more besides DSC in there - see anything that you think is important?
In Microsoft’s brave new world of agile, more-frequent software releases, including numerous pre-release cycles… Microsoft needs to rethink the way it communicates versioning. Windows Management Framework (WMF) v5 has, for me, been pretty much the perfect example of what not to do, and the perfect example of Microsoft still shoehorning itself into old nomenclature that no longer fills the bill. I know a bunch of folks on the PowerShell team are probably still trying to figure out what works, too, so this isn’t meant to be a hammer-on-’em post, but WMF5’s lifecycle was, from a versioning perspective, pretty hellish. We had several “technology preview” releases, which were simply named after their month of release. April 2015. November. Whatever. It was really difficult from within the product - e.g., via $PSVersionTable - to tell which one you were running, which made helping people difficult. None of these were supported in production until the “WMF5 Production Preview” released in late 2015, and in December we got “RTM” code. RTM means “Released to Manufacturing,” which is kind of absurd as a milestone, because there’s literally zero actual manufacturing going on. It’s just a word Microsoft is used to using. Windows 10 shipped with a production-supported version of WMF5, but it still wasn’t “final,” meaning RTM WMF is better than what shipped with the RTM OS. God willing, what ships in Windows Server 2016 will be v5.1 or something, because if we get yet another 5.0 release folks are going to start throwing up their hands and quitting. Now that Microsoft’s all lovey-huggy with open source and Linux and stuff, can we just copy what those guys do? Every time you release code, increment the version number. It’s that simple. There’s no “production preview,” there’s just “5.3.” And you maintain a list of what’s supported in production. If 5.3 isn’t a production milestone, fine - say so. But it’s still a real version, because it was released unto the world. The next release is 5.4. Then 5.5. And maybe 5.6 is supported in production, but once 5.7 is out, 5.6 remains supported for only 90 days. Or whatever. Just have a list of what’s supported, and increment the version number every time you release it. 5.8 might only last a week before someone finds some heinous bug and releases 5.9 - that’s fine. After that comes 5.10, and then 5.11, and so on. 6.0 is the first release of a major new evolution in the product, and it’s probably a “preview” release. 6.1 will be a bit better, with fewer bugs and more features nailed down, but it won’t be until maybe 6.5 that we get a “supported in production” release. All of this is a lot easier to keep track of than vague “version” numbers like “April 2016 Production Preview.” And while we’re at it, let’s have a Get-PSVersionInfo cmdlet. It can wrap around the existing $PSVersionTable variable, of course, but it can also ping a web service on Microsoft.com to tell you what the latest version is, what the latest supported version is, and whether or not your current version is supported in production. OMG, that would be _wonderful. _
There’ve been so many under-the-radar announcements and news bits about PowerShell, that I thought it’d be worth a quick start-of-the-week, pre-holiday roundup. First off, the big news is that **Windows Management Framework v5 has been released to manufacturing (RTM). **Not that there’s any real “manufacturing” anymore, but this means we’ve hit the milestone where it’s “done.” Now, if Microsoft is smart, whatever WMF ships with Win2016 will be “5.1” or something, so we can all keep track of what’s what. Fingers crossed on that. Next, and you may have missed this, Microsoft is moving away from Connect and over to UserVoice for many products, and PowerShell is now amongst them. Spread the word on this, because feedback is super-important, the team _actually does listen, _and UserVoice is now where it’ll happen. In the continuing move to open source, the PowerShell team **released a bunch of their tests on GitHub. **These are some of the tests they use to test PowerShell itself, and the ability for everyone to now contribute to those means the team can produce more error free code for us. This is a big deal, and proves this isn’t your grandfather’s Microsoft anymore. The **DSC Documentation has also been open sourced, **meaning we can all finally contribute to that. Yeah, we all know Microsoft should be producing their own docs - and they are - but this lets us correct errors, add examples and expansions, and fill in the gaps Microsoft may have to leave. They’re not a bundle of infinite resources, after all, and this finally lets us help each other in a more effective way. The PowerShell + DevOps Global Summit 2016 is about 1/3 sold-out. Currently, only 4-day registration is available. In February, we’ll begin offering any remaining seats for 3-day attendance as well as 4-day. We don’t recommend waiting much longer, because when we hit most people’s new fiscal year next month, it’ll be downhill to “sold out” again. Remember that registration cuts off at the beginning of March 2016, too. Finally, the Scripting Games puzzles continue to be posted at the start of each month (usually the first Saturday). We’re actively looking for a moderator to take over the process of collecting puzzle submissions from the community, coordinating puzzle and solution posting, and reviewing community submissions for noteworthy ones to call out. If you’re interested, drop an e-mail to admin here at PowerShell.org. We already have content for January and February 2016, and are also looking for puzzle submissions. Drop an e-mail if you’d like to contribute a puzzle and a solution. Happy Holidays from everyone here at PowerShell.org, and we wish you all the best in the coming new year!
Want to see what a real-world, functional, production-grade DevOps environment looks like? Look no further than Amazon Web Services’ Elastic Beanstalk (EBS). EBS is a neat combination of their EC2 IaaS product, S3 storage, and some DevOps magic. From a working perspective, it goes something like this:
Developer checks code into Git. A portion of this code is actually a set of EBS directives, outlining changes that need to be made to the base operating environment. This can include things like setting environment variables, installing packages, and so on.
Someone indicates that what’s in GitHub is ready for release. You can do this by pushing a button in your AWS console, or by making a call to AWS’ REST APIs. It’s pretty easy to automat this step.
AWS spins up virtual machines, and reads the EBS directives to get that environment configured the way it’s supposed to be. The code is loaded from Git into the VMs. The VMs are registered with AWS’ load balancer, and whatever old VMs were running are de-registered and destroyed. Poof, your app is up and running.
This model accomplishes the basic goal of DevOps, which is to shorten the path between developers and users. So where’s the “Ops” role in all this? Amazon did it. Their contribution to ops was to create all the automation necessary to make these steps happen. And the beauty of this model is that it supports tiered environments. For example, the above three steps might serve to spin up a testing environment, where you then run automated tests to validate the code. If the code validates, it’s pushed into a production tier - all automatically - running on a separate EBS application. So from check-in to in-production is entirely automated, and the process can be performed consistently every single time. Now… what would this look like in a Windows world? In Step 1, imagine that instead of a set of EBS configuration directives - which are just text files - your developers create DSC configurations. Yes, the developers. After all, they’re the ones who are coding for the environment, so that DSC configuration documents what they need the environment to look like. You might have a second DSC configuration that documents corporate standards for security, manageability, and so on. Whatever. Step 3 might be Microsoft Azure Pack or System Center Virtual Machine Manager, told - perhaps via an SMA automation script - to spin up the new VMs from a base OS image. The DSC configurations are run to produce a MOF, which is injected into the new VM. The developer’s code is deployed to the VM. The VM is registered with DNS and perhaps a load balancer, which provide access to it. There are a couple of important details that I’ve glossed over a bit. Jeffrey Snover is fond saying, “treat servers like cattle, not pets.” But servers by their nature have to have a few unique pieces of information, right? Well… yes and no. For all I know, cows make up names for themselves. I just don’t care. Take IP addresses, for example. You shouldn’t be assigning static IP addresses to servers; your DHCP system should be highly available, fault tolerant, and set up to handle servers. As you spin up a new VM, you can obviously have it register itself with DNS, so the IP address is mapped to a hostname. And speaking of that hostname - you as a human never need to know it. Or you shouldn’t. Windows will make up a host name for itself as the VM spins up, and you can - through your automation scripts - capture that host name. That lets you set up DNS CNAME records, a load balancer, or whatever else. The point is that while the server may have made up a name for itself, you don’t care. Nobody will ever address that server by its host name - they’ll use an abstraction, like a load-balanced name, or a CNAME, or something else. Your automation scripts handle the mapping for you. When a VM is spun down, automation de-registers the dying host’s name from whatever, closing the lifecycle loop. Interestingly, you could probably do this exact model, today, with a huge number of applications in your environment. Why bother? I mean, this model makes sense in web apps where you’re constantly spinning up and destroying VMs, but what about the majority of your apps that just run all the time without change? Well, this same model could spin them up in a disaster recovery scenario. Or in testing environments, which are constantly re-created to provide “clean” tests. Yes, it’s a lot of investment up front to make it all work, but once it’s set up it just runs itself. And that’s what DevOps looks like.
Here’s everything that’s fit to print regarding Summit 2016, running April 3-4-5-6 in Bellevue, WA! You can also download: Brochure-PowerShell and DevOps Summit 2016 to share with your boss and team.
Registration
Registration for Summit will open December 1, 2015, and run through March 1, 2016. Visit the registration website for more details. Registration will be limited to about 200 attendees. Initially, we will only offer registration for a 4-day event, which includes full-day pre-conference sessions on April 3rd, 2016. On February 1st, 2016, we will open any remaining space for 3-day registration.
Our November 2015 puzzle comes from PowerShell.org user [Tim Curwick][1], who created the puzzle based on a challenge he ran across at work. There’s nothing more real-world than this!
