在AWS上构建新的SaaS产品的指导原则

在本文开始时，我不会说在云提供商(特别是AWS)上构建SaaS有一个真正的方法。我可以自信地说，有很多错误的方法。在Trek10中，我们发现自己在帮助那些看到自己的AWS使用率飙升，并且需要整理AWS云的有机本地作物的混乱局面的客户。本文摘自多年来与AWS之旅中不同阶段的人们一起工作的精华，旨在帮助您远离错误的道路，走向成功的道路。

事实上，Trek10已经帮助足够多的人在AWS上构建和维护SaaS，因此我们很高兴成为设计服务和构建商类别中全新AWS SaaS能力的首家发布合作伙伴。

你知道这个故事，甚至你自己也可能在故事中扮演一个角色。一家公司正在转向软件即服务模型，以实现其产品的现代化。高层有人听说云加快了创新的步伐，并宣称，我们必须加入进来，否则就会被落在后面；这家公司不会成为采用曲线上的落后者！如果你真的走在前列，一两个工程师听说过这种新的无服务器产品，只是厌倦了安插和修补他们的全自动化团队，老板。

根据我多年来的所见所闻，以及与值得信赖的同事的一些讨论，我想谈谈我将如何(并且实际上已经)从第一天起就建立新的组织(产品、SaaS等等)以获得未来的成功。这里有几个引导灯塔，可以帮助你做出正确的长期决策。

这可能看起来很愚蠢，特别是如果您的组织已经存在了一个世纪。然而，在新产品和老公司中，构建的方法就好像您可以在任何时候销售一样，也有类似的效果；它迫使您使用最佳实践和孤立的方式构建。

为了实现这个目标，我会依靠一些众所周知的最佳实践，也许还有一些不太知名的工具。

随着AWS组织的推出，AWS明确表示，多账户策略是账户管理纵深丛林中的捷径。堆叠在控制塔和各种着陆区产品上，您可以放心，在当今这个时代，您甚至可以在最琐碎的项目中，以实践的方式轻松地利用帐户进行隔离。

这些天来，我最喜欢的协调工具之一不过是对原生AWS工具的薄薄包装，那就是AWS OrganizationForment。OrgFortification使用几个简单的标记和逻辑方案来设置帐户，并跨帐户部署/维护CloudFortification模板。

AWS帐户也是您工具包中用于限制爆炸半径的最有效工具之一。

最后，AWS组织会集中您的账单。任何足够大的云操作最终都需要云经济学家来理解其疯狂之处，但对于组织来说，您可以假装通过集中计费以及一些简单的警报或仪表盘将事情保持在可控状态一段时间。

按照这种结构，您会注意到，每个“产品”实际上都分布到自己的“组织单位”中，每个环境都分解到自己的AWS帐户中。帐单、CI/CD，甚至安全和安防审计都集中在一起，这有助于保持对整个公司的洞察力。

这可能看起来有点奇怪，但让我们直接引用我的朋友Ben Kehoe的话，他是云机器人研究科学家和AWS社区英雄。

将您的开发环境移向云，不要尝试将云向下移动到您的开发环境。

不可否认，有大量的工具和计划可以为本地开发人员环境带来熟悉的开发周期。有些比其他的要好。一些国家比其他国家实现了更多的平价。尽管其中一些是好的，但不可避免的是，您最终会遇到一些不太完美的情况，您需要花费几天或几周的时间来为您的团队解决这个问题。更糟糕的是，当您部署的云版本中的某些内容不太正确时，您会花费周期进行调试。

如今，我个人的大部分开发工作都是在AWS Cloud9上完成的。包装盒上快速、可靠的互联网，以及我所说的足够好的功能集和语言支持，在大约90%的时间里确实足够了。

除了Cloud9之外，我还强烈建议使用共享的开发人员帐户，或者对于更成熟的组织，每个开发人员使用一个沙箱帐户。如果你感到非常雄心勃勃，也许甚至是短暂的AWS账户。

我会要求大多数开发人员在Cloud9中开始他们的一天，只有当他们真的需要时才会弹出他们的本地机器。我希望他们在本地进行单元测试或简单的模拟测试，以便在本地快速、有价值地进行测试，但他们真正的开发和测试是推向他们的沙箱AWS帐户。

这个有点微妙，但让我们考虑一下它迫使我们做出的决定。我们需要更多地反思我们的内部实践，并仔细检查我们的代码库，就好像它对世界开放一样。

这意味着，隐蔽的安全性虽然从来都不是一种好的做法，但绝对是行不通的。我们不能指望人们不知道我们将管理端点移动到/unfindable-除非-by-Everyone。这也意味着没有秘密散布在代码中，也没有证书文件存储在存储库中。

您的项目依赖项需要定期审核并保持最新。您需要能够在针对这些依赖项发布关键常见漏洞和暴露(CVE)后立即推出软件的新补丁版本。唯一安全可行的方法是使用自动化和全面的管道来部署您的代码。

还有一个隐含的尴尬角度。当然，即使在许多开放源码项目中，也明显存在一些草率的编码。但是知道(或假装)某个外部力量正在监视您可能会帮助您花额外的一两个小时来正确地拉出模块或添加那些您知道应该完成的测试。遵循这一原则的最后一点建议是文档。开放源码项目的好坏取决于它的文档。您可以拥有世界上最优雅的API，但是如果没有足够的文档将这一点传达给新手，就不会有人使用您的项目。好的文档不仅仅是您的代码或API。它包括您的基础设施实践、作为项目的指导原则、新开发人员的入门培训，当然还有您的代码和API。

看，妈妈，我的偏见显露出来了！显然，我是使用我选择的平台提供的工具进行构建的倡导者。

如果AWS没有它(或者说，如果CloudFortification不支持它)，它真的存在吗？我知道这是一个相当咄咄逼人的声明，如果不是轻率的话。然而，任何时候我偏离了平台原生产品的方向，我都很有可能会后悔。

这也意味着，您的平台提供给您的所有服务产品和编排工具都需要投入大量精力。不要害怕为你的团队设定一些界限，但不要武断地强制执行它们。

提供标准，但允许实验。AWS是一个广阔的生态系统，但也存在一些漏洞。您的公司将选择一些您喜欢的服务和模式，以及您不喜欢的其他服务和模式。帮助您的工程师了解首选和支持的模式是什么。明确表示他们可以偏离这些道路，但他们将更多地依靠自己。这类似于慈善的黄金路径方法，但它并不是真正的AWS特定的。

为了扩展，肯定有一些情况下，留在平台内并不是最理想的解决方案。在某些情况下，市场领先于您的平台提供商几步之遥。例如，AWS没有像Algolia那样针对快速前端搜索体验进行调整的功能。但重点仍然是，走出平台应该是一种例外，只有在真正需要的时候才会这样做。虽然去市场并不是我的第一选择，但它绝对符合我在2020年对无服务器的看法。

这几天我对无服务器的思考是按考虑的顺序进行的。-如果平台有它，就使用它-如果市场有它，就购买它-如果你可以重新考虑需求，就去做-如果你必须建造它，就拥有它。

-Jared Short(@ShortJared)2019年2月27日。

现在，去市场买东西并不总是效果很好。但我的遗憾要比我试图在它的位置上建造一些东西要低得多。为了说明这一点，我将依靠我的好朋友福雷斯·布拉塞尔来写下一千字。

在为这篇文章撰稿时，我联系了大约5个值得信任的人，询问他们对构建在云上的组织的指导。每个人都明确表示，基础设施即代码(IAC)是拼图中必不可少的一块。

如果您没有通过CloudForment、Terraform或以可重复的方式建模和部署您的基础设施的其他无数方法中的任何一种来管理您的基础设施，您最终会后悔的。无论您是通过在应用程序增长时费力地重建新环境来支付费用，还是在从试运行到生产的3小时手动部署过程中忘记勾选复选框并莫名其妙地使应用程序停机几个小时。

如果你没有从这篇文章中得到任何其他的东西，请让它成为IAC是云上保健品生命周期的基石。

这些3&34；指导原则就是这样。指导方针。它们并不是教条式地遵循以保证成功的信条。它们实际上是多年与客户合作和参与各种AWS项目的泛化代码片段。

将每一项技术决策作为长期的合作伙伴决策进行评估。当然，您是按第二天/第二天/每月计费的，但实际上您是在选择采用该技术作为SaaS增长的合作伙伴。有些决定比其他决定更容易被取代，有些选择会随着年龄的增长而过时。这是很自然的，也是意料之中的。同样，不要在当前环境下评估你过去的选择。你现在知道的永远比以前多。当涉及到这些决策时，给你的团队建立和创新的权威和力量。不要回避云的力量来增强你的团队，不要回避信任你的团队。

把权威推下去(不要把CEO推下楼梯)。负责其应用程序运营需求的软件团队将减轻运营负担。通常，这是在组织级别完成的，因为开发人员和运营人员是独立的团队/组织。通过强制开发团队拥有其应用程序的运维，他们有责任(和权限)对其进行更改，使应用程序更加稳定。**请注意，这在许多地方都是正确的，但在大多数软件作为服务运行的云中，这一点要明显得多**。

所有人都表示，我会毫不犹豫地在AWS上开发一款新的SaaS产品，其他人应该强烈考虑这一点，但要为你们的技术决策和团队制定行动计划。