Why Stax Is Built on Serverless Tech

Benefits

Building serverless applications bring many benefits over traditional, server-based application development:

Cost: Large parts of our system only run in response to a request from our users. In the quiet times, we do less work, which saves us money. This means we’re taking full advantage of the elastic cloud provided by AWS to minimize our cost. Lower costs for us means lower costs for our customers.

Scalability: Event-driven applications are able respond to our customers as requests increase and decrease, without needing to be re-worked.

Simplicity: Serverless applications push a lot of traditional application complexity off to the AWS platform. This implies that you know how to use the platform, and while this can be a bit daunting when you first get started, once you’ve got a few applications “under your belt”, the amount of code you can avoid writing is empowering.

Reduced Operational Overhead: While the operational requirements for serverless applications is never zero, it is a lot less than a traditional application.

Improved Security: By using serverless technologies as possible, we leverage the power and capabilities of the AWS Shared Responsibility Model. Serverless also means we write less code, which is good because code is a liability, what the code does for you is an asset.

Improved Speed: By reducing the “undifferentiated heavy lifting” and not doing low-level infrastructure configuration, we enable our development teams to go fast, giving them more time to focus on building the things that makes Stax unique and valuable to our customers.

All of these things mean we can spend more time focusing on our customer and achieving their outcomes.

History of Serverless

The term “serverless” was popularized by the Serverless Framework back in 2015. The framework had originally been called JAWS (JavaScript + AWS) and made it easy to leverage AWS Lambda to build complicated applications quickly and easily.

While Lambda wasn’t the first FaaS (Functions as a Service) offering out there, it had the biggest and loudest launch back at AWS re:Invent in 2014. Lambda took full advantage of the AWS landscape, making it easier than ever to integrate functions with other AWS services for storage, hosting, logging, etc. This gave developers unprecedented access to the services they would need to develop applications without ever spinning up a server on which to run them.

Just to be clear—of course there are still servers (somewhere) in a serverless solution. The key is that we don’t have to care about them. We don’t have to maintain them, patch them, restart them, etc. They’re an implementation detail, and not something we need to concern ourselves with. As long as it “just works”, it doesn’t matter.

What is Serverless?

In practice, we use serverless as an easy way to describe a collection of services from AWS where AWS does as much of the work as possible. This means we lose the ability to change configuration for some things, but in practice we don’t actually want to configure (and be responsible for) those things. Being able to configure the full environment means you have more control, but that comes with the cost of being responsible for it all:

"With great power comes great responsibility" - The Peter Parker principle

Focus on Services

When you no longer have to focus on servers, you can start focusing on services. AWS has an extensive range of serverless services, and the main ones we use to deliver Stax are:

S3: Object storage at global scale. This underpins most of our services, used for storing artifacts, recording messages and events, and serving static web assets to the world. where it is used for storing artifacts, recording messages and events, and serving static web assets to the world.

Lambda: The backbone of any serverless application, this is functions-as-service. Almost all of our systems use Lambda in some shape or form.

AppSync: GraphQL as a service, which power our interactive web console, so that users get updates on their actions in real time using GraphQL subscriptions.

API Gateway: HTTP events as a service. We use this in our REST API, as well as for other internal services.

DDB: DynamoDB is ideal serverless database solution. We use this for managing support tickets.

SNS: The real time messaging service. SNS it great for sharing alerts and events widely amongst our platforms as a “fire and forget” style messaging service - if you miss it, it’s gone.

SQS: The original AWS service. SQS provides a serverless queue that consumers can retrieve messages from. This service is great because it provides durable queues that can manage the flow of messages.

Kinesis: Is the event streaming service from AWS. It provides fast messaging, but with the benefit of having the ability to replay messages in order. We use this in our back-end billing and logging systems.

EventBridge: An event bus-as-a-service. This replaces the functionality formerly provided by CloudWatch Events, and lets us deliver events to customers so they can build their own automation based on security and operational events coming from Stax.

Step Functions: Is a task-based workflow management service, using FSMs (finite state machines). We use this to track complex, long-running tasks with minimum overhead and maximum visibility.

These services are all characterized by the fact that you never talk to a “host”, but only to resources e.g. tables, queues, buckets, etc.

When Not to Go Serverless?

While this works great for many applications, it doesn’t work for all applications all of the time.

Serverless is the best fit for event-based applications, and many modern applications are event-based. The most common example is a website: a user or customer visits your website and clicks a button (the click is the event). Another common fit might be a task that needs to run on a schedule (the time of day is the event), or something that must respond to an event sent from another system e.g. a message delivered via SNS. If your application doesn’t work off events, such as continually or very long-running processing, then serverless may not be the right approach.

Go Serverless

The serverless approach is about making it as easy to run applications that meet the needs of your customers and deliver value as quickly as possible. Serverless does this by removing operational overheads and blockers, and streamlining your work in the cloud.

Just like serverless, Stax is also about streamlining working in the cloud. By using Stax, customers push as much of the undifferentiated heavy lifting of running a secure, compliant, and cost-effective AWS footprint on to us, so they can focus on the things that are unique to their business.

This ensures they’re getting the maximum value out of the work that their teams are doing, and providing the most value to their customers.

We think they shouldn’t have to worry about the low-level services and integrations to run a Well Architected environment on AWS. We can do that for them, and in less time.

By using serverless automation, we can deliver valuable results to our customers in minutes, not the weeks or months it would take them to do it themselves.