官术网_书友最值得收藏!

The sweet spot

Since serverless systems work on the basis of a single function, they are well suited to problems that are, or can be broken down into, the following subsystems:

  • Stateless
  • Computationally small and predictable

Serverless functions are ephemeral; that is, they have a known lifetime. Computation that is itself stateless is the type of problem where FaaS platforms shine. Application state may exist, and functions may store that state using a database or some other kind of data store, but the functions themselves retain no state between invocations.

In terms of computing resources, serverless functions have an upper bound, both in memory and total duration. Your software should have an expected or predictable upper limit that is below that of your FaaS provider. At the time of writing, AWS Lambda functions have an upper bound of 1,536 MB for memory and 300 seconds in duration. Google Compute advertises an upper limit of 540 seconds. Regardless of the actual values, systems, where you can reliably play within these bounds, are good candidates for moving to serverless architecture.

A good, albeit trivial, an example of this would be a data transformation function—given some input data, transform it into a different data structure. It should be clear with such a simple example that no state needs to be or is carried between one invocation and the next. Of course, data comes in various sizes, but if your system is fed data of a predictable size, you should be able to process the data within a certain timeframe.

In contrast, long-running processes that share state are not good fits for serverless. The reason for this is that functions die at the end of their life, leaving any in-memory state to die with them. Imagine a long-running process such as an application server handling WebSocket connections.

WebSockets are, by definition, stateful and can be compared to a phone call—a client opens up a connection to a server that is kept open as long as the client would like. Scenarios such as this are not a good fit for serverless functions for the two following reasons:

  • State exists (i.e., state of a phone call is connected or disconnected)
  • The process is long-lived because the connection can remain open for hours or days

Whenever I approach a new problem and begin to consider serverless, I ask myself these two questions:

  • Is there any global state involved that needs to be kept track of within the application code?
  • Is the computation to be performed beyond the system limits of my serverless platform?

The good news is that, very often, the answer to these questions is no and I can move forward and build my application using a serverless architecture.

主站蜘蛛池模板: 青川县| 阿鲁科尔沁旗| 抚州市| 平武县| 浦北县| 贡山| 石景山区| 寿阳县| 贵州省| 安义县| 丰原市| 鄄城县| 墨江| 乐平市| 汶上县| 民乐县| 桓台县| 宁河县| 永兴县| 红河县| 鹤庆县| 阿瓦提县| 万安县| 南宁市| 安康市| 万全县| 苍南县| 吉林省| 彭泽县| 丹东市| 明光市| 莲花县| 靖宇县| 蚌埠市| 同江市| 宜章县| 留坝县| 通渭县| 河池市| 临高县| 麻城市|