Yes there are reasons: it's slow and fragile. I know because a system which has been forced upon us is one of the buggiest on the planet. It can't tolerate the "challenges".
I don't think so. Given how many types of customer's microsoft serves, I think it's a good move. Many of microsoft customer are old sensitive business of banking, healthcare which have tons of regulation and being able to use Azure in their own data center is a really help them modernize their software stack.
Moreover, I don't know how we could undercut Microsoft on price either. I mean Azure and all of Microsoft Cloud Services(being Microsoft) probably gets Microsoft Windows licenses and all the licenses for free of cost and people like Rack space would have to pay for the licenses...
The only thing we could do is become better than Microsoft at reliability (hah!) and customer service (which there might be a shot at in the short term).
Key phrases: "enterprise on-premise data center" and "private cloud solution for IT pros and makes it easier for developers to scale their apps across their existing data centers and then boost to the cloud if they need more capacity on short notice" (emphasis mine).
The "Azure Stack" with those features apparently won't be available until 2016, however.
With the Azure Stack, you can deploy your applications on your on-premises (private) cloud, just like you would do in Azure - you're essentially retargeting the app. Our ultimate goal is to empower maximum application agility.
To enable the same deployment experience, Microsoft is bringing the same Azure portal, user experience framework, and underlying IaaS/PaaS APIs and services to your on-premises environments. We're also being thoughtful in which services we bring on-premises so that enterprise customers get maximum value.
We want to enable our customers and partners to run Azure in their datacenter in a way that's appropriate to their business requirements. We understand that not everybody operates at the hyper-scale that Microsoft does - as such, we will translate Microsoft's cloud designs and bring them to customers so it's easy to consume while enhancing flexibility and security in datacenter operations.
This is great news. Thank you very much for the explanation.
Will I be able to "burst" from on premise into Azure in this model? I'm in the process of deploying cloudstack/Ubuntu MAAS now for my on premise (and generally longer duration deployment) needs and using Azure for when I need rapid setup/teardown or a large amount of capacity (on demand).
If I could have one stack locally and in "the cloud", I would be VERY happy (especially if it's all tied in with AD, federated etc).
Yes. I have a housemate who is doing a rather interesting project with Azure at his workplace. Can't give any more real solid details than that, but Azure is essentially more open than AWS in the terms of giving the source of the special sauce it provides.
Every implementation needs a differentiating factor. AWS is its flexibility and ridiculous amount of built-in functionality - message queues, databases, DNS, storage, map reduce, etc. Azure moving from one-click deploy to the cloud to one-click deploy to your own cloud is amazing. It's the primary appeal of OpenStack for me.
The real question will be what will this take? If I have to put Windows Server 20xx on my hardware to run the fabric, I'm out.
It's not clear which X as a service will on premise Azure provide? While it is relatively easy to run virtual machines on private cloud platforms from vmware, Openstack and maybe now azure , it is notoriously difficult to provision DB or LB as a service or any of the other services
These kinds of developments can't make VMware happy. I have not understood why VMware never made a big iaas play when it had the chance to compete before others became established and established mindshare. I only guess they didn't want to compete against themselves, which is understandable but shortsighted.
VMWare's biggest competitor was itself and it's EMC linkage. IMO, moving towards IaaS t-shirt sized VMs makes it easier to architect around high cost stuff in the datacenter, like SAN.
> I only guess they didn't want to compete against themselves, which is understandable but shortsighted
I work on vCloud Air (VMware's IaaS offering) and this is just a guess (since I wasn't here at the time) but I imagine it wasn't about "competing against themselves."
It's easy to sit here in 2015 and say getting into IaaS early should have been obvious but that's ignoring the reality of what IT departments were saying they wanted. In 2008 88% of IT buyers preferred on-premise deployment, by 2014 that had declined to 13%[1].
FWIW early access to vCloud Hybrid Service (the original name of vCloud Air) was available in June 2013[2] and obviously something like this isn't put together overnight.
People working in IT data centers didn't work with cloud much, so they didn't understand the advantages. It's very dangerous to do product design in an echo chamber.
> As Jobs said, "Customers don't know what they want"
I see (and somewhat agree with) your point, but you're quoting/linking an article titled "Five Dangerous Lessons to Learn From Steve Jobs" that states just before the first bullet "here are some of the worst lessons to learn from Steve Jobs"
A better quote may be PG's "Make something people want"[1] - and if ~90% of the people you sell to are saying they want on-prem I'm not sure how (without clairvoyance or hubris) you can say for sure "nah, they're all wrong."
Amazon, Microsoft, and Google are much larger than VMware and can afford to put a lot more resources behind things that may never bear fruit - VMW had $1.8B in revenue in 2008[2], MSFT had $60B[3].
I understand hindsight is 20/20, but they should have been testing this alternative service, at least internally, with the other divisions, to see how well they could compete, if this thing caught on they could be somewhat ready. It's not that they need to predict the market, they should try for contingencies, what if that iaas does take off? Let's not get caught flat-footed.
Thanks for going open source with dotNet. We will use it on our Linuxes and BSDs, with gratitude and joy.
But when it comes to your intention of bringing your non-open-source'ed software to our data centers: we were actually almost finished taking them out, and feel much better that way.
Microsoft is on par with Linux and BSD machines. Until you are reading all the source code, there's no point in switching to Linux or BSD if you're already using Microsoft. Microsoft has the best and robust tools for the job.
What percentage of Linux users do you think have the capability or the desire to spend their time tracing calls through various libraries and kernel source?
When I run into a problem on my Linux machine, I typically have to do a lot of searching. More searching than I must do with Windows, because while there is generally only one Windows (at least relative to Linux), there are hundreds of Linuxes, distros and versions of those distros - many that are majorly different than the previous version.
Do you think it's easier for the average Linux user to find answers?
I thought the average linux user was a professional user. So, I guess I'd like to know if you think that most pros actually take the time to start digging into unknown code versus just looking things up?
>What percentage of Linux users do you think have the capability or the desire to spend their time tracing calls through various libraries and kernel source?
A minority, to be sure. But ultimately I am worried about the ability possessed by myself, my team, and potential hires. Not that of the average Linux user not working on the problems I am working on.
The argument for how the ability to do this is beneficial is not predicated on general users being able to do it, but the people administrating the services in question being able to do it.
If you have the ability to do so, it's possible in Linux (or the other open source OS). It's simply not possible in Windows.
Whether or not that's a huge deal is up for debate, but you're not really attacking a part of the argument that's relevant to their original point.
> I can trace the code all the way down to the kernel.
Maybe you can but do you? This requires not only figuring out how to compile your ENTIRE stack but also doing it AND figuring out how to debug each piece (since generic debugging tools are not the best). I understand there may be major issues that require this level of insanity but the rarity is so incredibly high and so few have enough domain knowledge to do it effectively that I don't buy this argument at all.
There's a level of understanding and debugging possible from reading the source without compiling/debugging that's not possible with access only to binaries. I'm a .NET/Windows developer mostly, and I've found myself consulting the .NET library reference source dozens of times over the past year. This has been useful, despite the fact I've never compiled it. Five years ago I would never have thought my work would require that level of understanding. You may be surprised how fast you can find yourself in areas where the internet doesn't provide ready answers when you start working on unusual stuff. You may also be surprised how fast you can figure out code that once seemed impenetrable when it's the next logical step in fixing an issue you desperately want solved.
> There's a level of understanding and debugging possible from reading the source without compiling/debugging that's not possible with access only to binaries. I'm a .NET/Windows developer mostly,[...]
I certainly agree with you but the claims of tracing the flow of execution down to the kernel? That's extreme in my opinion. Obviously there are times that's useful but for the majority of developers I can't imagine that's even as frequent as a rare occurrence. At least in my personal experience I only know maybe 2 people in my past experience who could actually do this. I just don't think the majority of developers know how to step outside of a few frameworks or languages.
At least Microsoft released the debug symbols for .Net back in 2012 so you've been able to at least trace through your framework's source for a while now :)
Dude, if there's one thing in abundance in a DC is non-open-source software. Can't imagine many DCs without one of these: Cisco, Juniper, Checkpoint, VMWare, Microsoft, Dell/HP on ILO/DRAC, F5 or Brocade; you effing name it. Your network, your SAN, all your effing data, everything! goes through some non-open-source'ed software stack. Oh yes, and let's not forget about all your NIC drivers for starters.
I think Microsoft has realized that their 'our way or the highway' approach only works for as long as the highway doesn't offer anything you need.
The fact that Azure can be used solely to deploy Linux VMs, for example, is appealing, and I've heard a lot of good things about it from iOS/Android developers who've used it.
This has been a consistent direction from Microsoft for some time. When Microsoft talks about private cloud or hybrid cloud, they refer to a design approach in which infrastructure and applications are separated. Even today, using the latest versions of Windows Server and System Center, you can manage physical hardware, storage and networking as a "fabric" and even offer self-service server provisioning.
In large shops, this allows for a real separation of roles between infrastructure and applications. I think this is a useful separation. Even in small shops where the same people are doing everything, this mental separation enables better management. Many small and medium sized businesses still operate in the mode that deploying an application or a major upgrade involves starting with deploying a new server.
I was in the Azure TAP program many years ago and they talked about this extensively to the participants. I would echo the consistency of direction on this. I had a vague sense that it was an attempt to quell enterprise fears about the cloud and lock-in, but perhaps not.
Amazing! This is again a smart move from MS. There is still a market segment that does not want to move to the cloud but looking for cloud like services, for example fast provisioning.
Yes. OpenStack is a nightmare for small shops without resources to have full-time OpenStack admins. The configuration and deployment is complex, and keeping it running demands a lot of attention. Plus the new releases every six months, and desupport of anything more than two releases old, make you feel like you're on a 100mph treadmill.
Microsoft always referred to Azure, from the beginning, as a new operating system - it was, after all, originally branded as "Windows Azure". This actually feels like it delivers on that promise - a datacenter operating system.
This has the definite advantage of limiting fear of being 'locked in' in deploying into Microsoft's Azure cloud - you can always run your application on your own Azure fabric. So does this also open up the opportunity for alternate Azure hosting providers to enter the market?
It also opens up the possibility of private-cloud versions of Microsoft's cloud offerings. Office365 runs on Azure fabric; can Microsoft now package that up as something you can deploy into your own Azure datacenter?
> This has the definite advantage of limiting fear of being 'locked in' in deploying into Microsoft's Azure cloud - you can always run your application on your own Azure fabric.
This lock-in is no different than the fear of being locked in into Amazon's AWS, Google's or Rackspace's services (even App Engine has open-source source-compatible equivalents out there). With the right tools (and there are open-source ones), you can deploy your applications to machines (real, virtual, containers) mostly anywhere.
50 comments
[ 4.4 ms ] story [ 297 ms ] threadI understand that Azure is Microsoft's Cloud Platform that provides services through which you can deploy your application on cloud.
Does this mean that you can run Azure on your own datacenter like Microsoft is doing currently?
The only thing we could do is become better than Microsoft at reliability (hah!) and customer service (which there might be a shot at in the short term).
Key phrases: "enterprise on-premise data center" and "private cloud solution for IT pros and makes it easier for developers to scale their apps across their existing data centers and then boost to the cloud if they need more capacity on short notice" (emphasis mine).
The "Azure Stack" with those features apparently won't be available until 2016, however.
With the Azure Stack, you can deploy your applications on your on-premises (private) cloud, just like you would do in Azure - you're essentially retargeting the app. Our ultimate goal is to empower maximum application agility.
To enable the same deployment experience, Microsoft is bringing the same Azure portal, user experience framework, and underlying IaaS/PaaS APIs and services to your on-premises environments. We're also being thoughtful in which services we bring on-premises so that enterprise customers get maximum value.
We want to enable our customers and partners to run Azure in their datacenter in a way that's appropriate to their business requirements. We understand that not everybody operates at the hyper-scale that Microsoft does - as such, we will translate Microsoft's cloud designs and bring them to customers so it's easy to consume while enhancing flexibility and security in datacenter operations.
Will I be able to "burst" from on premise into Azure in this model? I'm in the process of deploying cloudstack/Ubuntu MAAS now for my on premise (and generally longer duration deployment) needs and using Azure for when I need rapid setup/teardown or a large amount of capacity (on demand).
If I could have one stack locally and in "the cloud", I would be VERY happy (especially if it's all tied in with AD, federated etc).
The real question will be what will this take? If I have to put Windows Server 20xx on my hardware to run the fabric, I'm out.
I work on vCloud Air (VMware's IaaS offering) and this is just a guess (since I wasn't here at the time) but I imagine it wasn't about "competing against themselves."
It's easy to sit here in 2015 and say getting into IaaS early should have been obvious but that's ignoring the reality of what IT departments were saying they wanted. In 2008 88% of IT buyers preferred on-premise deployment, by 2014 that had declined to 13%[1].
FWIW early access to vCloud Hybrid Service (the original name of vCloud Air) was available in June 2013[2] and obviously something like this isn't put together overnight.
[1] http://www.softwareadvice.com/buyerview/deployment-preferenc...
[2] http://www.vmware.com/company/news/releases/vmw-vcloud-hybri...
http://www.forbes.com/sites/chunkamui/2011/10/17/five-danger...
People working in IT data centers didn't work with cloud much, so they didn't understand the advantages. It's very dangerous to do product design in an echo chamber.
I see (and somewhat agree with) your point, but you're quoting/linking an article titled "Five Dangerous Lessons to Learn From Steve Jobs" that states just before the first bullet "here are some of the worst lessons to learn from Steve Jobs"
A better quote may be PG's "Make something people want"[1] - and if ~90% of the people you sell to are saying they want on-prem I'm not sure how (without clairvoyance or hubris) you can say for sure "nah, they're all wrong."
Amazon, Microsoft, and Google are much larger than VMware and can afford to put a lot more resources behind things that may never bear fruit - VMW had $1.8B in revenue in 2008[2], MSFT had $60B[3].
[1] http://paulgraham.com/good.html
[2] http://ir.vmware.com/secfiling.cfm?filingID=1193125-09-38030...
[3] https://www.microsoft.com/Investor/EarningsAndFinancials/Tre...
Thanks for going open source with dotNet. We will use it on our Linuxes and BSDs, with gratitude and joy.
But when it comes to your intention of bringing your non-open-source'ed software to our data centers: we were actually almost finished taking them out, and feel much better that way.
When I run into a problem with my Windows machine, I have to resort to random searches and hoping that someone else has seen it.
When I run into a problem on my Linux machine, I typically have to do a lot of searching. More searching than I must do with Windows, because while there is generally only one Windows (at least relative to Linux), there are hundreds of Linuxes, distros and versions of those distros - many that are majorly different than the previous version.
Do you think it's easier for the average Linux user to find answers?
We're talking about a product designed to be run on multiple servers, in a datacenter. At that level, you're generally talking about professionals.
(edit: clarification)
A minority, to be sure. But ultimately I am worried about the ability possessed by myself, my team, and potential hires. Not that of the average Linux user not working on the problems I am working on.
The argument for how the ability to do this is beneficial is not predicated on general users being able to do it, but the people administrating the services in question being able to do it.
If you have the ability to do so, it's possible in Linux (or the other open source OS). It's simply not possible in Windows.
Whether or not that's a huge deal is up for debate, but you're not really attacking a part of the argument that's relevant to their original point.
Maybe you can but do you? This requires not only figuring out how to compile your ENTIRE stack but also doing it AND figuring out how to debug each piece (since generic debugging tools are not the best). I understand there may be major issues that require this level of insanity but the rarity is so incredibly high and so few have enough domain knowledge to do it effectively that I don't buy this argument at all.
I certainly agree with you but the claims of tracing the flow of execution down to the kernel? That's extreme in my opinion. Obviously there are times that's useful but for the majority of developers I can't imagine that's even as frequent as a rare occurrence. At least in my personal experience I only know maybe 2 people in my past experience who could actually do this. I just don't think the majority of developers know how to step outside of a few frameworks or languages.
At least Microsoft released the debug symbols for .Net back in 2012 so you've been able to at least trace through your framework's source for a while now :)
Increasingly, many tools and environments work best on Linux - which is quite an amazing shift from a decade ago.
http://cdn.geekwire.com/wp-content/uploads/2015/02/RightScal...
Some proprietary software vendors are not _that_ bad.
The fact that Azure can be used solely to deploy Linux VMs, for example, is appealing, and I've heard a lot of good things about it from iOS/Android developers who've used it.
In large shops, this allows for a real separation of roles between infrastructure and applications. I think this is a useful separation. Even in small shops where the same people are doing everything, this mental separation enables better management. Many small and medium sized businesses still operate in the mode that deploying an application or a major upgrade involves starting with deploying a new server.
This has the definite advantage of limiting fear of being 'locked in' in deploying into Microsoft's Azure cloud - you can always run your application on your own Azure fabric. So does this also open up the opportunity for alternate Azure hosting providers to enter the market?
It also opens up the possibility of private-cloud versions of Microsoft's cloud offerings. Office365 runs on Azure fabric; can Microsoft now package that up as something you can deploy into your own Azure datacenter?
This lock-in is no different than the fear of being locked in into Amazon's AWS, Google's or Rackspace's services (even App Engine has open-source source-compatible equivalents out there). With the right tools (and there are open-source ones), you can deploy your applications to machines (real, virtual, containers) mostly anywhere.