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

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.

主站蜘蛛池模板: 上虞市| 天津市| 禄劝| 镇坪县| 丁青县| 称多县| 承德县| 桓仁| 鄢陵县| 汉寿县| 东安县| 昌江| 临颍县| 隆安县| 陆丰市| 博爱县| 镇原县| 泸水县| 商河县| 香港 | 土默特左旗| 灵武市| 盈江县| 仁怀市| 江西省| 井陉县| 昭苏县| 浏阳市| 乌拉特前旗| 朝阳县| 张家港市| 上高县| 梁河县| 承德市| 育儿| 元江| 天柱县| 株洲市| 泸州市| 文成县| 三门县|