AWS Proton：“ Conway的法律即服务”吗？

如果现在有一件事将AWS Hero Slack团结在一起，那就是我们所有人都对Proton是什么感到有些困惑。我们想喜欢它！但是，就像……是什么？

-Forrest Brazeal @re：Invent 2020（@forrestbrazeal）2020年12月1日

“针对容器和无服务器部署的自动化管理，” AWS市场营销说。因此，这是专门用于部署无服务器应用程序（例如Stackery或Amplify）的工具吗？不！我认为他们之所以宣传Proton为“容器和无服务器”解决方案，是因为提供的两个示例模板包分别用于Lambda CRUD应用程序和负载均衡的Fargate服务。但是，尽管构建自己的模板似乎令人沮丧，但Proton可以帮助您部署的各种应用程序没有技术上的限制。

Proton本身仅是CloudFormation无服务器的“无服务器”：这是一项托管服务。那么Proton是新的和改进的CloudFormation吗？不，它使用全部用Jinja标记的CloudFormation模板，但是它的运行级别更高。

对我来说，花了一些时间才能找到答案，但Proton不仅仅是另一个半熟的AWS开发人员工具。它正在做我不相信AWS曾经尝试过的事情。

Proton的创新之处在于，它将关于您的组织的明确假设建立到其技术设计中。

多年来，我已经就中央云团队的现象（以及越来越多的病态）谈论了很多：位于云优先组织中心的Terraform书呆子，他们为其他人（尤其是产品开发人员）创建工具和标准。在您的公司中，该团队可能称为“平台团队”，“基础架构团队”，或仅称为“云团队”。即使最终不是最佳选择，这在大型组织中也是非常一致的。

实际上，“一个支持许多产品开发团队的平台团队”模式非常普遍，以至于AWS在真正的客户痴迷模式下，现在已经从它倒退了去设计Proton。 Proton是平台团队打包环境和基础架构服务，然后将其扔给将要使用它们的开发团队的说明性方法。 Proton在您的普通企业所做的工作中，在基础结构自动化和应用程序代码开发之间划清界限。

这意味着，如果您没有中央平台团队和多个开发团队（例如，如果您是一家10人的创业公司），那么即使您要部署许多Container和无服务器应用程序，Proton也不适合您（至少现在不是） 。并非由于许多AWS服务不适合您的原因-因为它们解决了您所无法承担的技术问题，而又负担不起-而是因为Proton以与您的组织不兼容的方式解决了应用程序部署问题结构体。

我真的想不到以这种方式构建的另一个AWS服务。甚至CodePipeline之类的服务都采用了AWS自己的组织理念（我认为它不愿支持基于分支的工作流）也隐含地采用了解决方法。 Proton专为企业型组织而设计。期。

那不是批评！ AWS绝对应该发布考虑到特定客户工作流程而设计的服务。哎呀，多年来，我亲自实施了至少三个定制版本的AWS Proton，在中央云团队工作的很多其他人也是如此。困难的部分始终是中央团队应该做的事情与开发团队应该做的事情之间的职责分离，以及无论您最终将其绘制在哪里，如何在这种分隔线上获得支持。我什至在2019年的这篇文章中写了一个简陋的Service Catalog-y解决方案，回想起来就像是在求助。

Proton具有规定性，因为它为您提供了用于协调应用程序交付的预烘焙模式，但是具有一定意义，因为该模式并未被视为任意的“最佳实践”，因此具有描述性–它只是AWS看到客户的标准已经在做。这样，它使我想起了更多我们经常看到的由AWS解决方案架构师和合作伙伴开源的参考架构，而不是典型的顶级服务。

Proton的预览版已经发布，尚未完全发布，因此我在这里不提供具体的技术建议，但我想解决一个批评，我已经从中央云团队中听到了很多话：“ Proton没有几乎足以简化创建部署基础架构的过程，对您有所帮助！”

去年，我指出“实用的CI / CD设计”是合理的，尽管它涉及复杂的模板设计，但是这种复杂性主要分布在您想要的位置：在平台团队的肩膀上。 （他们的工作是YAML！他们可以处理！）Proton进行了相同的计算，并且大多在同一位置绘制了分隔线。他们正在为平台团队提供原始的，有些劳动密集型的控件，以便向应用程序开发团队提供简化的部署工作流，并消除所有讨厌的基础架构。 （也许这是Proton被称为“无服务器”的第二个原因？开发团队没有服务器自动化吗？）

我担心质子实际上可能过于简单化，而不是过于复杂。因为在企业级别上，几乎不可能创建足够通用的部署模板，以适应各种应用程序团队的现成需求。当然，您将拥有一组“幸福道路”团队，您的模板可以很好地支持这些团队。但是，在某些极端情况下，需要您不支持的服务的团队或您无法提供的工作流程。您如何防止它们掉入影子IT……或更糟糕的是，将每个模板膨胀成一百万个无法使用的参数？

这些团队也许应该构建自己的基础架构，他们应该没有那么集中的命令和更分散的支持。这就是org的“伞形”模式->我在今年早些时候的一个博客中呼吁我表达CI / CD，就像在Proton设计会议上浪费了几分钟。我正看到越来越多具有远见的组织采用这种模式-与中央云团队一起工作了足够长的时间以意识到其局限性的组织。

中央云团队是瓶颈，即使80％的组织还不够成熟也无法解决这一问题。这就引出了一个最奇怪的问题：团队是否足够复杂以至于需要Proton最终变得过于复杂而无法使用Proton？

这还有待观察，但是我确实希望随着Proton的发展，它将带领客户走向可持续的最佳实践，而不是制造过去的组织错误。客户的痴迷程度很高，但是正如安迪·贾西（Andy Jassy）在上周的主题演讲中所说的那样-有时您必须给他们的不是他们的要求，而是他们的需求。