I thought a good way to start my blog would be to go over the steps I took to create it. In choosing the technology stack, the first thing to know about me is I am a very cost conscious person, especially when it comes to recurring costs. I am also a huge fan of the latest technologies and finding if I can use them to create more efficient / performant solutions. As a result of that, for the past several years, I have been a huge advocate of Serverless technologies, AKA Functions as a Service (FaaS), with most of that experience focusing on Amazon Web Services (AWS) offering of Lambda.
For this blog I definitely knew that I wanted to go the serverless route; there is no way I would be OK with the blog requiring a VM or a container running for the site to be available. Strictly hosting static content was not an option because I wanted to have some interaction (like comments). In general, when creating solutions, I try to use AWS Lambda until the problem being solved proves in some way that Lambda is not the right answer, which is rare.
In addition to serverless no longer requiring a VM or a container running for the site to be available, it introduces some other great benefits as well. For example:
I actually originally started creating this blog using the same approach that I have used for the last few years for most serverless projects, creating a Lambda function written in Python and then adding API Gateway to make the lambda available as an HTTP event. Then in my research, I was reading more about API Gateway being used as a direct proxy to other AWS services (which I had not leveraged before), with articles like these:
As that first article had me thinking about this, I was realizing the most responsible way to create my blog would be simply using API Gateway as a service proxy to DynamoDB; no need to add another piece in creating a lambda that is simply retrieving the record from DynamoDB and putting it into the HTML format that we want the browser to receive. That solution would still have all of the benefits of serverless that I stated above, but would remove another piece, theoretically making it less complex. Let's ignore the complexity of Velocity Template Language (VTL) for now ☺. The high level architecture would look like:
Next, I would like to thank Andres Moreno for reviewing my initial draft that turned into this blog series and pointing me to his blog post, How to build a Serverless API in AWS without using a single lambda. Based on his feedback I cleaned up several things in this series, and moved to creating the APIs using the OpenAPI definition files rather than many CloudFormation resources as I was initially.
In this series we will be doing everything via CloudFormation, more specifically CloudFormation with the AWS Serverless Application Model (SAM) extensions. The serverless framework and terraform are great options as well, but AWS SAM is my current preference. Most importantly though, on all projects do everything as code, Infrastructure as Code (IaC). Doing things manually by hand is not recommended due to it being slow, error-prone, inconsistent, not scalable and not repeatable. So, it is important that everything in our project is defined as code, that way it is self-documenting of what is deployed, easily repeatable, ready to be moved into an automated pipeline and easy to iteratively improve.
If you want to run through this series of posts on your own, you will need:
The rough plan I have in mind for this series is:
If there is something else you would like to see, please leave a comment or message me on Twitter/LinkedIn (links on the right side bar).
You must be signed in to post a comment.Sign out