企业级无服务器工具

This is the first section of the series on Enterprise Serverless; specifically covering tooling. You can read the ideas behind the series by clicking on the ‘Series Introduction’ link below.

这是有关Enterprise Serverless系列的第一部分。 特别涉及工具 。 您可以通过点击下面的“ 系列介绍 ”链接来阅读系列背后的想法。

The series is split over the following sections:

该系列分为以下几节：

1. Series Introduction 🚀

   系列介绍 🚀

2. Tooling 🚀

   工具 🚀

3. Architecture 🚀

   建筑 🚀

4. Hints & Tips 🚀

   提示和技巧 🚀

5. AWS Limits & Limitations 🚀

   AWS限制与限制 🚀

6. Security 🚀

   安全 🚀

7. Useful Resources 🚀

   有用的资源 🚀

工具🤖 (Tooling 🤖)

When architecting or developing in the serverless World there are various things to consider when starting out on a new project. I have covered some of the high level key areas below, as well as some of the tools that I have personally found useful.

在无服务器世界中进行架构设计或开发时，开始新项目时需要考虑多种因素。 我已经介绍了下面的一些高级关键领域，以及一些我个人认为有用的工具。

1. Serverless vs SAM vs CDK vs Terraform vs Others
   无服务器vs SAM vs CDK vs Terraform vs其他
2. Serverless Plugins
   无服务器插件
3. Monorepo or Monorep-no!
   Monorepo或Monorep-否！
4. Webpack, Babel & TypeScript
   Webpack，Babel和TypeScript
5. Local Development vs AWS Ephemeral environments
   本地开发与AWS临时环境
6. CI/CD from day one
   从第一天开始CI / CD

无服务器vs SAM vs CDK vs Terraform vs其他 (Serverless vs SAM vs CDK vs Terraform vs Others)

One of the first tooling considerations when starting a new serverless project is the framework you choose for your IaC (Infrastructure as Code), with various offerings to choose from. In my opinion the most mature is the Serverless Framework which I have now used on multiple large projects, which has a plethora of additional plugins created by the community. Amazon has since created SAM and the CDK, both of which are less mature but fantastic offerings, and essentially most frameworks generate CloudFormation at their core. Terraform is a considered alternative, however in my experience the need for multi-cloud is rare, unless you have the governance around this as a feature, for example some banks. Ultimately the important thing here is use the tool which fits your company, strategy and existing skillsets. This is a great link which shows the comparisons between the various providers https://www.serverless.com/learn/comparisons/

启动新的无服务器项目时，首先要考虑的工具因素是为IaC选择的框架( 基础架构即代码 )，并提供多种选择。 在我看来，最成熟的是我现在已在多个大型项目中使用的无服务器框架 ，该框架具有由社区创建的大量其他插件。 从那以后，亚马逊创建了SAM和CDK ，它们都不那么成熟，但是功能强大，基本上，大多数框架都以CloudFormation为核心。 Terraform被认为是替代方案，但是根据我的经验，对多云的需求很少，除非您具有围绕此功能的治理功能，例如某些银行。 最终，这里最重要的是使用适合您公司，战略和现有技能的工具。 这是一个很棒的链接，显示了各个提供商之间的比较https://www.serverless.com/learn/comparisons/

无服务器插件 (Serverless Plugins)

Having used the Serverless Framework as my go to tool for describing, configuring and deploying my infrastructure, there are a number of Serverless Plugins which I have found extremely useful on enterprise serverless projects (covering full-stack):

使用无服务器框架作为我描述，配置和部署基础架构的工具之后，有许多无服务器插件对企业无服务器项目( 覆盖全栈 )非常有用：

🔘 serverless-plugin-split-stacksAs soon as an AWS serverless project grows you will no doubt hit the dreaded CloudFormation 200 resource max limit (a nightmare for DevOps 👻). This configurable plugin allows the team to split the CloudFormation into nested stacks to get around this limitation, and in my opinion is a great addition at the start of a project in readiness.

🔘serverless -plugin-split-stacks一旦AWSless serverless项目发展，您无疑将达到可怕的CloudFormation 200资源最大限制( DevOps的噩梦 )。 这个可配置的插件使团队可以将CloudFormation拆分为嵌套堆栈来解决此限制，并且我认为这是在项目开始时准备就绪的一个很好的补充。

🔘 serverless-s3-deployThis plugin is fantastic for deploying files and resources to S3 as part of the infrastructure, for example, my teams have used it in the past for deploying email templates, configuration files and assets.

less serverless -s3-deploy此插件非常适合将文件和资源作为基础结构的一部分部署到S3，例如，我的团队过去曾使用它来部署电子邮件模板，配置文件和资产。

🔘 serverless-s3-removerWhen working with ephemeral environments it is sometimes necessary to clear an S3 bucket before tearing down the environment.

🔘serverless -s3-remover在临时环境中工作时，有时必须在拆除环境之前清除S3存储桶。

🔘 serverless-plugin-aws-alertsWhen you have a large amount of lambda functions it is imperative that you understand some of the key metrics such as invocations, throttling, errors and duration, and when the service is running outside of ‘normal’. This serverless plugin by the team at A Cloud Guru allows you to quickly add CloudWatch alarms to all of your lambdas with configurable thresholds; proactively emailing or messaging your ops team to make them aware of issues.

less serverless -plugin-aws- alerts当您拥有大量的lambda函数时，必须了解一些关键指标，例如调用，限制，错误和持续时间，以及服务在“正常”范围之外运行。 这个由A Cloud Guru团队开发的无服务器插件，使您可以通过可配置的阈值将CloudWatch警报快速添加到所有lambda。 主动通过电子邮件或消息通知您的运营团队，以使他们意识到问题。

🔘 serverless-appsync-pluginBy far my favourite serverless plugin at the moment, allowing a team to quickly spin up an AWS AppSync GraphQL API, including configuring VTL, authentication, data sources, resolvers, caching and more.

less serverless -appsync-plugin到目前为止，我最喜欢的无服务器插件，使团队可以快速启动AWS AppSync GraphQL API，包括配置VTL，身份验证，数据源，解析器，缓存等。

🔘 serverless-finchThis plugin is great for deploying built client apps such as React front ends, allowing you to quickly host in S3 as a source for CloudFlare or CloudFront for example.

less serverless -finch此插件非常适合部署内置的客户端应用程序(例如React前端)，使您可以快速将S3托管为CloudFlare或CloudFront的源。

🔘 serverless-step-functionsIf you are working with AWS Step Functions this plugin is great at allowing you to quickly define your workflows and deploy them using Serverless.

🔘serverless -step-functions如果您使用的是AWS Step Functions，则此插件非常适合您快速定义工作流程并使用Serverless进行部署。

Monorepo或Monorep-否！ (Monorepo or Monorep-no!)

A key consideration when setting up the initial project structure around an enterprise serverless project is how to split up the various deployable services that make up the overall application, and managing their dependencies.

在围绕企业级无服务器项目设置初始项目结构时，一个主要的考虑因素是如何拆分组成整个应用程序的各种可部署服务，并管理它们之间的依赖关系。

These assets could be APIs, workflows, mobile, clients, schedulers, databases, search engines, and more..

这些资产可能是API，工作流，移动设备，客户端，调度程序，数据库，搜索引擎等。

💡 A great way of deploying non serverless resources such as AWS DocumentDB, VPCs or Elasticsearch is with the Serverless Framework, as anything in the ‘resources’ section will deploy as normal CloudFormation. This is a great way of using the features of the CLI for all of your cloud assets — allowing you to deploy them using the ‘sls deploy’ command as you normally would.

less部署非无服务器资源(如AWS DocumentDB，VPC或Elasticsearch)的一种好方法是使用无服务器框架，因为“资源”部分中的任何内容都将作为常规CloudFormation进行部署。 这是对所有云资产使用CLI功能的好方法-允许您像平时一样使用'sls deploy'命令进行部署。

In my experience you very quickly find that you need shared resources between key projects, and the use of a Monorepo such as Lerna cleanly facilitates this whilst reducing the headache of versioning, publishing, and managing packages/dependencies.

以我的经验，您很快就会发现需要在关键项目之间共享资源，而使用Lerna之类的Monorepo可以轻松地实现这一点，同时减轻了版本控制，发布和管理软件包/依赖项的麻烦。

Examples of the shared resources could be i18n translation files, shared regexes, error types, shared functions and packages such as loggers, service integrations and utils. Having used Lerna in current large scale projects I could not imagine going back to managing these resources manually, and it’s saved our teams a lot of headaches. There are certainly some small quirks with Lerna, but they are small and hit few and far between.

共享资源的示例可以是i18n转换文件，共享正则表达式，错误类型，共享功能和包，例如记录器，服务集成和实用程序。 在当前的大型项目中使用Lerna时，我无法想象会回到手动管理这些资源，这为我们的团队省去了很多麻烦。 莱娜(Lerna)当然有一些小怪癖，但它们很小，而且命中率极低。

Webpack，Babel和TypeScript (Webpack, Babel & TypeScript)

A key consideration when working with JavaScript on a large scale serverless project is the use of tools such as Webpack, Parcel, Babel, and TypeScript for building and/or transpiling JavaScript modules. When working with lambda for example, minification and tree shaking has a direct correlation on performance and cold starts due to overall file size, and building as one file to prevent filesystem reads on required modules (hat tip Yan Cui). When working with these tools alongside the Serverless Framework there are a number of great plugins such as Serverless Webpack.

在大型无服务器项目上使用JavaScript时，主要考虑因素是使用Webpack ， Parcel ， Babel和TypeScript之类的工具来构建和/或转译JavaScript模块。 例如，在使用lambda时，最小化和树状摇动与性能和冷启动有直接关系，这归因于整个文件的大小，并且将其构建为一个文件以防止文件系统在必需的模块上读取( 帽提示 Yan Cui )。 与Serverless Framework一起使用这些工具时，有许多很棒的插件，例如Serverless Webpack 。

本地开发与AWS临时环境 (Local Development vs AWS Ephemeral environments)

An area which I have focused on in the past is around the benefits of development teams working locally vs working with deployed services on AWS natively.

我过去重点关注的领域是开发团队在本地工作与在AWS上本地处理已部署服务之间的收益。

There are various tools such as LocalStack and Serverless Offline which simulate the use of AWS locally through the use of containers; however they have various drawbacks such as the amount of setup time and configuration to integrate into the solution, they are constantly out of date due to the pace AWS build new features, they typically don’t mimic real World issues that you face natively, and typically don’t have the full set of features and integrations that you are likely to need (now or in the future as requirements change).

有多种工具，例如LocalStack和Serverless Offline ，可通过使用容器在本地模拟AWS的使用。 但是它们具有各种缺点，例如集成到解决方案中的设置时间和配置时间长，由于AWS建立新功能的步伐而不断过时，它们通常不会模仿您本机面临的现实问题，并且通常并没有您可能需要的全部功能和集成( 现在或将来随着需求的变化 )。

The alternative is for developers to deploy, test and work with their code directly on AWS, which doesn’t suffer from the issues listed above. The argument about cost is a non starter in my opinion as it is so cheap to run development workloads, and far outweighs the development costs of integrating and maintaining a local solution.

另一种选择是让开发人员直接在AWS上部署，测试和使用其代码，而不会遇到上述问题。 在我看来，关于成本的争论不是一个开始，因为运行开发工作负载非常便宜，并且远远超过集成和维护本地解决方案的开发成本。

A key area to focus on here in my opinion are ephemeral environments created through CI/CD pipelines based off the creation of a pull request by a developer, which has worked fantastically well for teams I have worked with in the past (just as long as the deployment process is quick and it has a fast feedback loop for issues)

一个主要领域集中在这里在我看来，通过基于关闭的开发商，已经工作飞驰很好的球队，我已经在过去的工作( 只要你将建立一个拉请求CI / CD管道创建短命环境部署过程很快，并且有快速的问题反馈循环 )

The only negative I have personally for this approach is debugging in the cloud is still not great! With most of the serverless frameworks you can fire the lambda through the CLI with an event payload, but gaining access to the logs is still not great.

我个人对此方法唯一的缺点是在云中调试仍然不是很好！ 使用大多数无服务器框架，您可以使用事件有效负载通过CLI触发lambda，但是获得对日志的访问权限仍然不是很好。

从第一天开始CI / CD (CI/CD from day one)

When starting new serverless projects it is imperative in my opinion that CI/CD is a key focus and carefully considered and planned up front, as it is very difficult to plug in later, and if dev and test are working against AWS through ephemeral environments this needs to work for the team from the outset. A benefit of frameworks such as Serverless and SAM is their accompanying CLIs which make the deploying aspects of the pipeline a breeze, especially with Serverless and Lerna together. In one command you can quickly deploy all code and infrastructure (as well as additional infrastructure added in the resources section).

在我启动新的无服务器项目时，我认为CI / CD是一个重点，并且必须事先进行仔细考虑和计划，因为以后很难插入，并且如果开发和测试正在通过临时环境与AWS进行协作，需要从一开始就为团队工作。 诸如Serverless和SAM之类的框架的优点是它们附带的CLI，这使管道的部署方面轻而易举，尤其是与Serverless和Lerna一起使用时。 在一个命令中，您可以快速部署所有代码和基础结构( 以及在资源部分中添加的其他基础结构 )。

There are obviously different strategies you could take when deploying your code, however for me personally when using Lerna with serverless it makes sense to deploy monolithically, so you have a quick feedback loop for breaking changes, rather than deploying the services only when they change.

部署代码时显然可以采取不同的策略，但是对我个人而言，将Lerna与无服务器一起使用是有意义的整体部署，因此您有一个快速的反馈循环来打破更改，而不是仅在服务更改时进行部署。

Although this could be covered in a separate post, some of the key activities I personally like to see in a pipeline (and not limited too)to benefit the full team are:

尽管这可以在单独的文章中介绍，但我个人希望在管道中看到的(但不仅限于 )一些使整个团队受益的关键活动是：

1. Unit Tests (e.g. Jest)

   单元测试( 例如笑话 )

2. Code quality analysis (e.g. SonarCloud)

   代码质量分析( 例如SonarCloud )

3. Dependency Checks (Audit.JS/Snyx/OWASP)

   依赖性检查( Audit.JS / Snyx / OWASP )

4. API Tests (Postman/Newman/SOAP UI)

   API测试( Postman / Newman / SOAP UI )

5. Front end tests (Selenium/Cypress/Cross browser testing etc)

   前端测试( Selenium/赛普拉斯/跨浏览器测试等 )

💡 Tools such as commitlint, commitizen, husky, pretty-quick and prettier can be used together to quickly perform checks, linting and enforce standards at commit time before even running the pipeline.

commit诸如commitlint，commitizen，husky，pretty-quick和prettier之类的工具可以一起使用，以在提交时甚至在运行管道之前快速执行检查，整理和强制执行标准。

Next section: Architecture 🚀Previous section: Series Introduction 🚀

下一节： 体系结构 🚀 上一节 ： 系列介绍 🚀

结语 (Wrapping up)

Feel free to also connect with me on:

请随时与我联系：

https://www.linkedin.com/in/lee-james-gilmore/https://twitter.com/LeeJamesGilmore

https://www.linkedin.com/in/lee-james-gilmore/ https://twitter.com/LeeJamesGilmore

If you enjoyed the posts please follow my profile Lee James Gilmore for further posts/series, and don’t forget to connect and say Hi 👋

如果您喜欢这些帖子，请关注我的个人资料Lee James Gilmore，以获取更多帖子/系列，并且别忘了联系并说声嗨 👋

关于我 (About me)

“Hi, I’m Lee, an AWS certified technical architect and polyglot software engineer based in the UK, working for a FTSE 100 multinational enterprise software company, working primarily in full-stack JavaScript on AWS for the past 5 years.

“ 嗨，我是Lee，他是英国AWS认证的技术架构师和多语种软件工程师，在FTSE 100跨国企业软件公司工作，过去5年主要在AWS上使用全栈JavaScript。

I consider myself a serverless evangelist with a love of all things AWS, innovation, software architecture and technology.”

我认为自己是一位无服务器的传播者，热爱AWS，创新，软件架构和技术。 ”

** The information provided are my own personal views and I accept no responsibility on the use of the information.

** 所提供的信息是我个人的观点，我对信息的使用不承担任何责任 。

翻译自: https://medium.com/swlh/enterprise-serverless-tooling-aa2b84d932de