Microsoft took another step toward being king of the cloud hill when it announced in January that it was releasing its Azure stack to the public. There are many technical reasons why this is cool, but more importantly, it's the psychological advantage this gives Microsoft.
Google has always had the ability for developers using its stack to develop locally on the same tools that run in Google App Engine. It recently forked its environments, so now the local and cloud environments are slightly different for some of the configurations -- I can't tell you how many nights I have lost sleep because of environments being slightly different! Development and hosting are two completely different things. What Microsoft did is one-upped Google and Amazon.
The psychological advantage comes into play for companies that aren't 100 percent sure about moving into the cloud or companies that don't want to be trapped in a proprietary ecosystem. Ten years ago, it would have been impossible to imagine Microsoft doing such a thing, but now their decision to release the Azure Stack is in line with their newfound love for open systems.
The truth of the matter is that we are all trapped by proprietary ecosystems, even if you are a big open source user. Everywhere you look, companies are using proprietary chat, storage, workflow, CRM, on and on, but one of the biggest blocks for companies adopting a cloud strategy is the fear of being trapped in an ecosystem that you can't get out of. Problem solved! Now if something goes wrong, just download the Azure stack, and you can run locally.
Truthfully, moving from the cloud to a local environment is going to be rare. Although it will now be possible, many of the advantages would be lost. Advantages like infinitely scalable storage, no need for IT support, offloading compliance issues. It would just be a lot of work, and unless you have the will and the staff, a move from the cloud locally would be beyond most organizations.
But I could see some companies that aren't yet ready to move up to the cloud but thinking about it seriously. In these cases, it would be great to design for the cloud, run locally, and then move the whole stack when you're ready. Sure, it would be extra work, but a whole lot less work then attempting to code in a "normal" on-premises environment and then attempting a move. Running the Azure stack locally first would be a smart first steps for companies that plan on moving to Azure but not for a couple of years.
Another option would be to run some of the stack locally and some in Azure. There are numerous reasons why people may think this is a good idea. However, the only two that resonate with me are performance or applications that for some reason won't run in Azure but could be cajoled to be running on a local Azure stack. Even with these two reasons, I would have to be convinced it to mix and match local and remote Azure environments. My general experience has not been good on this front. I really believe in all in or all out when possible.
I have talked about this before, but the truth is you shouldn't move your system to the cloud -- you should instead re-architect it for the cloud. Since Microsoft, Google, and Amazon are all very different in their PaaS offerings, to be successful you have to code specifically for any environment you are in. So even though the chances of moving a company from hosted Azure to local Azure are close to zero, it will make moving to the cloud an easier decision for those in charge. Being one of those people, I really enjoy one less tough decision to make in my day.