Analysis / Case Study / Events / Technology / /

Serverless Architecture: Five Design Patterns

7 Mar 2017 10:26am, by

Amazon Web Services is seeing five predominant usage patterns for its Lambda serverless service, according to a presentation at the APIdays Australia conference last week in Sydney, given by AWS Solution Architect Cassandra Bonner.

Summing up the current maturity of serverless technologies, consultant Ken Fromm recently wrote on A Cloud Guru’s Medium blog that serverless architecture allows developers to focus on managing what their applications and systems need to do, rather than the physical capabilities, limits and complexities of their backend infrastructure. That makes a job or task the unit of scale in a serverless environment.

That means, in the main, tasks tend to be asynchronous, stateless and ephemeral, or as Fromm puts it: “The task processing essentially becomes container processing with the containers set up and removed on a task by task basis.”

At APIdays, Bonner says the AWS team sees serverless as comprising four main principles:

  • Simple but usable primitives (i.e. small, useable building blocks).
  • Scales with usage (servers are autoscaled on the user’s behalf).
  • Pay-only usage (customers only pay for the time using services).
  • Built-in availability and fault tolerance (i.e. NoOps).

Earlier at APIdays, Peter Stanski, a Senior Manager in Solutions Architecture at Amazon Web Services in Australia, had said that the traditional adoption path of AWS in the Australian and New Zealand market (as for much of the world) was changing among medium businesses and enterprises.

For the past year or two, whereas startups had usually been “all in” from the beginning, established businesses with legacy systems often traveled a path from developing and testing proof of concepts, building new applications, adding analytics and then starting to migrate some of their legacy applications, finally focusing on migrating mission-critical apps to AWS.

Peter Stanski from AWS presenting at APIdays Australia

This year, Stanski said, businesses of all sizes tended to be “all in” from the very beginning. They would embark on migration activities of existing legacy stacks while at the same time building new applications directly from their cloud hosting services.

Bonner described a similar trend in the uptake of serverless: While new applications might be being built leveraging a serverless architecture, for the most part, businesses were employing hybrid approaches that saw new features built in a serverless environment and then weaving in and out of existing application hosting architecture environments.

“This is how we are seeing a lot of customers starting off,” says Bonner, pointing to one common example: a business might have an existing workflow of managing image data and were now adding an image recognition feature that was being run in a serverless environment and then the catalogued findings being piped back into the existing legacy workflow, which might be situated in a user’s cloud hosted environment.

The five serverless patterns for use cases that Bonner defined were:

  1. Event-driven data processing.
  2. Web applications.
  3. Mobile and Internet-of-Things applications.
  4. Application ecosystems.
  5. Event workflows.

Use case #1: Event-driven Data Processing

Architecture map showing event processing use case as described in article

One of the most common applications for serverless environments is to trigger actions after an event occurs. Bonner gave the example of an image object being added to an Amazon S3 bucket. That may trigger a lambda function, for example, to run a compression task so that the image is re-archived into S3 in a standard size format.

This style of use case also fits well with the hybrid trend, where serverless is being leveraged to perform specific functions within a wider hosted environment.

#2: Serverless Web Applications

Architecture map showing web app use case as described in article

In a serverless web app, there may be a combination of running processes that determine contextual and personal elements of the user to serve content and functionality that meets the user’s needs. In this use case, for example, static content might be stored in S3 to display when the application is opened in the browser.

At the same time, processing is initiated through the application’s API gateway to run Lambda functions that determine the application user’s context. The static content is then enhanced with more dynamic content that is generated through the lambda functions and stored as dynamic data in DynamoDB.

#3: Mobile and Internet of Things Applications

Architecture map showing mobile app use case as described in article

Similar to the web apps use case, mobile and IoT applications built in a serverless environment are looking to decide on what content to offer the user based on their context. Serverless authentication elements are used to ensure the user — whether that be a human or a machine — is authorized appropriately to access information or functionality. Lambdas then carry out functionality and interact with data in a DynamoDB to meet the user’s needs.

#4: Serverless Application Ecosystems

Architecture map showing app ecosystem use case as described in article

In an app ecosystem, applications or workflows are created in a serverless environment and draw on a combination of AWS functionalities and products alongside third party provider APIs.

Bonner gave an example of someone telling an Amazon Echo that they were giving a presentation, that voice data then triggering a lambda function to pass that message on to a remote team via the Slack API. Polling within the serverless environment then identifies when the team has responded and messages the Echo with the feedback.

#5: Event Workflow

Architecture map showing event workflow use case as described in article

The recent release of AWS Step Functions is now adding greater sophistication to serverless workflow possibilities. Decision trees can be created in Step Functions that then align with Lambdas and AWS products to carry out workflow branched actions (although it was confusing that Amazon Web Services were highlighting Step Functions in Australia given it is not available there as yet).

For example, using a pub/sub messaging model, it is possible to visualize and have all functions and distributed components drawn through a state machine. Users can map the customer onboarding process, entry into CRM, shopping cart ordering and order fulfillment through Step Functions and lambdas and AWS tools are automatically added to ensure the workflow can be completed.

So while Fromm talks about serverless being predominantly asynchronous, stateless and ephemeral, once getting into more complex workflows and applications, some capability to persist state and make synchronous calls comes into play.

Step Functions provides state machines so that Lambda functions can have some degree of transient state available for business processes where serverless applications may need to marry synchronous and asynchronous call chains.

But power users of serverless like Ben Kehoe from iRobots believes the current pricing structure of Step Functions is too prohibitive to use it in production in serverless environments. In addition, the default throttling limits suggest that the intended use does not tend to cover scaled but transient event scheduling.

“I’m hopeful that State as-a-Service is a paradigm that can be made to work for low-level, transient state needed by FaaS in serverless architectures, whether it’s through Step Functions or another service,” wrote Kehoe late last year after Step Functions was first announced.

Authentication Choices

Within the serverless environment, it is also possible to choose a user authentication and identity management workflow best suited to the serverless design pattern and use case being implemented. Authentication methods may change depending on whether a number of users from the one organization need access with varying permission roles, whether users are predominantly customers, or whether partners have some access.

A video of Jim Tran and Justin Pirtle presenting at AWS Re:Invent last November describes in more detail some of the authentication choices available in the serverless environment:

The Maturing Serverless Tooling and Ecosystem

Serverless is still very much in progress to become a major force in how businesses deliver via cloud.

As serverless matures and is increasingly taken up for both new projects and as hybrid, it is likely that the business adoption of cloud will be repeated, albeit at a smaller rate in serverless, as businesses begin to choose to migrate existing applications to serverless architecture. While mission-critical apps for businesses and enterprises at scale may not be on the cards just yet, with some security capabilities and overall ecosystem tooling still needing to mature, the use cases of serverless suggest that beyond startups, it is increasing probable that serverless will become an “all in” decision in the same way that cloud is today.


A digest of the week’s most important stories & analyses.

View / Add Comments