SaaS: Announcing Windows PowerShell Snap-In for GoGrid

I am very pleased to announce the first public BETA (BETA2) of Windows PowerShell Snap-In for GoGrid. For the past week I’ve been working away on a project that brings to of the things that I am passionate about, specifically PowerShell and GoGrid (and especially what GoGrid represents).

The PowerShell Snap-In is an open source project, hosted up on CodePlex under the MIT license. If you are interested in helping out with the project the main thing that I need is getting people using the Cmdlets and reporting bugs.

Getting Started

The first thing that you are probably going to want to do is view this screencast which walks through using the Cmdlets. If that appears then you will need to go and create a GoGrid account, and also download PowerShell to your machine if you don’t already have it – then of course you need to get your hands on the latest version of the snap-in.

Why is GoGrid exciting?

GoGrid is exciting because it allows those wanting computing resources to provision those resources on demand using a simple web-based console and then pay for those resources by the hour, instead of by the month. GoGrid is very similar to the Amazon EC2 offering except that right now it is the only one to offer Windows 2003/2008 hosting using this on-demand model (at least, it is the only one that I am aware of).

One of the neat things about GoGrid and EC2 is that they both provide an API (GoGrid, EC2) that developers can use. This is useful if you need a system that can automatically scale the computing resources at its disposal (for example a massive video transcoding effort).

Why did I build this PowerShell Snap-In?

The purpose of the Windows PowerShell Snap-In for GoGrid is to demonstate how useful it can be for infrastructure-level SaaS providers like GoGrid to expose an API for their customers to use. I am hoping that it will encourage those responsible for provisioning Windows boxes to experiment with using cloud computing resources. Some key scenarios that I envisage are:

• Configure applications for performance testing.
• Run load agents for performance testing.
• Test disaster recovery scenarios.
• Provision hardware for project work (i.e. development teams).
• Support instructor led training with virtualised labs.
• Host demonstration environments for presentations.
• Controlling scale of your underling SaaS infrastructure.

There are probably lots of other scenarios that I haven’t thought of as well, if you can think of any please leave a comment.

Why is this relevant for SaaS readers?

If you are looking at using SaaS solutions or building SaaS solutions then you need to look at the technology stack that you are looking at. If you are sitting on a stack that doesn’t allow you to rapidly acquire more computing resources then you might get stuck not being able to access your services or service your clients. Services like GoGrid provide that scalable computing infrastructure without forking over big bucks. These PowerShell cmdlets allow your system administrators to scale your system and integrate that scaling function into their existing operations.

What is next?

I am hoping to provide PowerShell Snap-Ins for a variety of SaaS orientated services. I picked GoGrid first because it was useful to me, but when Amazon releases their Windows support for EC2 I will start investing more time on that Snap-In.

All your "man" pages belong to us.

I don’t want Carla Schroder to feel like I am throwing hand grenades over to her side of the fence (Linux), but I wanted to point out that PowerShell, the new command shell for Windows does in fact have some pretty good command-line accessible documentation that work in a very similar way to man pages.

With the command shell up all you need to do is type in “help”, and what you actually get back is an information page about how to use the help command, along with a few pages of examples:

The help system is pretty much tied to the various Cmdlet’s that the system has installed. The beauty of that is that you can ask for help for a list of the commands that it supports by typing “help *-*”:

The reason for this consistency is that PowerShell has all commands using a common verb-entity syntax. So if I want to bring up the help on a command – say Get-ChildItem, I would just type in “help get-childitem” and I would get several pages of help back.

Another cool feature is that it understands now to navigate aliases so if I asked for help on the gci command it would have returned the same result (because gci is an alias for Get-ChildItem, as is dir).

Let’s hope that PowerShell has command-line documentation for a long time to come!

Fun with scripting shells (how to rename multiple files in PowerShell).

I stumbled across this post by Rob Newcater on RootPrompt.org which points to this post on BasicallyTech.com. It shows the various ways that you can rename or manipulate filenames in groups using the bash shell and a smattering of standard UNIX utilities.

The sample given was renaming a directory full of *.mp3 files such that all the spaces were replaced with underscores – here is the script in BASH:

for FILE in *.mp3 ; do NEWFILE=`echo $FILE | sed ’s/ /_/g’` ; echo “$FILE will be renamed as $NEWFILE” ; done

That is pretty cool, although it is much more concise in PowerShell:

get-childitem *.mp3 | foreach { rename-item $_ $_.Name.Replace(” “, “_”) }

And by concise, I don’t mean shorter. One of the advantages of PowerShell over traditional text-piping shells is that you are dealing with objects which provide a lot more data to the next part of the processing pipeline. If you are into punctuation you could express it as:

gci *.mp3 | % { rename-item $_ $_.Name.Replace(” “, “_”) }

But to be honest, I prefer it the first way.

MGT304: PowerShell: Next Generation Command Line Scripting

Back when I was in high school I ran an after-hours bulletin board (you know, back when e-mail = FidoNet). Originally I ran the system on top of MS-DOS using the Maximus BBS package – it completely cracks me up that this software is still under active development and hosted up on SourceForge.

Eventually I migrated over to OS/2 which enabled me to run one line full time and an additional line after hours. Operating systems like OS/2 and DESQview were frequently used by BBS sysops because they were better at handling serial comms.

Of course, running a bulletin board involved more than just installing and configuring an operating system. Most bulletin board platforms like Maximus were really a framework upon which the sysop could build custom user interface and it was the process of taking groups of ASCII files and transforming them into the proprietary Maximus screen format (Mecca files). I would keep all of my ASCII files in a sub-directory and then after each change and do a batch conversion – the command that I issued looked something like the following:

for %f in (*.*) do build.bat %f

This would loop through each of the files that matched the filespec (*.*), and for each one call build.bat (a little batch file that I had strung together to do a couple of different things, including taking backups of existing files) – %f would contain the name of the file which is the subject of each loop.

Simple commands and scripts like this made my life a lot easier, and once I graduated from running a bulletin board to performing systems administration functions on computer networks I took my scripting skills with me.

Over the years I’ve used shells like bash, csh and ksh. I’ve also used Perl quite a bit. These shells give us quite bit of functionality and their use is considered a core skill for many UNIX system administrators. As dynamic languages like Python and Ruby get more popular in sysadmin circles, the boundaries of what is possible are being expanded – but where does this leave Windows system administrators?

The good news is that Microsoft has not been sitting idle and has been building a new command line and scripting environment for windows called PowerShell. In this session at Tech.Ed I’ll introduce PowerShell, look at what role it will plays in the future of platform administration on Windows.

What is the equivalent of the script above?

get-childitem | build

Of course, that assumes that I’ve got a function or cmdlet defined called “build”, but lets just pretend I do for now eh? See you in the session!

Aspen: PowerShell Futures

I just read the PowerShell blog and noticed that they are teasing us about the next release of the product and making sounds that it might have something to do with the next version of the Microsoft Management Console (note that the current version of MMC is 3.0). This is really a natural progression because if we look at some of the other management tools that Microsoft has shipped, the marriage of UI to underlying script generation is very useful for the system administrator community.

For example, pretty much every screen in the new SQL Server Management Studio (from SQL Server 2005) has the ability to product a script based on the current options on the screen. Ideally they could get to the same point that Apple has with their Automator tooling where scripting – even of the user interface components.

If every process declared its ability to be scripted then when you were doing a recording session the desktop compositing engine in Vista could somehow highlight those windows that could partipate in the process.

I suspect however that the Aspen release will be somewhat more limited in scope, and be more like the tooling from SQL. Still, I think it would be great fun to implement. If you are attending TechEd 2006 in Australia and would like to know more about PowerShell don’t forget to catch my session (MTG304) – it’ll be a must for system administrators responsible for managing Windows environments.