Let's do the paradigm shift again!

It's summer, which means it's time to break everything we can't touch when classes are in session. We've got entire labs offline: time to play!

Our big experiment with lab technology this summer is going to be a product from Ardence, essentially netboot + management features, for Windows. Our current model is to create and push a build using Altiris -- a product similar to Symantec's Ghost, but which had some key features Ghost didn't, at the time of our purchase. We're pretty happy with Altiris, and we're quite good at using it. Our labs are pretty stable and happy. We have the time we need to complete a myriad of other projects during the year.

It's not really broken...so why fix it? Why are we looking at a paradigm shift?

Over the last few years, we've gotten the process of build development and deployment down to a science -- we've optimized, streamlined, and outsourced until we pared the process down to only the things we specialize in and the things we can't avoid. Unfortunately, the unavoidable process of pushing builds and preparing packages for midquarter updates still requires more man-hours than we'd like to spend, and it's pretty boring work, too. Even if we can shave time off the push process with faster networks and servers, it's never going to be all that speedy to install 10+ GB of data over the network to 200+ machines in 6 locations -- as time goes on, networks will get faster, but builds will get bigger and our number of locations is still growing. It has to be done, and it has to be done over interims, i.e. in 5 days (or less, if anything goes wrong). By 2008, we need to be able to manage builds of 30GB of data and 500+ machines -- in those same 5 days, with the same number of staff.

The other factor bringing us to the table is complexity. Our well-honed security model is defense in depth -- required logins, restricted access to c:, no access to cmd.exe, no right click on the desktop, registry lockdowns, group policies, the whole nine yards. Nonetheless our model is inevitably weakened each quarter as the latest must-have applications (and we added a dozen new items last quarter) require higher priveleges, write access to directory after directory, registry key after registry key. We're beginning to see the impact of this continual need to loosen up our security here and there -- some mysterious instability in some machines late-quarter, problems only reproducible on certain machines, and so forth.

Moving forward, these two factors are rapidly approaching intractibility. Network booting has the potential to break us out of the track we're on -- if updating a build or refreshing it back to its pristine state is as simple as rebooting the machine, and our network performance is sufficient to cover the load, we can cut our development and deployment time and immunize users from the daily damage done by applications which don't respect boundaries.

Ardence may prove to be too expensive to buy compared to what it saves us in time, but we're going to give it a shot. Eventually, something is going to come along that requires more access than we're willing to give to people even under a netboot model, and our only option at that point is likely to be Citrix, which is a solution of an entirely different flavor. But Ardence certainly beats Citrix on price per-seat and capital costs, and almost certainly on staff time. Adding a single point of failure makes me nervous in some ways -- but in reality, we already rely on the network for LDAP logins and Keyserver.

It's summer...let the adventures begin.