自从 Heroku 诞生之初，我就一直是它的粉丝。但我喜欢 AWS Elastic Beanstalk 让你能够更好地控制实例的特性。我喜欢 Heroku 的一点是，我可以部署应用程序，而不必担心管理它。我假设Heroku 确保所有操作系统安全更新都及时应用。我只需要确保我的应用程序是安全的。
我对 Beanstalk 的初步研究表明，尽管它会为您构建和配置实例，但之后它会转向更手动的管理流程。安全更新不会自动应用于实例。似乎有两个方面值得关注：
- 新 AMI 版本 - 随着新 AMI 版本的发布，我们似乎希望运行最新版本（可能是最安全的版本）。但我的研究似乎表明您需要手动启动新设置以查看最新的 AMI 版本，然后创建新环境以使用该新版本. 有没有更好的自动化方式将您的实例轮换到新的 AMI 版本中？
- 在发布之间，将发布针对软件包的安全更新。看来我们也想升级这些。我的研究似乎表明人们安装命令偶尔运行 yum 更新。但由于新实例是根据使用情况创建/销毁的，因此似乎新实例并不总是具有更新（即实例创建和第一次 yum 更新之间的时间）。因此，偶尔您会遇到未打补丁的实例。而且，您还会遇到不断修补自己的实例，直到应用新的 AMI 版本。我的另一个担心是，这些安全更新可能没有经过亚马逊自己的审核（就像 AMI 版本那样），自动更新它们可能会破坏我的应用程序。我知道 Dreamhost 曾经发生过 12 小时的中断，因为他们完全自动应用 debian 更新而没有任何审核。我想确保同样的事情不会发生在我身上。
所以我的问题是 Amazon 是否提供了一种提供像 Heroku 一样完全托管的 PaaS 的方法？或者 AWS Elastic Beanstalk 真的只是一个安装脚本，之后你就得靠自己了（除了他们提供的监控和部署工具之外）？
答案1
首先，要明确一点，Elastic Beanstalk 并不是您所想象的 PaaS。如果将其分解成几部分，它实际上更像是拥有虚拟化实例模板和应用程序部署自动化，如 puppet 或 chef。除此之外，您还可以自动访问 awe 的负载均衡器服务和云监控，这允许您根据指标启动新的应用程序服务器或关闭现有的应用程序服务器。
它之所以感觉像 PaaS，是因为其主要卖点是应用程序部署系统，它可以获取你的代码并将其复制到集群中的所有应用程序服务器。
一些人对 PaaS 的抱怨之一是 PaaS 供应商替您决定应用程序环境。在我看来，这似乎是 PaaS 的价值主张：作为客户，您可以专注于应用程序功能，而将所有其他细节留给 PaaS 供应商。您支付费用让其他人管理基础设施并提供系统管理。为了这种简单性，您需要向他们支付额外费用，就像 Heroku 的情况一样，它也在 ec2 上运行其基础设施，只是对您来说是透明的。
亚马逊实际上是在 Ec2 及其 REST API 之上提供 Elastic Beanstalk，并且没有花太多精力向您隐藏这一点。这是因为他们是通过 IaaS 赚钱的，而 EB 只是安排一组 ec2 资源的设置，只要您有时间和知识，就可以自己设置。
现在，就 AMI 的具体情况而言，AMI 再次成为用于促进 EB 的众多 ec2 组件之一。EB AMI 并没有什么神奇之处 - 它只是一个预先配置为与 EB 配合使用的 Amazon Linux AMI。与任何其他 AMI 一样，您可以在 EC2 中启动它，对其进行调整，并从正在运行的实例中派生出新的自定义 AMI。Amazon Linux 基本上是 Centos 和 Fedora 的结合体，带有半虚拟化补丁和由 Amazon 维护的预配置 yum 存储库。
您可能知道，Amazon Linux 已配置为在启动时安装安全补丁。但是，在补丁方面，正在运行的实例与任何其他服务器没有什么不同。补丁可能会中断服务。如果您非常关心安全补丁，您可以随时使用容器命令并设置 cron 以某种周期运行 yum update --security。
您还可以利用 EB API 来更改 EB 配置，或自动创建新的 EB 环境，然后在其启动并准备就绪后切换到该环境，然后关闭旧环境。具体描述如下： http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html
与 AWS 的其他功能一样，有一种方法可以通过编程方式访问和控制每个非 SaaS 功能，因此没有什么可以阻止您创建修补的 AMI，然后使用这些 AMI 创建新的 EB 环境并推出它们。EB 不会强迫您遵循配置细节，也不会为您提供系统管理组来维护基础设施。
答案2
自 2016 年 4 月起，Elastic Beanstalk 支持自动平台更新：
答案3
所有 Beanstalk 应用程序和环境都可以通过 EBEXTENSIONS 文件进行配置，这些文件与您的应用程序部署包（例如 Java 应用程序的 WAR 文件）一起打包，并使用基于 YAML 的配置来更新或重新配置应用程序、容器、操作系统等的任何部分。Beanstalk 是 PaaS，因为它是一个允许您部署应用程序而不必担心底层 IaaS 的平台。最终，所有 PaaS 提供商都会通过某种形式的自动化来混淆底层 IaaS。但是，由于我们讨论的是计算机科学，因此没有适用于所有应用程序的单一最佳状态，并且如果无法在 PaaS 下调整 IaaS，那么您只能依靠 PaaS 服务提供商来确保您的应用程序运行顺畅、快速且安全。
Heroku 在 AWS 上运行，使用不同的管理层。但是，当您必须执行诸如保护应用程序之类的操作时，它就会变得非常麻烦。虽然他们尽最大努力有效地管理他们的解决方案并维护安全性等，但他们无法也不会承担最终导致应用程序漏洞的风险和后果。他们希望使他们的服务尽可能千篇一律。
我认为，调整平台底层 IaaS 的能力是 Beanstalk 的优势和吸引力。