NASA is now preparing to upgrade the OS on the Curiosity Rover. No big deal, except it landed on Mars yesterday so a DVD or USB key are probably not viable deployment options. DHL to mars might be a little bit on the expensive side.
I couldn’t help but imagine the conversations in the NASA camp that might have led to this…
"Yeah yeah, good, maybe a bit behind, but we'll be OK"
"A bit behind?"
"Yeah, yeah, having some trouble with the drivers"
"Just a couple.. wheels.. laser.. The camera is working fine though.. well, black and white at the moment, but that's OK."
"Riiight.. And you'll have this fixed for launch?"
"Yeah yeah, well, actually we were thinking about that. Maybe we could patch it post launch"
"Yeah yeah, like we do with our PCs"
"And that'll work?"
"Yeah. Easy. We do it all the time here"
"But this thing will be on Mars, you know that right..?"
"Yeah yeah Mars. It's fine. We've got some ideas on that"
"How long did you say it take to get to Mars?"
"Ah! That's OK then. We'll have our long distance upgrade module by then. Yeah. Worst case, you'll land and won't be able to move for a few days"
I watched the live stream from NASA during the landing and was struck by the blend of technology and emotion on display. The amount of effort and planning that was involved captivated me. The smallest of mistakes would have rendered this mammoth project a failure and the high stakes made it even more spectacular. NASA even created a video dubbed “Seven minutes of Terror” that went viral highlighting the feat of this event. So when the Mars Curiosity landed I was relieved and excited.
When “stuff just works”
Isn’t it great when “stuff just works”? All of the planning had paid off. All of the technology put in place to get the Curiosity Rover to Mars had yielded a successful landing. Then NASA announced their website had gone down due to heavy load.
This left me conflicted. I’d just witnessed an awesome showcase of innovation, engineering and technology yet was not surprised that a website suffered a temporary outage. We have a habit of associating a sense of inevitable problems when major events take place. When it isn’t business-as-usual we fear something unusual is bound to happen. NASA has spent $2.5 billion on this project and the official website went down.
The link from Mars Curiosity to Earth started out at just five megabits. That’s now up to forty megabits when conditions are right and that’s before the Curiosity deploys its main antennae. Forty Megabits before the main antennae – that’s a better link than some sites can muster on Earth so surely the OS deployment will be a lot easier for the Mars Curiosity Rover?
How will the OS upgrade go for the Curiosity Rover? Will it be a success and go as smoothly as planned or will there be unexpected issues? Migrating Operating systems on Earth from Windows XP to Windows 7 feels like a major event and not business as usual. Is that true? Does it have to be like this? Is OS deployment on Earth more difficult than on Mars?
Is OS deployment on Earth harder than on Mars?
The Mars Curiosity doesn’t require business as usual for its OS deployment. The OS deployment is a critical stage in the project and will not disrupt their “business”. They can afford the upgrade to be an “event”. Deployment on Earth on the other hand does not share this same luxury. The cost of making an OS deployment a project can spiral out of control. The cost of personnel, time and expertise will all factor in. The planning required moving large amounts of data from one site to another without causing user disruption and not forgetting the migration of applications and user data. This isn’t business as usual. But why isn’t it?
OS Deployment on Earth should be easier than Mars
Unlike the NASA scenario, we have done OS upgrades before. In fact we’ve done them several times and we’ll do it again. We understand the challenges of OS deployments and our infrastructures so we created software such as Nomad 2012 that integrates with Microsoft System Center Configuration Manager to achieve highly optimized and rapid migrations with 100% automation across the majority of PCs. We’ve proven this in our ability to perform a complete Windows 7 migration on 39,000 machines in just one month.
This is business as usual.
This is how OS deployment should be done.
No disruption to users. Applications and user data all appear where it is supposed to be and all within a newly upgraded OS.
OS Deployment should be easier than on Mars. With Nomad and SCCM it is.
Written by Andy Hawkins
Why run Nomad 2012 vs nothing at all?
How does Nomad 2012 control your SCCM bandwidth management?
Nomad 2012 is a pure software solution which dynamically manages the bandwidth of IT content distribution in order to prioritize business traffic over IT traffic instead of traffic competition where it’s business traffic vs IT traffic. Nomad 2012 does this by Reverse QoS™.
By using Nomad in your SCCM (ConfigMgr) designs for branch offices and SCCM bandwidth management you no longer have to deliberate whether onesite should be your central location site vs another site. Instead when it comes to Microsoft SCCM WAN bandwidth management at branch offices you can target Applications and Packages without any additional SCCM branch office constraints due to the complete Nomad integration. There is no risk with using Nomad 2012 in your SCCM branch office design as it will augment the System Center infrastructure rather than compete with it.
Many organizations have a list of key criteria they need to meet within thier environments when evaluating Nomad 2012 vs other methods for managing client systems at SCCM branch offices.
How many servers will they reduce to before creating a single point of failure? Nomad reduces the server infrastructure at Microsoft ConfigMgr branch offices more than any other product on the market. It does this without having to ask the question of "should I deploy this?" versus "will this create a single point of failure?" because Nomad 2012 accounts for all scenarios.
Reducing your network infrastructure compared to creating a single point of failure
Nomad also has Byte-level differencing, client cache management and Peer to peer based redundancy, and the distribution mechanisms of Nomad 2012 allow an organization to dramatically reduce infrastructure servers by 95% or more without creating any risk such as a single point of failure, unnecessary client overhead or kernel drivers.
The requirements for many organizations require multiple sites in comparison to one site for many reasons, political, geographical or even high availability and disaster recovery, and Nomad 2012 can cater for all these scenario whereas others cannot.
Additionally, the OSD facilities of Nomad 2012 allow organizations to supercharge migration projects without any additional staff and achieve the highest possible amount of automation on most client systems. The PXE Everywhere functionality that is native to the Nomad 2012 solution allows for PXE in branch offices to happen without any server infrastructure while still effectively managing the ConfigMgr bandwidth to the branch. Try Nomad 2012 for yourself, whittle your list of ten questions down to none and manage the Microsoft SCCM bandwidth for your branch office at one site like you would your central site – in other words manage them all the same.