Hacker News Reader

Comment by OkGoDoIt | Hacker News Reader

Is there a reason you would ever want to do this in the real world or is this just pushing the boundaries for the sake of experimenting?

I’m not sure what the use case is for adding an extra layer of azure infrastructure on top of the existing azure infrastructure. I assume it costs more than just running on azure directly and doesn’t really get you any privacy/efficiency/performance benefits since it’s still running on the azure cloud. Perhaps it makes migration/deployment easier in some way?

View on HN

No, I am pretty sure this is just one of those "because you can". I suppose you COULD do this just to test out how Azure Stack would work on one of your existing azure templates/environments, before ponying up the $$ for the real hardware, or for someone who wants to learn how to deploy azure stack and gain some experience.. but not for workloads I dont think.

Or maybe to understand the deployment process before doing it for real?

To test the deployment process you need to do it on like hardware. This is why proper operations practice is to stage migrations/deployments.

I can see it being useful to handle different deployments and release schedules. Instead of having different environments inside azure for different releases, you could just have a different azure stack. That might even be preferable if part of the releases are making modifications to the stack itself.

I am currently working for a product to work with Azure Stack, but can't purchase and receive the hardware to run the devkit requirements in time for release.

Currently I am RDP'ing into an ASDK instance setup by a 3rd party, and this might be setup as a nested VM, but it does not matter as it is not noticeable.

Most likely this type of installation I will use more frequenting instead of keep dedicated hardware around just to run the Azure Stack Development Kit when it will not be used 24/7.

Yes. This is exceptionally beneficial in terms of testing and experimentation. Virtual machines in the cloud shine for non perpetual workloads, such as learning and experimentation. They shine less for long term (3yr+), stable workloads, where buying hardware and layering on something like Azure Stack, can save a company huge amounts of money.

My guess is that this is just an experiment for the sake of experimenting... But still, many things come out of this kind of experimenting.

Reply on news.ycombinator.com