了解简单措施，使您的无服务器采用取得成功
一年多以前，在奥地利的Semmering自然环境中，我们在一条小路的交叉口迷路了。由于路标不明确，我拿起手机寻找线索。在几条Twitter通知中，我刚好看到了Paul Johnston在他的文章《学习无服务器 (以及为什么这很难)》中的提及。
在平常的日子里，我肯定会立即阅读它。但鉴于我们当时的位置以及我作为家庭指导者将家人安全带出树林的责任，我不愿为了无服务器而牺牲美丽的Semmering早晨。
回到家后，我阅读了这篇文章，并且Paul勇敢地准确地解释了这个问题！我本想更早加入讨论，但我全身心致力于完成《在亚马逊云上开发无服务器：构建企业级规模的无服务器解决方案》(O’Reilly, 2024)这本书，一年后我借来了锤子，并从整体的角度来看待这个问题，而不仅仅是关注学习本身。
在本文中，我将带您了解使用无服务器技术开发应用程序的一些重要因素，无论是在商业产品开发、构建数据驱动应用程序、人工智能还是机器学习方面。
《无服务器开发》
《在亚马逊云上开发无服务器：构建企业级规模的无服务器解决方案》
sbrisals.medium.com
驾驶汽车难吗？
- 驾驶手动挡汽车难吗？
- 学习驾驶手动挡汽车难吗？
这个答案根据你的经验而有所不同。如果你已经驾驶了几年，你对第一个问题的回答肯定是否定的。因为多年来，你已经熟悉了所有的操作，它们已经变得自然而无需考虑。
然而，当你还是个学习者时，你对第二个问题的回答肯定是肯定的。当你学习驾驶时，有很多需要考虑的事情 —— 需要协调的动作、需要按顺序进行的活动以及需要同时进行的观察。而且这些都是在车辆行驶的时候。
仅凭你会转动方向盘并不足以使你成为一名司机。
如果你现在考虑一辆自动挡汽车，作为司机，你的活动会减少一些，因为汽车的机械结构会处理某些动作（就像云服务提供商会处理无服务器的一些繁重工作一样）。
我们日常生活中的很多事情都具有挑战性，但我们通过学习技能并沿着经验证明的道路变得更加擅长。无服务器开发也不例外。它可能听起来有点简单（就像自动挡汽车一样），但它不会让您立即启动引擎并疾驰而去。
在技术领域，有很多错误的做事方式，无服务器领域尤为如此。构建一个复杂的事件驱动架构并使用无服务器服务很容易且不需要花费很多时间。然而，设计和开发一个模块化、可观察和可持续的解决方案需要知识和正确的技能。这并不意味着无服务器很难。
在技术领域有很多错误的做法，尤其是在无服务器领域。
如果你不了解无服务器的生态系统，无服务器就很难。
汽车由许多部分组成，从高层面到细节层面。汽车发动机主要被写作一个单独的单元，但有几个组件。一辆正常运行的汽车需要一个驾驶员（忽略无人驾驶），并搭载乘客。从某种程度上说，所有这些一起构成了汽车的生态系统。
很多人常常把无服务器描述为架构蓝图、函数即服务（FaaS）或框架。对我来说，它超越了这些，不仅仅是我们通常所想象的那样。无服务器在某种程度上是一个技术生态系统。当你和我使用无服务器时，我们也成为其中的一部分，就像驾驶员和乘客是汽车的生态系统的一部分一样。
如图所示，无服务器的生态系统有几个因素。无服务器技术具有其独特的特点。云平台及其托管服务构成了基础。开发实践、工具和框架使价值流更快。业务利益相关者与工程师合作，在无服务器上为客户构建现代功能。所有这些以及更多都是该生态系统的一部分。
上述描述的目的是让你思考超越编写函数或争论基础设施工具的范畴。想象一下无服务器为你的组织、团队和你自己带来的多样性，因为当你使用无服务器时，你将需要扮演多个角色。与以往相比，像Lee Gilmore所说的这样的思考更加常见，因为我们正在不断成熟并成为无服务器生态系统的一部分。
如果你以错误的心态开始使用无服务器，无服务器就很难。
几年前，一位工程师在他的无服务器之旅中寻求指导。在聊天几分钟后，很明显他希望以一种与云无关的方式实现他的Lambda函数的逻辑，以便在他所在组织的决策者想要切换时，他的无服务器应用程序可以轻松部署到不同的云提供商。
了解了他的意图后，我问他对非FaaS服务的处理方式以及他如何使它们与云无关。他的解释是某种宏伟实施的六边形架构！
在通话结束时，我意识到他尚未将任何无服务器工作负载部署到生产环境中！
虽然像上面那样的思考和方法可以取悦董事会，但挑战和对企业的价值并未得到评估。企业采用无服务器等技术是为了提高速度、增加流程，并建立竞争优势。以上述心态对待无服务器就像追逐幻象，永远得不到任何东西并且很快交付。
工程师常常指向框架提供的多云配置作为一个例子（或者借口）。事实上，工具提供这样的功能，以便每个人都可以使用它们，并且你不会根据一个框架提供的功能来做出多云决策。当这样的错误策略无法产生价值时，你会听到诸如切换到无服务器很难、令人困惑和违背直觉的抱怨，正如保罗在他的文章中提到的。
开发工具经常支持多云功能，但你不能根据一个框架提供的功能来做出你的多云决策。
如果你认为无服务器太容易，无服务器就很难。
我受邀参加一次会议，倾听并批准一个无服务器架构提案。一位工程师呈现了一个设计精良的虚拟面板，并介绍了他们的架构。Lambda函数主导了解决方案，周围散布着几个DynamoDB表。我开始感到不舒服，就礼貌地打断了对话，并提出了一个问题-
你之前构建过无服务器解决方案吗？
工程师回答说，是的！
在设计中提出了一些选择的“为什么”之后，工程师承认以前他们只是为简单功能编写了Lambda函数，没有架构化也没有构建事件驱动的微服务。
我在这里的意图不是贬低工程师，而是要突出我们在接触和使用新技术时都经历的一个重要阶段。知道如何编写和操作Lambda函数绝对是正确的开始，但同时，您不应该认为在无服务器环境中一切都太容易而过度激动。这种态度会导致您实现纠结的无服务器应用程序。
我同意，对于刚开始接触无服务器的人来说，将问题分解为微服务，识别应用程序的同步和异步部分，以事件为中心思考，或者为可观察性设计都是复杂的。事实上，其中许多方面既不是新的，也不特定于无服务器。不同的是，在过去的孤立团队结构中，作为程序员，您从未有过这种接触或参与过程。
当您学习驾驶时，在进行实际驾驶测试之前，您需要接受几堂课程才会有信心。同样，评估您的无服务器技能并在您作为无服务器工程师的工作期间进行必要的学习（在后面的章节中讨论）是必要的。
如果您排除了工程师参与架构讨论，无服务器是困难的。
在指导团队时，我采用的一种方法是将一个或多个工程师负责服务或功能的开发——从构思到实际生产。他们从与产品团队、利益相关者和技术专家进行的早期对话开始，了解他们将要构建的解决方案。他们参加必要的构思会议和问题分析，并在高级人员和专家的指导下开始起草架构，然后提出一个供大家审核的解决方案设计文档。从这里开始，创建实施票，并进入迭代开发和交付阶段。
解决方案设计在无服务器开发中的重要性 — 第一部分
它带来了什么，为什么我们需要它？
sbrisals.medium.com
上述方法是有意的。尽管存在缺点和批评，但它为团队和工程师的专业成长带来了许多好处。为了教育工程师并使其成为无服务器生态系统的一部分，您必须停止向他们提供架构蓝图。相反，您通过提供想法和资源来与他们共同演进架构，使他们学习、开发和交付。
不要在架构师的象牙塔中制定您的无服务器架构，而是在团队的引擎室中创建架构。
曾经有一个组织进行了团队间的跨部门协作，以推出一个新功能。在同意一个高层提案之前，有几次构思会议，与一群人一起参与。后来，有几位工程师被分配了一个任务，来实施他们团队部分的解决方案。然而，这些工程师从未参与过前面的会议，没有听过任何简报，也没有看到捕捉了所有随笔、图纸和前期对话思考的虚拟看板。
如您所想象的那样，上述工程师们处于困境之中。无论工程师的能力如何，问题的琐碎程度如何，确保您的无服务器开发不是以Visual Studio（VS） Code开始。如果您这样做，无法保证您的无服务器体验会更加顺畅。
无论工程师的能力如何，问题的琐碎程度如何，您的无服务器开发不会从VS Code开始。
如果您追求完美而不实际，无服务器就会很困难。
在我关于如何发展您的无服务器团队的演讲中，我分享了一张幻灯片，展示了一个实践思维的团队如何在无服务器环境下加速，而一个试图使一切都完美且拥有悲观观点的纯粹主义团队则落后。
通常情况下，信息过载和象牙塔架构师的完美主义，缺乏实际引擎舱经验，会使你的无服务器采用变得困难，你的体验变得糟糕。
我曾经听说过一个社区对话中讲述的关于两个无服务器团队的故事。这两个团队有共同之处。他们在各自的界限内运作，开发了事件驱动的微服务，并拥有明确定义的API。
一个团队在单一的生产AWS账户中拥有并运营他们的微服务（测试、QA、预生产等有单独的账户），将其Lambda函数放置在自定义VPC（虚拟私有云）之外，并只在必要时配置VPC，他们将API托管在Amazon API Gateway上，并配备必要的使用计划。他们的服务是由亚马逊EventBridge上的自定义事件总线协调的。对于这个团队来说，开发、部署和运营一个新的微服务似乎是毫不费力的。
然而，第二个团队受到纯粹主义思想的指导，选择将每个微服务托管在单独的AWS账户中，并将他们的Lambda函数部署在自定义VPC中。此外，他们所有的API都托管在不同的网关平台上。随着微服务数量的增加到二十个，并且还在增加中，他们正在为涉及的复杂性而苦苦挣扎。
当然，在我们做出不同选择和决策的情况下，我们应该评估并进行纠正，以避免陷入难以管理和无法回头的境地。
采用无服务器的主要动机之一是将繁重的工作交给云提供商，但如果我们通过我们的策略违背了无服务器的优势，无服务器只会变得更难。
无服务器如果破坏团队界限会很困难。
在团队界限方面，每个人都会想到有界上下文（就像领域驱动设计中的概念）。然而，与自治的“两披萨”无服务器团队相关的其他界限也是相关的，如下所列。破坏界限会导致一系列后果，使您的无服务器体验变得困难。
- 有界上下文边界
- 团队责任边界
- 团队所有权边界
- 源代码存储库边界
- 云账户边界
前三个是相关且相互重叠的。如果你的团队是组织域的一部分的有界上下文的保护者，那么你就处于一个很好的位置。在这种情况下，你的团队对这个有界上下文内的一切负责，并拥有所有特性、服务和实现工件。
你所有拥有的资产的实现工件都在一个团队成员共享和贡献的存储库中。
AWS云账户边界标志着您部署和运营云和无服务器资产的操作边界。
在理想的情况下，你的团队与这些边界之间会有一对一的映射，如下所示。
- 由于有界上下文，你的团队存在。
- 你的团队对有界上下文内的一切负责并拥有。
- 你的团队有一个仅由你的团队贡献的存储库。
- 您的团队在其专用的云账户中运营它所拥有的一切。
你作为一名无服务器工程师的生活将会变得简单而愉快！
现在，让我们开始放松一下，打开边界，并想象可能发生的事情。
假设，由于业务优先级和满足交付期望的需要，你将另一个团队的工程师引入你团队的责任共享中，迫使你的团队的关注点发生变化。
- 你如何确保团队知道彼此的工作方式？
- 你如何确保代码质量统一？
- 你如何确保AWS服务的选择和架构模式的对齐？
- 你如何确保在运营责任方面没有遗漏？
这些团队可以合作解决和缓解这种情况。但是合作意味着更多的讨论、配对、审查、讨论、会议等活动，这些活动将影响到两个团队的关注和效率。
没有足够的思考就开放团队界限和共享责任可能会对组织产生负面影响。无服务器开发可能会变得更加困难，开发者的经验也会变得令人沮丧。
如果不投资于人员的成长，无服务器将变得困难。
我们身边充斥着快捷方式。有几个捷径可以教你编写Lambda函数。这种快餐式学习只能在食物还有时候有效。为了满足你的食欲，你需要继续点餐。
要在无服务器环境中取得成功，你必须不断学习。
保罗的文章主要关注学习以及那些刚入门无服务器的人如何在技术和生态系统方面努力上手。正如保罗所述，对于一个刚刚接触无服务器的人来说，单一用途的Lambda函数的概念本身就需要一些时间来理解。
要在无服务器环境中取得成功，一旦掌握了单一用途的Lambda函数，你就需要迈出许多步伐。许多领域作为你向成功目标迈出的踏脚石，你在路上会获得许多特质。
我经常强调无服务器给团队带来的工程多样性。如果你想让无服务器变得容易，这个认识至关重要。
工程师应该受到引导、培养、指导或培训（或者在你的组织中使用的任何术语），使他们理解利益相关方的需求，允许他们提出架构方案，灌输给他们单一用途函数和微服务的好处，向他们展示如何融入安全性，教导他们可观察性原则，让他们部署到生产环境，并将他们标记为服务的所有者。这些都不会一夜之间发生，也不是通过在YouTube上观看几个视频就能实现的。这就是高质量培训和长期人员成长策略的作用。
不要用企业官僚主义束缚工程师。让他们自由学习新事物，参加会议，参与技术研讨会和合作活动。
我在一次会议上与一位工程经理交谈。她认为花上几个小时或更长时间的EventStorming和Architecture Katas等研讨会是浪费时间，影响团队的生产力。所以我问她，如果有几个机会被拒绝和不满的工程师请了一两天的病假，她会怎么处理生产力问题。她没有答案！
无服务器训练营是为工程师提供无服务器技术生态基础的简单方法。一些组织已经成功实施了这样的项目。有一次，亚马逊Web服务(AWS) Hero马特·科尔特提到了在Liberty Mutual公司新员工中的一个成功项目。组织经常以预算限制为由削弱这类倡议，而根本没有评估它们所带来的好处。
无服务器培训的一个挑战是课程大纲中技术、开发、架构和运营要素的质量和覆盖范围。在众多课程中，我听到了对Yan Cui的生产级无服务器培训研讨会的积极反馈。Yan是一个AWS无服务器Hero和无服务器知识的强大力量。
生产级无服务器
学习构建生产级无服务器应用的最佳实践。
productionreadyserverless.com
使工程师理解利益相关方的需求，允许他们提出架构方案，灌输给他们单一用途函数和微服务的好处，向他们展示如何融入安全性，教导他们可观察性原则，让他们部署到生产环境，并将他们标记为服务的所有者。
无服务器将变得更容易……
就像开车随着驾驶时间的增长变得更好、更容易一样，当你积累经验并熟悉无服务器的生态系统时，它也变得更有生产力和愉悦感。
过山车并不是每个人最喜欢的。寻求刺激的人经常给其他人的最常见建议是——你必须学会放手！
你必须学会信任无服务器技术，以便充分利用它所提供的无差别的繁重工作。如果AWS提供托管解决方案，那就利用它们来增加业务价值。为什么要努力对抗并构建你永远不会需要的复杂解决方案呢？
从那些成功采用无服务器的人们那里汲取灵感。
最后，我找不到比Momento’s AWS re: Invent 2023 Community Party主题更好的短语了-
相信无服务器！
是的，相信无服务器，学会放手！