Journey to Fully Serverless Architecture

Melchor Tatlonghari

Below are my own personal experimentations on different tech stacks for deploying my own web application. I have taken the time to learn about different technologies outside of my normal work in order to gain a deeper understanding of them. As I discuss the different technologies and their processes, I will also include difficulty ratings and the amount of time it took me to learn them. Please note that these difficulty ratings and time frames are based on my experience during that specific time period. Additionally, please keep in mind that there is no one solution that fits all scenarios; every technical decision has its own trade-offs and successes through trial and error.

1st Iteration: Layman’s approach Tech Stack: Wordpress Difficulty: easy Cost: 5–10$ per month Length of being an engineer: 1–2 years

Rationale.

When I first started in web development, I chose to use Wordpress as a way to publish my site. It was the most popular platform out there during the time and I was looking for an easy way to create a website. Wordpress was an ideal platform for me because as a beginner, I did not have to worry about the technicalities of web development and could instead focus on content generation. The sotware-as-a-service model made it easy for me to quickly launch my website with. This seemed like a rational approach at the time.

Why I moved out of it.

However, upon further reflection and experience with website building, I realized that using WordPress for my first iteration was not actually a good idea. It did not provide me with a good portfolio which I could showcase potential employers or clients. It also had several limitations which prevented me from achieving certain functionality or customizations with my website. Additionally, while using WordPress, I had no control over the data or code associated with my website as all rights were owned by third party providers such as hosting companies and other plugins used by WordPress.

Overall, while using a standard CMS may have been suitable for creating simple websites during the beginning stages of my career as an engineer; it soon became apparent that it would not be able to meet all of my requirements and expectations in terms of functionality and performance optimization.

Photo by Ian Battaglia on Unsplash 2nd Iteration: Journey to the Cloud (There is no cloud, it’s just somebody else’s computer)

Tech Stack: AWS Cloud (via EC2, VPC, Route 53, ELB, Cloudfront) Difficulty: hard Cost: 20–30$ per month Length of being an engineer: 3–5 years

Rationale

My second iteration of the tech stack I chose to use was Amazon Web Services. This was a difficult choice due to the complexity of setting up a cloud infrastructure. I wanted to learn extensively how to deploy to the cloud and get real-world experience rather than being all theoretical. I also wanted to understand the intricacies of deploying of a web application, intricacies of setting a cloud network and making site publicly available.

Why I moved out of it.

At first my decision seemed good because it gave me an opportunity to gain some hands on experience with deploying applications on cloud and learn various technologies in this domain. However, with time I started facing certain problems that made me realize that this tech stack was not good for me long term. The cost was piling up for reasons I did not understand during that time. I was also not able to understand the basics of cloud computing which meant that I could not scale my application properly. Finally, lacking knowledge about security protocols meant that the security of my web application was compromised as well (e.g.: VPC all ports being open, ACL’s not restricting unwanted traffic, etc.)

Ultimately, after learning and having more in depth knowledge of the cloud, what made me reconsider was that there were simply too many resources that I had to manage and keep in check. There was no Infrastructure as Code back then and it was too tedious to manage manually for something I did as a hobby.

3rd Iteration: Static Clouds Tech Stack: AWS static hosted S3 Bucket Difficulty: easy Cost: <2$ per month Length of being an engineer: 5–6 years

Rationale

The third iteration of website and my tech stack of choice was still in AWS but was just purely static and hosted on a S3 Bucket. This decision was based on the fact that I had a basic understanding of cloud and what each service offered. After exploring other options, I decided that for my website, hosting a static web site was the best choice in the interim.

The cost of using AWS for my website was relatively low, which made it an attractive option. Not only did it fit within my budget, but it also didn’t require much maintenance or upkeep. Additionally, this tech stack was easy to use and navigate, without too many complexities that would make it difficult to understand.

Why I moved out of it.

However, after using this tech stack for some time I realized there were some limitations in terms of what I could do with my site, which was the original problem I had on the first iteration. Safe to say this stack did not last long.

4th Iteration: Smooth Sailing Tech Stack: AWS LightSail, Docker Difficulty: medium Cost: <4$ per month Length of being an engineer: 6–8 years

Rationale.

I had already become adept with AWS and its various services, but LightSail was something new to me. It promised managed hosting that was cost effective and allowed me to quickly spin up servers without needing to manage all the bloat associated with setting up EC2 instances. Additionally, it provided an easy way to set up DNS configurations and other networking details without too much hassle.

Since Docker containers were becoming increasingly popular at that time, I wanted to explore using them in production settings in mini-servers. LightSail seemed like the perfect platform for this purpose since it offered managed hosting services that promised an easier deployment process for Docker containers than AWS EC2 instances alone would have provided.

Why I moved out of it.

While LightSail did make deploying Docker containers relatively simple, the platform had some drawbacks. For instance, there was no infrastructure as code back then so any configuration changes or updates had to be done manually. This made it difficult to keep track of the current state of the infrastructure and scale up or down servers without manual intervention. Additionally, LightSail seemed like an unusual niche in AWS; most developers were still sticking with more traditional EC2 instances for their deployments rather than using LightSail’s managed hosting services.

Ultimately, while using LightSail was a great learning experience for me, it wasn’t the right fit for my project in the long run since there were several limitations that prevented me from achieving my goals with ease or scalability going forward. Nevertheless, I am glad that I chose to use LightSail as astable iteration since it served as an introduction into containerized deployments and helped me discover what types of solutions would be best suited for future projects of mine.

Current Iteration: Completely Serverless Tech Stack: Complete Serverless — Terraform, API Gateway, DynamoDB, AWS Lambda, AWS Amplify difficulty: hard cost: <1$ per month length of being an engineer: 10+ years

Rationale.

Building a serverless application using Terraform, Lambda, and AWS Amplify is my current iteration. Being an engineer with over 10+ years of experience, I wanted to learn how to use Terraform to manage the infrastructure of a serverless application and bring all the best practices’ I’ve learned all together.

When I started the project, I had to build out various configurations such as IAM, API gateway, lambda functions, and Dynamodb in terraform. This allowed me to gain a better understanding of how Terraform works and how it can be used in production settings. Since security is always a priority, I also implemented via hub-spoke paradigm for enhanced security.

Once the infrastructure was set up and running, I used AWS Amplify for continuous integration and deployment. This allowed me to quickly deploy changes without having to manually verify each change before pushing it out into production. It also enabled me to automate the process of testing new features and changes before they were released into production.

Running completely serverless and everything automated is a dream, I just push code to the repository and less than 2 minutes later its in production! Cost has never been cheaper given that it only cost me less than $1 a day (relative to number of views). Finally, I have all the control of all the application and can build out the features myself later on.

Why I will move out of it.

I will post my next iteration later on