Stackery is software that helps teams to quickly build and manage serverless infrastructure. In order to fully utilize Stackery's toolset, it's helpful to know a little about serverless app architecture and how it compares to other types of architectures and server management.
This guide is written for serverless beginners. If you're already familiar with building serverless applications, feel free to skip right to our Quickstart Tutorial, which will familiarize you with using Stackery by creating and deploying a serverless web app.
What is Serverless?
Serverless is a form of cloud computing architecture in which the cloud provider manages computing resources, including individual servers.
Yes, there are still servers behind serverless functions, just as “the cloud” consists of a lot of individual servers. As the saying goes, “There is no cloud, it’s just someone else’s computer”. This is true for serverless as well. We could just as well say, “There is no serverless, it’s just someone else’s problem.”
These are five general characteristics that classify cloud services as serverless:
- No management of servers (including virtual machines or containers): the cloud provider does this for you
- Pricing based on consumption, not capacity: you pay for resources only when they’re in use
- Scaling built in: a resource or application scales to meet demand
- Automatic availability and fault tolerance: more things you don’t have to worry about
- Provisioning resources through infrastructure-as-code, not hardware
Developing serverless applications requires a change of mindset for seasoned engineers who are used to writing monolithic applications or microservices. While serverless development allows engineers to develop and deploy applications faster than in previous workflows, there are some DevOps challenges to undertake. The most significant adjustment is often in a developer's environment, since you can't run managed cloud services on your local development laptop.
With serverless, deploying to the cloud becomes part of the development process. Engineers need to deploy as part of their daily workflow of developing and testing functionality. Automated testing generally needs to happen against a deployed environment, where the managed service integrations can be fully exercised and validated.
This means the environment management needs of a serverless team shift significantly. You need to get good at managing a multitude of AWS accounts and developer specific environments, avoiding namespace collisions and injecting environment-specific configuration.
In short, serverless development requires new workflows and toolsets; Stackery is one of the toolsets that can help serverless teams thrive.
Types of serverless stacks
Serverless applications have three components:
- Business logic: a function (Lambda) that defines the logic of the application
- Building blocks: Resources such as databases, API gateways, authentication services, IOT, Machine Learning, container tasks, and other cloud services that support a function
- Workflow phase dependencies: Environment configuration and secrets that respectively define and enable access to the dependencies unique to each phase of the development workflow
Taken together, these three components create a single “stack” that is “deployed”: i.e., activated within a specified AWS account and region. In some applications, they can make up the entire backend.
The above example is about as simple as you can get with a stack. It consists of a function and an object store. When triggered, the function manipulates the data stored in the object store (in this case, an S3 bucket on AWS).
A simple use case would be a function that returns a specific image from the bucket when triggered. For instance, when a user logs into an app, their profile picture could be retrieved from the object store.
Here’s a somewhat more complex stack:
This stack consists of a function (
handleSubmit) that is triggered when someone submits an email address on a website’s newsletter signup form (
POST /submit in the API). The function takes the contents of that signup form (in this case, a name and email address) and stores it in a table called
SignUps. If this stack were to be expanded, another function could email the contents of the
SignUps table to a user when requested, for example.
Here is a stack handling CRUD operations in a web application:
While this looks like a complex operation, it’s actually just the
DELETE methods connected to a table of users. Each of the functions is handling just one operation, depending on which API endpoint is triggered, and then the results of that function are stored in a table.
This kind of CRUD stack would be very useful in a web application that requires users to sign up and sign in to use. When a user signs up, the
POST API triggers the
createUser function, which simply pulls up the correct DynamoDB table and writes the values sent (typically username and password) to the table. The next time the user comes back to the app and wants to log in, the
getUser function is called by the
GET API. Should the user change their mind and want to delete their account, the
deleteUser function handles that through the
Finally, let's look at a complex, real-world situation:
This is an actual AWS CloudFormation template for deployment of the AWS Connected Vehicle Solution. We won't get into the details, but at over 2400 lines of YAML, this is an advanced use case of serverless, though by no means unusual in production applications.
A serverless stack is described by a template file, typically written in YAML or JSON. This configuration file describes the functions, API endpoints and other resources in your application.
The Serverless Application Model (SAM)
Stackery is built to utilize AWS's open-source Serverless Application Model (AWS SAM) template.
Stackery does support other template formats, which you can read about in our serverless template formats documentation.
A SAM template is the blueprint for your serverless application, describing all of your resources and the relationships between them. Here's an example of a SAM template for the newsletter signup stack shown above:
You can view the entire GitHub repository of a newsletter signup application to get a better sense of what a serverless application looks like.
Users building a serverless application from scratch would need to write their own
template.yaml file as part of the application development process. One of the advantages of using Stackery is that this file is automatically configured as you add resources in the Stackery Dashboard or the CLI.
What is Stackery?
Stackery is serverless acceleration software, a set of development and operations tools for engineers building production serverless applications. It consists of a web-based Dashboard and a command line (CLI) tool, as well as the Stackery Role, which is a group of resources allowing Stackery to be linked with the user's AWS account(s).
These tools are used to manage production serverless applications throughout their lifecycle, particularly in the case of a team workflow, where different developers can have different permissions sets, environments, and other configurations.
As defined above, stacks in Stackery are individual applications consisting of interactions between cloud resources specified in a configuration file (in the form of a
serverless.yaml file located in the root directory of the stack’s repository). To see all of your stacks, just click the Stacks link in the main navigation.
In Stackery, the stack code and configuration is stored in a Git repository from your usual Git provider such as GitHub, which means your typical application workflow of commits and PRs is preserved when working within the app.
Cloud Resource References
A Cloud Resource Reference represents an AWS service within a stack. These resources are shown as boxes in the Stackery Dashboard. They come in a variety of types that represent various cloud provider resources such as AWS Lambda functions, API services (API Gateway or AppSync for GraphQL), datastores (e.g. S3, MySQL, Postgres, DynamoDB), network infrastructure (e.g. Virtual Networks, CDNs), and Docker Tasks. Some reference types have input and output ports that are used in combination with Wires to subscribe to and publish events. A full list of Cloud Resource Reference types can be found in the menu to the left.
Environments provide a mechanism to store environment-specific configuration values such as database passwords, API keys, or application configurations, as well as deployment configurations (by region and AWS account). It’s typical to have a set of environments such as production, staging, and development. In some cases, it’s useful to create individual development environments for each engineer. When an environment is created within Stackery, you specify a region and an AWS account. Stacks will be deployed into the AWS account and region associated with the environment.
In serverless applications, certain cloud resources must integrate with one another. A resource integration is a connection between two resources and is represented by a wire between them in the Stackery Dashboard. You'll find two types of wires in the Stackery Dashboard:
Event Subscription Wire: a solid line shown that represents an event subscription or integration between Cloud Resources.
Service Discovery Wire: a dashed line shown that connects a Compute Resource (Function or Docker Task) to another Cloud Resource Node. A Service Discovery Wire can only originate from a Compute Resource and populates the IAM permissions and environment variables required for it to perform actions on the connected resource.
Wires are used to subscribe one resource to an event stream emitted by another resource. For example, a Function's input is commonly connected to a Rest API's output, which subscribes an AWS Lambda function to API Gateway HTTP events. This pattern can be used to subscribe Lambda functions to a wide variety of event sources such as S3, DynamoDB, API Gateway, GraphQL API through AppSync, Kinesis streams, CloudWatch Events, other Lambda functions, and unhandled exceptions.
To learn more about each element of Stackery's software, see the documentation under the "Using Stackery" section to the left, or dive right in with the Quickstart.