aws一年免费_我们在生产周期中使用AWS Lambda超过一年的经验

aws一年免费

Over the last few years, serverless approaches have gained decent traction in the web app designing, developing and implementing sectors. In the early days, many engineers treated serverless just like another hype. Still, almost all of those who tried to use it had to admit that the technology turned out to be as good as traditional and standalone virtual machines for hosting web-applications.

在过去的几年中，无服务器方法在Web应用程序的设计，开发和实施部门中获得了广泛的关注。 早期，许多工程师将无服务器视为另一个炒作。 尽管如此，几乎所有尝试使用它的人都不得不承认，该技术与托管Web应用程序的传统和独立虚拟机一样好。

To date, we can see that startups tend to utilize serverless technology stack as a part of their systems or even as their primary solution for building products in different domains.

迄今为止，我们可以看到，初创企业倾向于将无服务器技术堆栈用作其系统的一部分，甚至将其用作在不同领域构建产品的主要解决方案。

第一件事 (First things first)

Our team decided to test out the technology while working on the product during the last year — an on-demand bike taxi app that uses a serverless approach for one of its components. In fact, it is much similar to an Uber app.

我们的团队决定在去年使用该产品时对这项技术进行测试，这是一种按需自行车出租车应用程序，该应用程序的其中一个组件使用了无服务器方法。 实际上，它与Uber应用程序非常相似。

Technically, it was mostly a REST API and cron-tasks, anchored by the following technologies (all of these are provided by the Amazon Web Services):

从技术上讲，它主要是一种REST API和cron任务，并由以下技术所锚定(所有这些技术均由Amazon Web Services提供)：

• API Gateway as a platform for API management.
  API网关作为API管理的平台。
• CloudWatch Rules for scheduling cron-tasks.
  用于计划cron任务的CloudWatch规则。
• Lambdas as computing units.
  Lambda作为计算单位。
• S3 buckets to store static files.
  S3存储桶用于存储静态文件。
• CloudWatch Logs with Logs Insights for log management.
  带有Logs Insights的CloudWatch Logs用于日志管理。
• Tools for continuous integration and deployment of our application: AWS CodeBuild, AWS CodePipeline and AWS CodeDeploy.
  用于持续集成和部署应用程序的工具：AWS CodeBuild，AWS CodePipeline和AWS CodeDeploy。

Initially, we used Node.js version 10 to write the code (a few months ago it was upgraded to version 12 without any issues). And all the infrastructure part (I mean all the AWS objects descriptions) is created and managed by an open-source Serverless Framework.

最初，我们使用Node.js版本10编写代码(几个月前，它已升级到版本12，没有任何问题)。 所有基础架构部分(我的意思是所有AWS对象描述)都是由开源无服务器框架创建和管理的。

*This guide is not about AWS, FaaS (Function as a Service) or Serverless framework, since there is a lot of such content on the Internet. Here you will only find the things that our team faced during the development and after-launch stages. This info might be helpful if you come up with doubts about which technology to adopt for your next project. *

*本指南与AWS，FaaS(功能即服务)或无服务器框架无关，因为Internet上有很多此类内容。 在这里，您仅能找到我们团队在开发和发布后阶段所面临的事情。 如果您对下一个项目采用哪种技术有疑问，此信息可能会有所帮助。 *

无服务器世界-使用AWS Lambdas的显着优势 (The Serverless world — the remarkable benefits of using AWS Lambdas)

Let’s start with the good parts! No matter what any hater says, the Serverless world provides a bunch of excellent features that you cannot achieve in any other way under equal conditions.

让我们从好零件开始！ 不管讨厌什么，无服务器世界提供了许多出色的功能，在相同条件下您无法以任何其他方式实现。

When we started this project mostly from scratch, it didn’t require any severe capacity in measurements of Memory, CPU or network, to name a few. The same statement can be made not only about the development phase but also about the Staging, QA and Pre-Prod environments.

当我们主要从头开始这个项目时，仅举几个例子，它不需要任何大容量的内存，CPU或网络测量。 对于开发阶段，也可以对登台，QA和Pre-Prod环境作出相同的陈述。

Traditionally, we need four servers, whether that be virtual machines, docker containers or any other platforms where we can host servers. For sure, it might be quite expensive to keep and maintain servers, even small and low-power ones. Even switching them off at nights and weekends is no way an option.

传统上，我们需要四个服务器，无论是虚拟机，docker容器还是我们可以托管服务器的任何其他平台。 当然，维护和维护服务器，甚至小型和低功耗的服务器，可能都非常昂贵。 即使在晚上和周末将其关闭也不可行。

However, the Serverless world has an alternative solution — the so-called “Pay as you go” payment approach. It means that you pay only for the computing resources and network load that you use, even though the entire infrastructure is deployed and accessible at any moment.

但是，无服务器世界有另一种解决方案-所谓的“随用随付”付款方式。 这意味着即使整个基础架构随时可以部署和访问，您也只需为使用的计算资源和网络负载付费。

In practice, it means that we were not burdened with any cost savings during the project’s development. Moreover, while we remained within the AWS Free Tier limits, the actual cloud usage was charge-free until we reached the production stage.

实际上，这意味着我们在项目开发过程中不会节省任何成本。 此外，虽然我们仍处于AWS Free Tier限制之内，但实际的云使用量是免费的，直到我们进入生产阶段。

So here are some advantages of AWS Lambdas worth mentioning here.

因此，这里有一些值得一提的AWS Lambdas优势。

出色的可扩展性 (Outstanding scalability)

The app was designed for the city with more than 13 million people. So it’s no wonder that the number of users started snowballing right after the first release. By “snowballing”, I mean thousands of new users per hour in the first few weeks, hence a bunch of rides and ride requests as well.

该应用程序是为拥有超过1300万人的城市而设计的。 因此也就不足为奇了，用户数量在第一个版本发布后就开始滚雪球。 所谓“滚雪球”，是指在开始的几周中每小时有成千上万的新用户，因此也有很多乘车和乘车要求。

That’s where we felt all the benefits of the AWS Lambdas’ incredible scalability and zero management of the scaling process. You know, this feeling when you see a rapidly growing number of requests on the chart (that was automatically provided by AWS). And the greatest part is that you shouldn’t even worry about this, since the AWS Lambdas are scaled automatically. All you have to do is set a threshold for the concurrent invocation.

那就是我们感受到AWS Lambdas令人难以置信的可扩展性和扩展过程的零管理的所有好处的地方。 您知道，当您在图表上看到快速增长的请求(由AWS自动提供)时，就会有这种感觉。 最重要的是，您甚至不必担心此事，因为AWS Lambda会自动缩放。 您要做的就是为并发调用设置一个阈值。

标准的监视和记录工具集 (A standard set of monitoring and logging tools)

Aside from the automatic scalability feature, AWS provides a basic set of tools for Lambdas. So, you don’t have to waste your precious time dealing with the annoying configuration of basic monitoring metrics, such as Memory Usage, Execution time or Errors Count.

除了自动可伸缩性功能之外，AWS还为Lambda提供了一组基本工具。 因此，您不必浪费宝贵的时间来处理烦人的基本监视指标配置，例如内存使用，执行时间或错误计数。

Moreover, you can customize your own dashboards in the CloudWatch service that would help you track performance issues and execution errors throughout the entire serverless application.

此外，您可以在CloudWatch服务中自定义自己的仪表板，这将帮助您在整个无服务器应用程序中跟踪性能问题和执行错误。

For sure, you won’t come up with as many customizable graphics options, as Grafana or Kibana can provide, but at the same time, the AWS CloudWatch metrics, alarms and dashboards are way cheaper. Besides, you can attune these without much preparation, and last but not least — the cloud provider takes responsibility for the efficiency of the monitoring tools described above.

当然，您不会像Grafana或Kibana那样提供尽可能多的可自定义图形选项，但同时，AWS CloudWatch指标，警报和仪表板更便宜。 此外，您无需进行太多准备就可以调优这些功能，最后但并非最不重要的一点是-云提供商对上述监视工具的效率负责。

隔离环境 (Isolated environment)

Well, let’s say you managed to customize a dashboard without any problems. But then you realized that the Lambdas execution process took more time than it should have, and it looked like Lambdas performed some sophisticated calculation. Luckily, it’s not a problem for AWS Lambda, since every function-handler runs in an isolated environment, with its own configuration system of Memory or CPU.

好吧，假设您成功地自定义了仪表板，没有任何问题。 但是随后您意识到Lambdas执行过程花费的时间超出了原本应有的时间，而且看起来Lambdas执行了一些复杂的计算。 幸运的是，对于AWS Lambda而言，这不是问题，因为每个函数处理程序都在具有其自己的内存或CPU配置系统的隔离环境中运行。

In-fact, each instance of Lambda is a separate AWS Firecracker Container that spawns on a trigger (in case of a REST API, the trigger is an HTTP request). That said, all you have to do is just increase CPU units Count or Memory for the specific Lambda, with no need for global updates, as if it were done in a classic server.

实际上，每个Lambda实例都是一个单独的AWS Firecracker容器，该容器会在触发器上生成(对于REST API，触发器是HTTP请求)。 就是说，您要做的只是增加特定Lambda的CPU单位计数或内存，而无需进行全局更新，就像在经典服务器中完成的一样。

灵活的错误管理 (Flexible errors management)

Another outstanding benefit that you can enjoy while using AWS Lambda is decent error handling.

使用AWS Lambda时，您可以享受的另一个显着优势是体面的错误处理。

As said above, each Lambda has an isolated environment, so even if one of your Lambda instances fails for any reason, all other Lambdas will continue to operate normally. It’s fantastic when you have just one or two errors from a few hundred possible AWS Lambda invocations, isn’t it?

如上所述，每个Lambda都有一个隔离的环境，因此，即使您的Lambda实例之一由于任何原因而失败，所有其他Lambda都将继续正常运行。 当数百个可能的AWS Lambda调用中只有一个或两个错误时，这真是太好了，不是吗？

自动重试尝试 (Automated retry attempts)

Furthermore, retry attempts is another out-of-the-box feature that AWS provides. Should a Lambda fail for any reason, it would be automatically re-invoked with the same event payload during the pre-configured period. I must say, it’s a quite useful feature if your Lambda is invoked by schedule and is trying to send a request to a third party resource that can be unavailable.

此外，重试尝试是AWS提供的另一种现成功能。 如果Lambda出于任何原因失败，它将在预先配置的期间内使用相同的事件有效负载自动重新调用。 我必须说，如果按计划调用您的Lambda并试图将请求发送到可能不可用的第三方资源，则这是一个非常有用的功能。

Finally, AWS Lambda supports the Dead letter queue concept that means you can acquire relevant notifications and tracking information about failed Lambdas.

最后，AWS Lambda支持死信队列概念，这意味着您可以获取有关失败Lambda的相关通知和跟踪信息。

AWS Lambda的缺点-需要学习的一些痛点 (The AWS Lambda disadvantages — a few pain points to learn from)

On the flip side of the coin, AWS Lambda and the serverless concept are not entirely perfect yet and have enough unresolved problems and pitfalls that make the development and support processes a little bit harder.

不利的一面是，AWS Lambda和无服务器概念还不是很完美，并且有很多未解决的问题和陷阱，使开发和支持流程更加困难。

持续时间限制 (Duration limits)

For our project, it was all about limits. For example, we ended up with an execution duration limit — a Lambda can be performed within 15 minutes maximum. Moreover, if a trigger is requested from an API Gateway, the duration must be no more than 30 seconds.

对于我们的项目，一切都与极限有关。 例如，我们最终受到执行持续时间的限制-Lambda最多可以在15分钟内执行。 此外，如果从API网关请求触发，则持续时间不得超过30秒。

Perhaps, we could accept such limits for the API, but a 15-minutes limit for the cron-tasks was way too tight to execute the particular scope of tasks on time. That said, since the computed intensive tasks couldn’t be invoked with Lambdas, we had to create a separate server specifically for long-running tasks.

也许，我们可以接受API的此类限制，但是cron任务的15分钟限制太紧，无法按时执行特定任务范围。 就是说，由于无法使用Lambdas调用计算密集型任务，因此我们必须创建一个单独的服务器专门用于长时间运行的任务。

CloudFormation部署限制 (CloudFormation deployment limitations)

Another significant issue we faced was the Lambda deployment via CloudFormation (the AWS service for infrastructure and deployment). At the very beginning of the project, everything was fine. Still, when the number of Lambdas mushroomed into more than 30 CloudFormations, the stack started failing with different errors like “Number of resources exceeded”, “Number of outputs exceeded”.

我们面临的另一个重要问题是通过CloudFormation(用于基础结构和部署的AWS服务)进行Lambda部署。 在项目的开始，一切都很好。 但是，当Lambda的数量猛增到30个以上的CloudFormation时，堆栈开始失败，并出现诸如“超出资源数量”，“超过输出数量”之类的错误。

Thankfully, the Serverless framework and its plugins helped us to tackle this issue early on. There are also a few other ways to solve such kinds of problems, but that’ll be a topic for another article.

幸运的是，无服务器框架及其插件帮助我们尽早解决了此问题。 还有其他几种方法可以解决此类问题，但这将是另一篇文章的主题。

无法扩展监视和调试工具集 (Failure to expand monitoring and debugging toolset)

Even though AWS provides some basic level of monitoring and debugging, it’s still impossible to extend this part and make some custom metrics that could be useful for particular cases and projects. This time around, we had to use third-party services that you usually need to integrate as libraries into your code to be able to monitor some specific stuff.

尽管AWS提供了一些基本的监视和调试级别，但是仍然不可能扩展此部分并制定一些自定义指标，这些指标对于特定情况和项目可能很有用。 这次，我们不得不使用第三方服务，您通常需要将这些第三方服务作为库集成到您的代码中，以便能够监视某些特定内容。

As mentioned above, each Lambda instance is in-fact a tiny Firecracker Container with some basic runtime environment, libraries and your code. It’s created temporarily to process any event evoked by the triggers. It’s a well-known fact that creating a container or running an executable environment and code takes some operational time called a cold start.

如上所述，每个Lambda实例实际上是一个很小的Firecracker容器，其中包含一些基本的运行时环境，库和您的代码。 它是临时创建的，用于处理触发器触发的任何事件。 一个众所周知的事实是，创建一个容器或运行一个可执行的环境和代码需要一些操作时间，称为冷启动。

It can take random time between 100 milliseconds to a few minutes. Moreover, if you keep your Lambdas under VPC (Virtual Private Cloud), cold starts will take more time because the system will have to create additional resources for each Lambda, called Elastic Network Interfaces.

这可能需要100毫秒到几分钟之间的随机时间。 此外，如果将Lambda保留在VPC(虚拟私有云)下，则冷启动将花费更多时间，因为系统将必须为每个Lambda创建称为弹性网络接口的其他资源。

This, in turn, results in annoying delays, so the end-users have to wait for the app to respond, which is definitely not good at all, isn’t it? The workaround here is to ping your Lambda every 5 minutes to keep containers “warm”. The AWS system is smart enough and doesn’t kill Lambdas containers immediately, since it is based on the concept that triggers would keep spawning new events.

反过来，这会导致令人讨厌的延迟，因此最终用户必须等待应用程序响应，这绝对是不好的，不是吗？ 解决方法是每5分钟ping您的Lambda以保持容器“温暖”。 AWS系统足够聪明，不会立即杀死Lambdas容器，因为它基于触发器将不断产生新事件的概念。

数据库连接陷阱 (Database connection pitfalls)

In view of the above, it’s problematic to manage a database connection for such a system. You cannot just open a connection pool to your MongoDB or MySQL servers at the application startup phase and reuse it during the entire lifecycle.

鉴于上述情况，为这样的系统管理数据库连接是有问题的。 您不能仅在应用程序启动阶段打开与MongoDB或MySQL服务器的连接池，并在整个生命周期内重复使用它。

So there are at least two ways to manage connections:

因此，至少有两种方法可以管理连接：

You should open a connection for each Lambda invocation and close it after your code with logic would be completed; You can try to reuse a connection and keep it in the Lambda memory as a reference in code or field in context — it allows you to keep a connection within the same Lambda containers till closing.

您应该为每个Lambda调用打开一个连接，并在逻辑代码完成后关闭该连接。 您可以尝试重用连接并将其保留在Lambda内存中，以作为上下文中代码或字段的引用—它使您可以将连接保留在同一Lambda容器中，直到关闭为止。

However, both have their own limitations. In the first case, we end up with additional delays since we have to open a connection for each Lambda call. In the second case, we can’t be sure for how long Lambda would keep a connection, and consequently — we can’t handle a connection shut-down properly.

但是，两者都有其自身的局限性。 在第一种情况下，由于必须为每个Lambda调用打开连接，因此最终会导致额外的延迟。 在第二种情况下，我们无法确定Lambda将保持连接多长时间，因此，我们无法正确处理连接关闭。

本地测试限制 (Local test limitations)

Besides, the serverless apps are hard to test locally, because usually there are a lot of integrations between AWS services, like Lambdas, S3 buckets, DynamoDB, etc. For any type of local testing, developers must mock all this stuff, which usually is a formidable and time-consuming task.

此外，无服务器应用程序很难在本地测试，因为通常在AWS服务之间有很多集成，例如Lambda，S3存储桶，DynamoDB等。对于任何类型的本地测试，开发人员都必须模拟所有这些东西，通常是一项艰巨而费时的任务。

无法以传统方式采用缓存 (Inability to adopt caching in a traditional way)

On top of everything else, you can’t implement a traditional caching for classic-like servers. Usually, you have to use other services like S3, DynamoDB or ElasticCache (de-facto Redis hosted on AWS) to keep Lambda’s state or cache some data between AWS Lambda invocations.

最重要的是，您无法为经典服务器实现传统的缓存。 通常，您必须使用其他服务，例如S3，DynamoDB或ElasticCache(AWS上托管的事实上的Redis)来保持Lambda的状态或在AWS Lambda调用之间缓存某些数据。

In most cases, it results in extra costs of the entire infrastructure. Not to mention additional operational overhead — you’ll have to put and fetch cached data from remote storage, which, in turn, can slow down the performance of your cache.

在大多数情况下，这会导致整个基础架构的额外成本。 更不用说额外的操作开销了–您必须从远程存储中放入和获取缓存的数据，这反过来又会降低缓存的性能。

复杂的付款模式 (Complex payment model)

The last one worth mentioning is a sophisticated price calculation. Even though AWS Lambda is quite cheap, various supplementary elements can significantly increase the total costs. People tend to think that the pricing for using the AWS Lambda’s API is based on its computing resources and duration of code execution. In fact, you should keep in mind that you’ll have to pay for additional services, such as:

最后一个值得一提的是复杂的价格计算。 即使AWS Lambda相当便宜，各种补充元素也会大大增加总成本。 人们倾向于认为使用AWS Lambda API的价格是基于其计算资源和代码执行时间的。 实际上，您应该记住，您将需要支付额外的服务费用，例如：

• Network traffic,
  网络流量，
• API Gateway,
  API网关，
• Logs stored in the CloudWatch.
  存储在CloudWatch中的日志。

结语 (Wrapping up)

Summarizing the above, I want to say that the AWS serverless approach is a great way to strengthen your development practices. Nevertheless, you have to keep in mind that it’s quite different from traditional servers.

总结以上内容，我想说的是，AWS无服务器方法是加强开发实践的好方法。 但是，您必须记住，它与传统服务器完全不同。

To leverage the life-changing benefits of this technology, you have to get acquainted with all the subtleties and pitfalls in the first place. Besides, you also have to think through the architecture and its specifics for your particular solution.

为了充分利用这项技术带来的改变生活的好处，您首先必须熟悉所有的微妙之处和陷阱。 此外，您还必须为您的特定解决方案考虑体系结构及其细节。

Otherwise, the serverless approach can bring you rather problems than beneficial features as of insufficient educational background.

否则，由于教育背景不足，无服务器方法可能会给您带来很多问题，而不是有益的功能。

Originally published at https://brocoders.com.

最初发布在https://brocoders.com上。

翻译自: https://medium.com/brocoders-team/what-we-have-learned-while-using-aws-lambda-in-our-production-cycles-for-more-than-one-year-dbf79faa441b

aws一年免费