Architectural models for building code, known as design models, act as essential models for developers. When considering serverless computing, developers naturally flock to serverless design patterns.
But before sifting through the suggested architecture models, developers should think about two key questions:
- What is the nature of your serverless application?
- In which serverless framework, or frameworks, do you expect to work?
Serverless application type and provider
The first thing to do is to determine the type of serverless application needed and the best provider to host it.
Serverless computing runs code components called microservices, functions, or lambdas. Let’s use functions, the most generic term, to reduce the confusion. Typical serverless applications are either an event management application or a front-end web application.
In an event management application, externally or internally generated events trigger the execution of serverless functions. In a front-end web application, a user triggers a function through a browser or interaction with a mobile application. Developers need to know which model they will follow before choosing their serverless design models.
The app’s serverless platform is also key. Although there are general rules for constructing serverless functions, the specific technique should accommodate the serverless framework. provided by cloud provider. This is especially important if you plan to use a cloud provider’s workflow creation orchestration tools, such as AWS Step Functions, Microsoft Azure Logic Apps, or any number of workflow techniques. similar available in Google Cloud Platform. If you have a preferred cloud provider, consider how your serverless application would map to it.
Design templates for event management applications
For event management applications, a basic design template usually has a simple name, such as the event application template. This type of model should assume that a single event triggers the execution of a serverless function and that no further events will be generated or that the processing of one event will selectively trigger another. This event can occur externally, generated by something like an IoT sensor, or it can occur because a cloud web service has queued up a task to be handled, such as word processing, image processing, or processing. of video.
More complex event processing requires stateful event handling. This means that a mechanism must be in place to control state in the application design without creating serverless functions. with state – which they cannot be, because they are not persistent. The specific mechanism used here again depends almost entirely on the chosen cloud provider.
With AWS Lambda, for example, use its event workflow design model. Complex events should avoid using synchronous – call-and-wait-for-result – practices, as they are difficult to orchestrate in a stateful framework. A generally useful template is a state machine design template that is built into the specific vendor’s serverless feature set.
Front-end web application design templates
For the web template, the base design template is a microservices or services design template. This design pattern uses a function to provide the necessary link to one or more associated HTTP events that represent a common HTTP endpoint. Here a API Gateway or Service Broker front-end function, which is invoked by the HTTP event – get / post – and then frequently accesses an external datastore. This architecture model is like a storefront design model suitable for serverless.
A more complex model for web and mobile support is the webhook design model, which uses a queue to hold the work passed from the serverless function to a set of non-serverless back-end processes, including including a hybrid cloud model where transaction processing takes place in the data center. . Back-end congestion triggers a function to queue work, rather than passing too much data to the back-end process. This general design pattern will work in any cloud, but tailors the implementation to match the cloud provider’s backpressure mechanism and queuing services.
Two architecture models related to the webhook also deserve to be taken into consideration. One is the first in, first out design pattern, which is used when a queue needs to be processed in that specific order. This processing order is typically required if the output work is multistep and stateful in nature, as many transactions are.
The other option is the request router design pattern. This model uses one function to examine the input and relays it to another function based on the request. This method only works for asynchronous functions and uses a front-end queue to hold input work that cannot be dispatched immediately or that overwhelms the processing of the function.
Use serverless design patterns
Serverless design patterns are useless until you classify the target application as event, web, or app. This step helps you identify the main suitable design patterns. Event-based models are either simple events or stateful models in most cases, and web models are variations of a storefront model.
Then take this leading approach to the target serverless vendor documentation pages and see what specific tools and features they offer to support the operation of the application. The tools and features of a serverless provider include things like queue tools, database tools, and even APIs or service brokers. It is a good idea to tailor your use of features and serverlessness in and around these tools to simplify development and optimize the scalability of the resulting application.
On the flip side, all of these web service tools come at a cost, and if you want to avoid spending the money, you might need to find a separate serverless architecture model that doesn’t use them. For example, the demand router design pattern can replace a proprietary offering like AWS Step Functions in some situations.
When developing the application, keep in mind that serverless design patterns are different from the types of design patterns that most developers typically use. in conventional applications. Developers should think of serverless as a method of billing cloud services rather than an architecture that dictates certain practices. As such, it can be applied to almost any software project with the proper effort.
Because serverless is still an emerging technology, different cloud providers have introduced platforms for it in different ways, and there is not yet a neat and established design pattern cookbook. In the meantime, use these proven design patterns and stay on top of developments in serverless technology.