An independent guide to building modern software for serverless and native cloud

Building with Serverless

This is the third in a multi-part overview of serverless and native cloud technologies for beginners. This series looks at the origins of the PAAS model, at what defines serverless, what you can build with it, and what benefits it offers.

In the previous post we outlined the features that define serverless as well as the categories of services that have these features. In this post we’re going to take a quick tour of the kinds of things you might build using these serverless services. This obviously isn't an exhaustive list of the possibilities, but should start to give shape to the overall capabilities of the technology.

Building Services

If, as this website argues, service-oriented architecture is a key part of how you build modern solutions, then having the ability to easily build custom services is going to be very important. Fortunately, this is very much one of the strengths of serverless, and is a good example of how this technology goes hand in hand with modern architectures.

So let’s start by outlining a textbook serverless service stack, the kind of basic building block that you might use as the backend for an SPA web application or mobile app, or as part of process or system API in an enterprise environment. Our textbook stack has an API management layer at the top which routes requests to a compute layer below it, running as functions, which in turn read and write to a NoSQL serverless database. Rounding out this architecture, and aligning it with what this site’s Learning AWS Serverless course covers, this stack secures the API layer with an OAuth 2.0-compliant identity service. The API will also, ideally, define its endpoints and data schema using OpenAPI.

For reference, on AWS this stack would use the following services:

  • API Gateway for API management
  • Cognito as the identity service
  • Lambda for compute
  • DynamoDB as the NoSQL database

The equivalent stack on Azure would use these services:

  • API Management
  • AD B2C as the identity service
  • Azure Functions for compute
  • Cosmos as the NoSQL database

Using OpenAPI enables you to define a schema of reusable request and response objects, making it easier to compose orchestrations of multiple services. Using API management adds a layer of indirection between the consumers of services and their implementations. This makes it possible to have a broad, full-featured API that’s implemented with smaller units of micro-service code. These units of code, by being smaller, are going to be more cohesive and so easier for a team to understand and maintain. By not being monolithic, small services are also free to be built on the most suitable platforms, using the most suitable libraries. They can also be deployed independently when isolated updates are necessary.

If you want to avoid cold starts of any kind, or you want to run code on a language platform or version of a language platform not supported by functions, then running containerized API endpoints is a good alternative. API management services can route requests to container endpoints just as well as they can integrate with functions. If you need to use a SQL database, there are serverless options for these as well, such as Aurora Serverless on AWS or Managed SQL instances on Azure.

Building Integration Services

There are whole categories of integration techniques that are traditionally performed on middleware like ESBs. These techniques include things like uncoupling execution processes with async messaging, transforming event messages and intelligently routing them to different targets, or defining orchestrations of multiple services. All of these techniques can be performed in the cloud using serverless integration services. To list some examples, you might combine these integration services in the following ways:

  • Route outbound events asynchronously through a message queue in order to invoke web hooks on registered listeners
  • Read messages in a queue, then fan out and transform messages for multiple message or endpoint targets
  • Orchestrate a long-running batch job that calls multiple services in a loop, either synchronously or asynchronously

Again, for reference, integration services in AWS include:

  • SQS for messaging
  • EventBridge for event-processing and intelligent routing
  • Step Functions for orchestration

Some equivalent services in Azure would include:

  • ServiceBus for messaging
  • EventGrid for event-processing and intelligent routing
  • Durable Functions for orchestration

Processing Data

There are also services that can be used in combination to process large data objects or high-volume streams of incoming data. In either case, incoming data can trigger events that can be integrated with custom services or with custom integration processes. Object storage can also be integrated with identity services to enable authenticated uploads or downloads within applications.

Using Identity Services

We’ve mentioned the role that identity services can play in helping to secure APIs or object storage. Let’s outline what else this type of service can do for you. Obviously, to start, you can use an identity service to centralize your authentication mechanism, enabling your users to access multiple applications with a single set of credentials. Identity services also make it easier to implement advanced security features, such as basic or adaptive multi-factor authentication.

They also make it possible to federate with other identity providers, so that inbound users of OIDC- or SAML-based providers can authenticate on your identity service using credentials from the originating service. You can also implement custom authentication flows that use additional credentials. Finally, you can share identity service client IDs across sibling applications to enable seamless user navigation between them without their needing to re-authenticate.

Modernizing Applications

Zooming out to full solutions, serverless building blocks can be used to help modernize legacy web applications. Such modernization might follow a re-platforming, or a more ambitious re-architecting strategy. When re-platforming an application, you might take these steps:

  • Containerize the application code
  • Run these containers on serverless container hosting
  • Run the database layer on serverless SQL
  • Expose the containers through an application load balancer, secured with an integrated identity service
  • Persist session state in a managed cache service to uncouple user sessions from the lifecycles of the container instances

A more ambitious re-architecting strategy might look take these steps:

  • Refactor business logic into a suite of micro-services
  • Run serverless services behind a managed API
  • Run the database layer on serverless SQL or NoSQL
  • Secure the API with an identity service
  • Build a new SPA frontend that calls the API.

The re-platforming strategy is a shorter path to migrating an application to a modern cloud platform. The advantage of the more ambitious re-architecting strategy is that the application’s functionality will be more maintainable and more adaptable over time. This second strategy also makes it easier to expose APIs to other systems and can do so using native technologies that integrate well with cloud network infrastructure. This makes it easier to securely establish private, cross-account network connectivity with other workloads running in the cloud.