高级架构/应用程序基础架构决策：在哪里托管项目

Question

一段时间以来，我一直在脑海中徘徊这个想法，以便在我的空闲时间构建产品，但每当我坐下来开始实际工作时，我都会陷入这个基础设施决定，我很难熬过去。

项目

受众和目的

首先，我正在考虑制造的产品将销售给美国的医院和大型医生办公室。我不想过多介绍该软件将解决的问题的细节，但我只想说它将为美国的医疗保健提供者提供一种自动化特定监管要求的方法，据我所知知道，目前主要是手动解决。

要求

我希望这是一个基于浏览器的应用程序。我对 ASP.NET MVC 最熟悉，所以我是从这种思路出发的，但我不会反对其他解决方案。

应用程序的用户可以是任何医院员工/工作人员。他们只会看到专门为他们的设施设置的应用程序版本 - 基本上它应该是每个设施的一种内部网站点 - 他们应该能够使用他们的 AD/域凭据来访问他们的站点。

部分应用程序需要与客户的 EHR（电子健康记录）系统集成。虽然它可能是可选的，但我需要能够访问一些数据才能真正让它大放异彩。有许多不同品牌和版本的 EHR，其中一些比其他的更容易构建第 3 方集成。无论我采用哪种架构方法，客户都需要提供集成部分......似乎有太多不同的场景让我尝试为每个场景提供解决方案。

目前的想法

基于云的

我的第一个想法是，我希望它成为托管在“云”中的多租户应用程序；但是，对于集成，他们可能需要创建某种 REST API（基于我定义的合同）以供应用调用以获取所需的数据。出于 HIPAA 安全原因，似乎大多数地方都会犹豫不决。也许我错了。我知道对于 Azure，有 Hybrid Connections，如果使用它，可以让我的云托管应用程序连接到客户的本地资源。但我不知道这种解决方案的可行性或市场价值。

自托管

另一种选择是将其打包以安装在他们自己的 Web 服务器上（或作为包括 Web 服务器在内的整个软件包），然后为他们提供一个接口来实现以使集成部分正常工作。然而，支持这种部署似乎是一场噩梦。

问题

• 我还缺少什么？
  • 还有其他一些可能适用于我的方案的托管策略吗？
  • 在权衡我的选择时，我还应该考虑其他任何优点/缺点吗？

Answer 1

由于您正在规划大型业务应用程序，因此自助托管可能不是最佳解决方案。是的 - 在过去的美好时光中，我们做到了（在我们自己的基础设施/数据中心），并且许多企业继续这样做。

最近的方法是云 - 对于您的特殊需求，我建议您使用基础架构即服务 (IaaS) 提供商，您可以在其中构建可以设置的可扩展应用程序。 Amazon AWS 的 Elastic Compute Cloud (EC2) 就是这样一个提供商。

虽然拥有 IaaS 为您带来了许多优势，但这也意味着您需要维护服务器端工作 - 例如安全性等...如果您有特定的安全要求（看起来像您一样），这可能是您可以在这里实现自己的安全性。

其他托管策略包括使用 PaaS，例如 Heroku 或 Google AppEngine。虽然您不必处理 Infastruture，但它可能无法完全满足您的自定义安全需求。

无论哪种方式，都计划构建可以很好地互操作、可以替换或移植的组件。考虑根据软件质量属性评估您提议的产品，并根据需要进行权衡。

你错过了什么... 很多事情 - 我强烈建议分析现有解决方案（在您自己的医疗保健领域）是如何制作的。您需要一份关于您的架构计划的非常详细的指南/帮助。