Software Delivery Bottlenecks - Deployment

Seems that the business waits on software developers, who have waited on system administrators, who have waited on infrastructure engineers to produce the ecosystem required for todays software applications, while waiting on the business to produce the contracts, by which the business can legally operate.

Looking at the most simplistic example of the macro tasks involved in a software project we have:

• develop software 
• runtime environment(s) 
• deploy software

If we assume an admissibly arbitrary cost of 1, for our tasks, and fundamentally all tasks being equal, then we can create a simple formula to help describe the bottleneck in our software delivery process.

We do have to account for things we do many times or iterations. For instance, we will deploy software through more than 1 environment. While the software hasn't changed, but we still have the overhead of the deployment cost.

Example

• assumed cost of 1 arbitrary unit 
• multiplier N, where N is equal to the number of iterations, which will be 5. 
• multiplier E, where E is equal to the number of environments, which will be 4 (Development, QA, Staging, and Production)

The Cost of Doing Business

• develop software (1 * N) = (1 * 5) = 5 
• provision hardware (1 * E) = (1 * 4) = 4 
• deploy software ((1 * E) * N) = ((1 * 4) * 5) = (4 * 5) = 20

 

Of course, this is a very simplistic view, contrived to drive the point home that deploying software can have a very high overall cost of a software delivery. Deployment is an area of the overall software delivery process that can bring an almost immediate value in economy of scale as the number of servers, and number of environments, increases.

Automate those things that have a high rate of repeatability. Don't be surprised, removing one bottleneck will typically force another bottleneck into the light and we address those one at a time.

People, Process, and Automation. 

Lather, Rinse, Repeat.

Windows PowerShell Retrospective

In interest of full disclosure, the opinion here is mine, and not widely shared by, well, anyone. With that out of the way, I like PowerShell, I really do, just I'd rather use Ruby.

Wikipedia on PowerShell

Windows PowerShell is Microsoft's task automation framework, consisting of a command-line shell and associated scripting language built on top of, and integrated with the .NET Framework. PowerShell provides full access to COM andWMI, enabling administrators to perform administrative tasks on both local and remote Windows systems.

PowerShell falls into the "scripting" language category, along with languages like Python, Ruby and Perl, and specifically targets the Windows platform. This means its a powerful tool for any type of Windows administration tasks.

So why then would anyone NOT use Windows PowerShell to administer a Windows system? You'd have to be a lunatic NOT to take advantage of Windows PowerShell, right? Right.

Taking advantage of PowerShell for discreet, Windows specific, tasks makes perfect sense as part of a toolchain targeting Windows. Basing an entire provisioning infrastructure around it probably does not. There are a plethora of existing tools to help you there.


[image from dev2ops.org]

Pick one. Get started with it. Enjoy life.

Things That Make Me Sad Inside

Stupid name. Really. I can't say "PowerShell" without hearing a Monster Truck voice in my head. I know you do, too. Granted, that was an easy one, so now that we've got the low hanging fruit out of the way, lets move on to other considerations when working with PowerShell.

PowerShell is dependent on .NET. No surprise there. However, PowerShell cmdlets written for previous versions may not work without a recompile targeting new .NET version, or some configuration changes. This is easily mitigated going forward with PowerShell 2.0 by leveraging a PowerShell vs. C# module based approach, which was not as convenient prior to 2.0.

PowerShell updates are tied to platform updates. Platform updates which may need to be requested of Infrastructure. You want to install Windows PowerShell (pre-Windows Server 2008 R2), you need this update. Look at all the goodness that you get with that update. You wanted just a PowerShell runtime? Sorry, its got dependency issues. Might also get a reboot out of that to boot. You read that right, this is not an XCOPY deployment we are talking about here. This update is something that is twiddling the bits of your server in an unknown manner. Do you have good feature test coverage on your applications to validate them after an update like that? Me either.

Enterprises are not generally a homogenous environment. This is where the wheels start to come off. Other scripting environments, even on Windows, might start to look more attractive. The major platform scripting languages (Python, Perl, Ruby) are each XCOPY deployable and have a side by side execution story, which PowerShell doesn't currently have.

Pipelining implementation goes a little too far. With most languages, pipelining is accomplished by piping ("|") strings into other processes. This is something every administrator is familiar with since the dawn of computing. Everything violates the Principal of Least Astonishment [PoLA] at one point or another, and with PowerShell,your first encounter with [PoLA] is when you start piping strings. Thats when you remember, you are not pipelining strings, but strings cleverly disguised as objects. Even with what appears to be STDOUT, aka, the console window.

PowerShell pipelining objects really isn't that big of a deal, except that it means you've implicitly broken every tool chain ever invented. Maybe thats a little overstated, but hopefully you get my point. Things just don't work like you would expect out of the gate, and you can spend an unfortunate amount of time refactoring your way around the pipelining implementation.

Even as awkward as pipelining feels at first, there is one feature of PowerShell that felt crippled because of it: remoting. If you've ever experienced secure shell (SSH), you know how convenient it is to SSH into a remote server, and read/edit a file.

Try doing that with PowerShell. Go ahead. I'll wait. Remote into a server and try to run the old edit.exe text editor. Its still on your system, I promise. Your PowerShell session will hang. This is because programs like edit.exe, vim, pico, emacs, etc. manipulate that console output in a tried and true fashion that just works on just about every platform (of course, you don't get SSH on Windows by default without installing something like OpenSSH, but thats another discussion). Very easy to work around this problem in a trusted, enterprise, environment by leveraging admin shares. Not necessarily as convenient, but there you have it.

It may seem like I'm bashing PowerShell (I meant to do that, then pun, that is) but I really am not. Its a very powerful addition to any Windows administrator's tool belt.  If you work on the Windows platform, you owe it to yourself to pick it up.  The ebook, "Master PowerShell", from Dr. Tobias Weltner, is an excellent resource to get started.