Architecture 高级体系结构/应用程序基础架构决策：在何处托管项目

我已经在脑海里反复思考了一段时间，想在空闲时间制作一个产品，但每当我坐下来开始实际工作时，我都会被这个基础设施决策所困扰，我很难通过它

项目 受众和目的 首先，我正在考虑的建筑产品将向美国的医院和大型医生办公室销售。我不想过多地讨论这个软件将解决的问题的细节，但我只想说，它将为美国的医疗保健提供者提供一种自动化特定监管要求的方法，据我所知，目前主要是手动解决

要求 我希望这是一个基于浏览器的应用程序。我最熟悉ASP.NETMVC，所以我是从这个角度来考虑这个问题的，但我不会反对其他解决方案

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

部分应用程序需要与客户的EHR（电子健康记录）系统集成。虽然它可能是可选的，但我需要能够访问一点这些数据，以使其真正发挥作用。EHR有许多不同的品牌和版本，有些品牌和版本比其他品牌和版本更易于构建第三方集成。无论我采取哪种体系结构方法，客户都需要提供集成部分……似乎有太多不同的场景，我无法尝试为每个场景提供解决方案

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

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

问题

• 我还缺什么？
  • 是否有其他一些托管策略可能适用于我的场景
  在权衡我的选择时，我还有什么其他的优点和缺点吗？

---

由于您计划使用大型业务应用程序，自托管可能不是最佳解决方案。是的-在过去的好日子里，我们（在我们自己的架构/数据中心）这样做了，许多企业继续这样做

最近的方法是云计算——为了满足您的特殊需求，我建议您使用一种结构即服务（IaaS）提供商，在该提供商中，您可以构建一个可伸缩的应用程序。亚马逊AWS的弹性计算云（EC2）就是这样一个提供商

虽然IaaS给您带来了许多好处，但它也意味着您需要维护服务器端的工作—例如安全性等。。。如果您有特定的安全需求（看起来您有），这可能是您在这里实现自己的安全性的一种操作

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

他们计划构建能够很好地集成、可以替换或移植的组件。考虑一下你所建议的产品与软件质量属性的关系，并根据需要进行权衡。 你错过了什么。。。

---

很多事情-我强烈建议分析现有解决方案（在您自己的helthcare领域）是如何制作的。您需要一份关于您的体系结构规划的非常详细的指南/帮助。

您要问自己选择哪种托管选项？支持这两种策略的做法越来越普遍，小客户可以使用SaaS云版本，而想要自己的安全保证和其他好处的大客户可以自行托管。