我们最近的 ZipChat 《菠菜大平台》是富有洞察力的，充满了现实生活经验. 无服务器不仅仅是基础设施. 这是一种有助于理解如何构建好的软件的心态. ZipChat开始时的一个快速调查显示，大多数人仍在尝试无服务器技术. 在我们深入探讨细节之前，这里是对讨论小组的一个快速介绍，
- 甘地Raketla 是AWS的高级解决方案架构师吗. 他与AWS客户和合作伙伴在云应用方面合作, 帮助客户培养敏捷性和创新的架构解决方案.
- 马特·格里菲思 是天祥炼金术的首席建筑师吗. 他从事企业和网络应用开发已有20年的专业经验. 对知识分享和辅导充满热情. 他致力于以身作则，并授权人们寻求和发展他们实现目标所需的技能.
- 菲利普边缘 是工程部的副总裁吗 & 天祥炼金术公司的首席安全官. 他有20多年的企业应用开发经验 & 平台开发以及11年以上的网络安全项目(PCI-DSS)的实施, NIST, SOC2, GDPR, ISO 27001, OWASP).
会议由 迈克•沃森他是Synerzip的工程副总裁，是一位经验丰富的工程领导者. 他有超过15年领导软件团队的经验. Mike的热情是帮助软件产品开发组织过渡到强大的敏捷实践和文化中.
为什么serverless
Mike在开始讨论时问，为什么一个组织应该走无服务器技术的路线.
甘地回应说，理解应用程序的角色在过去20年中发生了怎样的巨大变化是至关重要的. 在过去, 应用程序是实现特定功能的工具, 通常只能提供帮助. 然而，今天的应用程序已经成为核心创收模式的一部分.
今天的竞争优势在于将客户需要和想要的功能迅速推向市场. 无服务器基础架构策略使您能够做到这一点. 它卸去了管理环境(比如打补丁)的所有操作职责, 维护工具, 等.给云提供商. 这种卸载可以帮助您更专注于增加业务价值的开发策略.
潜在的进入壁垒
一个快速的调查显示，无服务器的障碍平均分布在没有挑战的处理单片应用程序之间.
同意这个观点, Mike注意到有多少用于设置和管理基础设施的代码已经商品化了. 重新发明它会浪费宝贵的时间. 他进一步向甘地提出了一个问题，关于一个组织在走上无服务器道路之前必须评估的考虑因素和障碍.
应用程序体系结构
甘地补充道，这在很大程度上取决于商业模式，以及应用程序增值的方式. 当企业主开始考虑无服务器产品时, 他们必须重新考虑应用程序架构, 它触发的事件, 以及它如何变化. 而无服务器应用程序体系结构看起来很像传统的体系结构, 它在逻辑和实现上有一些区别. 他深入研究了一些突出的问题, 例如服务的模块化, 哪一个是微服务的领域.
模块化的服务
微服务包含执行特定任务和提高可伸缩性和弹性的功能. 无服务器基础设施的另一个变化是微服务中的这些功能如何通信, 包括事件, 消息传递系统, 和队列. 第三个最关键的变化是有目的的数据策略，为正确的工作使用正确的数据库，而不是为每种目的使用单一的数据库.
Gandhi进一步阐述了多个团队共享的单一发行渠道. 这种共享会导致瓶颈和复杂的相互依赖，从而阻止更快的发布. serverless技术, 处理功能而不是技术组件的团队不需要这种相互依赖. 他们现在可以按照自己的节奏移动，并以一定的速度发布功能.
无服务器的现实动机
Matt谈到了他使用无服务器框架的动机. 他讲述了他们如何构建一个与设备无关的现代应用程序，并且需要与主体(单片)应用程序集成. 与此同时，一些功能必须在后端进行扩展.
桥集成应用
这也印证了甘地的观点, 他谈到了无服务器技术如何帮助他们从担心基础设施的头痛中解脱出来，而不需要用大量的后端处理重新创造轮子. 无服务器帮助他们弥补了许多与AWS现在提供的服务的集成差距.
Philip强调了无服务器技术是如何内置在DynamoDB等许多组件中, λ, 等. 他还指出，该服务的整体容错能力非常强, 在那里你不用为任何空闲时间付费. 开发人员可以拥有生产环境的克隆，而不用担心在自己的机器上运行.
开发者的主人翁意识
对马特和菲利普来说，最让他们大开眼界的是它赋予开发商的所有权. 它消除了要求It提供基础设施来部署代码的所有杂务. 与serverless技术, 开发人员现在拥有运行代码所需的一切，并专注于他们最擅长的工作, 开发应用程序和编写程序.
Gandhi进一步补充道，开发人员通常需要设置他们的ide，然后将其与CICD管道集成, 管理id, 等. 这种设置占用了宝贵的开发时间. 无服务器允许开发人员在云中启动他们的ide，并通过开发管道快速配置它们.
生产档次，质量开箱即用
这些周期时间的缩短使无服务器技术能够将产品级API的开发时间从几个月减少到几天. 他们现在不需要担心测试功能的规模、可靠性等.因为无服务器技术为它们提供了健壮性和产品级的开箱即用.
借用这一点, Philip补充说，无服务器技术使他们能够快速开发原型和演示. 这种快速性让他们能够测试自己的假设，快速失败，并快速改进上市时间. 概念验证的时间已经从几个月减少到几天甚至几个小时.
将无服务器技术的好处与业务收益挂钩
Mike进一步询问Philip，他们的开发者现在是如何使用这种快速而激烈的开发方法的. Philip表示，他们的客户正在积极使用他们的产品. 无服务器的想法使他们能够构建安全、健壮的产品. 团队发现，与昨天相比，现在的市场可用性更强. 他们已经取得了一些很快的胜利，这让他们大开眼界. 他进一步表示，他们正在构建一个使用无服务器技术的本地云平台.
Matt进一步阐述了他们如何在一年多的时间里没有服务器，并帮助他们实现自动化，使他们更接近自动化的CICD. 原生云可以帮助他们利用无服务器的优势.
单片应用的混合方法
在这一点上，Philip谈到了混合方法. 他们的应用不能独立运行, 开发人员并不想仅仅为它建立一个全新的数据库，因为它仍然需要与核心集成. 主要前端是由S3桶的React提供的. 他们还在λ和传统的PHP单片应用程序之间使用了nodeJS.
他们正在构建REST端点，但不想为此构建专门的api. 因此，混合方法允许他们重新弱化一些现有的api，以支持与核心的集成. 马特和菲利普为新平台从头开始，但需要试水, 这种混合的方法让他们通过更快的学习和更快的失败来更快地行动.
克服挑战
培训和认证
在项目的初始阶段, 马特和菲利普并不完全了解AWS服务, 它们是如何工作的, 和他们的角色. 因此，培训和认证是他们首先完成的事情之一. 也, 认证和培训逐渐渗透到整个团队, 他们在哪里学会了如何集成和使用AWS服务. 工程团队中98%的人都获得了AWS认证，其中一些人已经获得了下一个认证.
异步工作流
了解无服务器功能, Matt解释说，您需要理解异步工作流. 在传统的软件开发工作流程中，整个团队负责所有的工作. 然而，异步模型任务需要移交给另一个服务或团队才能继续. 这个工作流在前端比后端更明显. Matt解释了他们是如何调整前端以适应这种异步工作流的.
基础设施代码
Matt谈到的另一个挑战是DevOps. 传统上，DevOps管理和调整基础设施. 与serverless, 基础设施代码, 因此，开发人员现在需要更多地了解网络安全和其他基础设施的细微差别，这些是DevOps专业人员的传统大本营. 另一方面, DevOps团队越来越意识到开发人员正在如何做更多的基础设施. 作为一个团队，团结在一起是一种学习经验和持续的过程.
选择合适的项目候选人
在初始阶段或在试验无服务器技术时, 甘地补充说，选择正确的候选人至关重要, 哪个对业务影响不大，但在功能上也很重要. 保持这种平衡很有挑战性.
改变思维
甘地进一步阐述了在思考无服务器功能如何运作方面的转变是至关重要的. 用与单片应用程序相同的方式考虑，将所有这些挑战移植到无服务器环境中. 他进一步阐述了模块化思维和优先级功能是客户端如何从无服务器技术中获得真正价值的.
Gandhi建议寻找能够真正利用无服务器功能的领域. 他还强调，选择合适的框架是必要的，因为它伴随着正确的工具来帮助改变思维.
Philip进一步阐述了从移动到无服务器的转变是如何带来灾难性后果的. 他强调需要关注业务逻辑. 然而, 许多公司已经拥有了单片应用, 利用无服务器技术的新应用程序仍然需要使用这些遗留应用程序. 因此，在这种情况下，一种混合方法是可行的.
观众的提问
问:你如何看到应用程序的各个部分以及它们正在做什么? 如果出了问题，您如何调试，以及您将从哪里查找?
Matt详细阐述了他们如何通过查看更多的图表来理解工作流程. 他谈到了一些工具，可以扫描你的AWS账户，并根据开发人员正在使用的应用程序绘制架构图.
然后他解释了阶跃函数, SQS, SNS队列帮助他们将工作流分解得更详细. LucidCharts或Visio等工具可以帮助绘制这些图表. 这有助于回顾他们是否在做他们应该做的事情，以及他们如何符合你的预期目标.
Philip谈到了使用一个单片应用程序性能管理工具(New Relic). 这个工具帮助他们了解应用程序的各个部分是如何实时运行的，以及它们是否具有预期的流程.
Matt进一步谈到了一个来自AWS的工具 控制塔 它允许您通过一次登录来管理对各种AWS服务的访问和帐户. 该服务有助于为开发人员建立沙盒环境. 即使在发生违约的情况下，它也限制了由于帐户隔离而造成的损害.
甘地进一步补充说，按功能建立团队，这样管理和监控服务更容易. 他还添加了正确框架的使用，例如 放大，它提供了正确的工具来管理和监控应用程序. 比如工具，比如 x光 帮助跟踪函数调用和每个阶段所花费的时间.
Q:虽然λ服务在基于事件的用例中工作得很好, 有哪些服务与微服务模式相关，比如断路器, clients-side发现, 等?
Matt谈到了使用step函数来实现这一点. 他描述了他们如何编写单独的λ函数来执行特定的任务，然后使用步骤函数将它们链接在一起来构建工作流. Gandhi进一步增加了API Gateway的使用来实现这些功能. 他谈到了在服务之间使用基于rest的通信. AWS AppMesh 是否还有另一个支持服务间通信的服务.
小组建议的其他资源:
无服务器和SaaS是决定性的匹配，Synerzip和AWS也是如此. Synerzip具有独特的定位，可以为各种垂直领域和用例设计和构建SaaS应用程序, 为公共和私人服务过, 初创和企业客户. 无服务器思维模式与SaaS模型相交叉，两者都使您的业务具有灵活性和敏捷性，从而具有成本效益并降低风险. 强大的AWS服务套件提供了一种平和的心态，可以让你放下运营组件，转而完全专注于推动盈利和增长. 作为高级层AWS咨询合作伙伴，提供无服务器SaaS交付专门化, Synerzip可以帮助您的应用程序实现更快的时间价值.
