If you've read my previous blog posts, you know I love serverless technologies. My love of serverless technologies comes from my passion for creating performant, efficient solutions. My favorite aspect of serverless technologies is its ability to 'scale to zero,' meaning that when there are no requests, there are no consumed resources (other than persistent storage) and therefore no costs. Of course, we can turn off every type of web service. However, the difference between traditional systems and good serverless solutions is that our web service is still online and available to accept requests. Until there's a request to act on, nothing is running. While there are no running resources, there are no costs.
Other points about serverless technologies:
- Of course, there are still servers.
- The servers are abstracted away by the Cloud Provider, and the application team does not manage or need to worry about them.
- The service's pricing follows a pay-per-use model.
- Pay for actual usage, not per hour of your web service being available.
- No need for capacity planning and buying for your expected peak usage
- The managed services scale to meet demand.
- Highly available / fault-tolerant
- The services are multi-AZ.
The serverless technology that I use the most is AWS Lambda. AWS Lambda is AWS's Functions-as-a-Service offering. When I first started using AWS Lambda, it was through the console. Managing lambdas, or any resource, through the console is not recommended because it is slow, not scalable, challenging to improve iteratively, and risks inconsistency from one environment to the next. The best practice is to have everything defined as code. In addition to our application code, we should also define our infrastructure as code. Our Infrastructure-as-Code (IaC) makes it easy to improve iteratively, easily repeatable (i.e., create another environment), and ready to be moved into an automated pipeline.
I originally started using the serverless framework to move to an IaC solution for my lambda projects. As I started using the serverless framework, I quickly found that while it is best practice to manage your serverless projects as IaC. It is easier as well. With everything for the project in code, the infrastructure, and the actual application, you can commit it to version control (Git) and then iteratively improve on it from there. With git diff, you can always compare what you currently have in your working copy to what was last committed. I find that setup very productive while working on the solution I am creating. Then using a framework, like the serverless framework, makes it a lot easier to manage configuration items. The first thing I remember finding with the serverless framework was how much easier it was to manage cross-origin resource sharing (CORS) settings with its IaC rather than directly in the console.
Later I moved to a company where CloudFormation was the de facto IaC. I had previously used Terraform for all of my non-serverless IaC project needs. Soon after, I learned about AWS Serverless Application Model (SAM). AWS SAM is an extension of AWS CloudFormation that makes the building of serverless projects even more efficient. AWS SAM includes a CloudFormation macro, referenced in the template under the Transform key. That macro adds to the library of CloudFormation resources a group of elements prefaced with AWS::Serverless. When you include that transform in your CloudFormation template, you can use those additional resources in your template. When the CloudFormation service receives your template, the macro will run and expand those elements into the actual CloudFormation required had you not used the macro. This process often will create many more CloudFormation resources to accomplish what the SAM macro had simplified for you. After processing that transform, CloudFormation creates the resources like it usually would.
AWS SAM also includes a useful CLI that quickly enables us to get things done from the command line. So in my IaC journey, I then moved to use AWS SAM. I was pleased with AWS SAM until I started trying out the AWS Cloud Development Kit (CDK). The AWS CDK won me over because it uses the programming languages we already use for our projects. Using the programming languages, we are already familiar with obviously brings that language's looping and conditional logic, which can be a massive plus to writing and maintaining IaC. Another big plus is using the programming language to provide familiar ways to abstract reusable code into modules (which CDK calls Level 3 Constructs).
I was happy with AWS CDK and could not imagine a way for it to get better. But it did. The team at serverless-stack.com created SST. As the project's GitHub page states, 'Serverless Stack (SST) is a framework that makes it easy to build serverless apps. It's an extension of AWS CDK and its features'. My favorite features of SST are its CLI and the Static Site construct it provides. The CLI and Static Site construct enables you to create a serverless application's backend and frontend (full-stack) in one project and deploy it with a single command. Your frontend application will require a reference to the backend for the application to work. The provided CLI and construct does that for you.
Not only does SST extend AWS CDK, to make it even better. The Serverless-Stack team provides full-stack demo applications, including a step-by-step guide to build a full-stack notes application. Having a working full-stack application to play around with eased the task for me to get comfortable working on frontend applications using both React and Angular.
SST also features a live lambda development environment. To me, this is magical. When you are in an SST project at your terminal, you run npx sst start. At that point, it deploys resources to your AWS account and runs locally in this live development mode. You can then edit your lambda functions locally, and they immediately take effect. I do not need to understand how this works fully. I know it works, and it's fantastic. I have navigated around in the console from the projects I have used SST. From that observation, I understand that SST creates a particular lambda function for local development stacks and an associated API Gateway configured for WebSockets. I gather that the particular lambda function and WebSockets API Gateway relay the requests back to your running SST CLI where the dev environment invocations occur. If you would like to learn more about how that works, I see they documented it at https://docs.serverless-stack.com/live-lambda-development#sst-start
Even then, I thought it could not get better than SST. The team at serverless-stack then added a console on their website that you can launch and easily manage many resources within your stack that is currently running using your local CLI.
I encourage you to give SST a try.
References:
https://docs.serverless-stack.com/
https://docs.serverless-stack.com/live-lambda-development#sst-start
Top comments (0)