Azure架构问题

Question

请告诉我以下推理是否有效。

据我所知，当您构建Azure应用程序时，您会自下而上地构建它，并考虑到云（例如，数据库等资源在Azure应用程序中的处理比在旧的标准应用程序中处理得差）。

这意味着您无法开始构建业务关键型Azure应用程序，然后最终决定以某种原因以旧式方式托管它（可能您对性能或其他方面不满意。）

我能理解这一点吗？

Answer 1

在某种程度上，推理是正确的 - 某些云资源（如Azure表存储）在非托管世界中没有功能特性对应物。

尽管如此，Azure为您所做的大部分工作都可以通过数据库，队列（如MSMQ或Tibco），网络文件系统等进行复制。像HBase这样的NoSQL数据库提供了托管云的可扩展性在您自己的基础架构上，但它们需要重新审视您对数据访问所做的一些假设。 Microsoft还销售appliance for a private cloud，在本地复制Azure环境。

最后，在云和非托管环境之间移动所涉及的工作量取决于您的代码的分解程度，特别是在数据访问和进程间通信方面。

Answer 2

如果设计业务系统时考虑到解耦和域驱动设计，那么迁移到云（Azure，亚马逊等），扩展，分发或执行无论需要什么。

要记住几件事：

• 信息
• 域驱动设计
• CQRS Architectures的原则。

Answer 3

是的，但仍然......如果您为客户编写Azure应用程序并将其部署到云端： - 如果客户后来决定他们想为自己托管它，那该怎么办？ （可能有多种原因：性能，安全性，非战略性供应商锁定，成本等）在这种情况下，您将不得不再次涉及开发人员，再次测试等等（它可能是也可能不是同一个人）。你不能通过简单地改变一些配置参数等的一行来交换传统的主机（当然，除非你从一开始就为双平台实际构建它，为两个平台测试它等等。

我认为Azure作为托管选项，在应用程序设计方面感觉非常具有侵入性。

那个Web角色/工作者角色怎么样？这是否会让您在Azure上进一步锁定？是否可以轻松转移到传统的ASP .NET Web应用程序/ Windows服务？

抱歉这样沉闷的怀疑论者！ ; - ）

Answer 4

有两种主要方法：

1. 您可以在内部移动应用程序，而无需通过在Azure Appliance上运行进行任何更改。 http://www.microsoft.com/windowsazure/appliance/

2. 您可以构建解决方案，以便不使用特定于Azure的功能。例如，Azure SQL中的数据不在Azure表存储中存储。 ASP.Net MVC中构建的Web前端将在Azure和IIS上运行。

Answer 5

我相信IaaS（操作系统，托管环境），迁移到OnPremise可能并不困难。但是，如果我们大量使用不同的服务，云供应商作为PaaS的一部分提供，那么我们将不得不在迁移过程中面对这一负担。