Azure Stack宿主代码的安装给我们带来了驱动兼容性和一些安装错误的挑战，但我们最终解决了这些问题。艰难的部分对任何新事物,一个快速的谷歌搜索并没有为我们提供很多帮助,但与5环境工作,我们汇集的知识和通过辨识工作,主要是常识的东西,通过反复试验,我们算出了(尽管现在真的很好文档微软提供在线安装/配置/调试)。当我们长时间VMware的一个家伙说的是难走,我们不得不提醒他,如果他被前面一个ESX主机第一次有限的指令,他会得到多少设置主机和做所有的冗余和高可用性的东西在主机第一次。
现在我们已经多次建造并重建了主机，我们现在可以获得一个整个Azure Stack主机在几个小时内建造，所以与任何东西一样，一旦你知道它是如何工作的，它很容易......
一旦核心Azure栈开始运行，真正的测试就是将工作负载放到系统上。我们最初的工作是构建Windows vm和导入Windows vm，这是平淡无奇的，坦白说一点也不令人兴奋，但这是我们所期望的。这是一个微软的产品，我们已经使用VMware和Hyper-V多年来托管基本的Windows VM，没有什么太令人兴奋的运行一个基本的VM。但至少我们知道它运行VMs就像我们期望的那样好。
在我们的测试过程中对我们留下了什么对我们的留下印象是什么时候我们开始小提巴的服务。我们拍摄了我们的Intranet（内置于Microsoft IIS Web和SQL Server），逐渐弥补了支持PAAS环境的代码修改，并在我们的Azure堆栈内完成了一切并在大约一天结束时运行（代码Mods，代码上传，可扩展性测试，一切）。令人兴奋的部分是当我们将负载发生器放在事物上，然后缩放了Intranet以增加更多核心和更多存储的容量，我们只需点击添加资源，并动态添加资源！
We didn’t have to build more VMs, we didn’t have to insert VMs into a cluster, we didn’t have to setup external load balancers, we didn’t have to create more SQL server nodes and bring our clusters up and down to change capacity. THIS is where the power of Azure Stack is at! The code changes we made to our app were nominal, and here forward, we now have a PaaS enabled app that is built for the true scalability and “agility” that the cloud has been sold to us over the years, and is now readily available in our datacenter.
我们在Azure堆栈上安装了SQL（PAAS）提供程序，以与我们的Web应用程序可扩展性相同的方式缩放一些SQL Server实例。我们扔了SQL实例的加载，缩放它们并增加了更多的负载。任何时候我们对我们的要求更改了更多容量，Azure堆栈增加了我们在后端所需的资源。就应用程序（和用户）而言，他们没有看到，只是持续的绩效和正常运行时间。
We developed test processes of patching and updating the underlying components of Azure Stack, which there are base templates that serve up the capacity, however instead of patching and updating dozens (hundreds) of individual VMs, we’ve setup a process of updating the base templates that are to be deployed, and then as we deploy the templates, everything is already up to date and fully operational.
这是一个完全不同的操作模型，但我们一直在我们的组织内部重写操作手册，以管理一个Azure堆栈，而不是一堆独立的vm。回到我的搬家车的类比，如果我要搬很多东西，而不是维护100辆单独的车，我要维护5辆搬家车，其中3辆做大部分的工作，2辆是多余的备用。
For the current Azure Stack TP1 Preview, it’s just a single host server model, so we’re not able to do multi-site replication and redundancy just yet, but now that we are running full test workloads on the hosts we have setup in our datacenters, we can’t wait for updated generations of Azure Stack that’ll provide us multi-host / multi-site capabilities.
概括
我有机会在很多技术公开发布之前就摆弄它们，写过一些博客文章和1500页的书籍，其中包括一些在Microsoft Exchange、SharePoint、Active Directory、Apple Mac Integration、Unified Messaging、Office 365等平台上首次公开使用的文本。在Azure Stack上摆弄和构建案例场景让我脸上露出了灿烂的笑容。
Azure Stack完全改变了数据中心管理大规模应用的方式，甚至解决了开发/测试和高度安全、可伸缩的应用。
我没有看到基本的虚拟机很快就会消失。一个小org不会经历购买Azure堆栈来举办几个虚拟机的努力，就像屋主购买半卡车移动几箱甚至整个家庭都没有意义。在这些方案中，“租用”一辆面包车（或购买Azure（公共）能力）更有意义。
但是对于当前正在将应用程序的组织扩展到“数十”的单个VM，它们在大量的VM上划过了大量的VM，或者对于拥有所希望的云级应用程序的组织，构建为云构建Azure堆栈能力，但用于内部部署操作。
在我看市场的时候，组织不能把亚马逊AWS或谷歌放在本地，而且，不是每个人、每件事都准备好了进入公共云。微软在提供高度可扩展和全球分布式公共云服务(Azure public)的市场上拥有独特的地位，同时也为组织提供了运行完全相同的应用程序、功能以及云可扩展和冗余服务的能力。
正如我们看到今天要决定的组织到亚马逊AWS或Microsoft Azure的决定，如果你所做的一切并期望（永远）是云中的基本VM，那么它真的是在AWS与Azure之间折腾。但是，如果你就像世界上每个企业都希望在云中做一些东西的灵活性，而且有些东西在预境中;能够在IAAS环境中为VMS进行一些东西，并且在可扩展的PAAS环境中有一些东西，Microsoft上的银行业务提供了更灵活的选择，可以在今天和将来符合您的所有业务需求。
我将在接下来的博文中发布更多的实践技巧和指导，提供如何在Azure Stack中优化东西的内部技巧，以及如何测试正在进行的核心业务场景。请继续关注!