Whilst documenting how I structured the infrastructure used for hosting our wedding website, I mentioned the possibility of showcasing its use for another application concern.
In the tradition of over engineering a problem related to our wedding - we really did not want resized/compressed photos shared through WhatsApp/iMessage of the big day.
So instead, I decided to create a Serverless photo gallery which provided guests with the ability to share the original photos in one place.
I also wanted to explore the ability to achieve this with having 100% feature parity locally in a development setting.
In this post I would like to discuss how I went about building these photo-upload/resizing and lazy-loaded gallery capabilities using AWS Lambda, S3 and DynamoDB.
The final implementation can be found in this GitHub repository.
Since being introduced to the world of Advent of Code just prior to the 2020 calendar starting, I subsequently spent the majority of 2021 completing (and documenting) the 2015, 2016 and 2017 calendars.
For the 2021 calendar I decided that it would be interesting (and challenging) to complete the calendar in C, with an initial solution written in Python to meet the daily aspect of the challenge.
Additionally, with C being such a performant language, I also wanted to set the goal of ensuring that the entire C calendar was solvable on a single CPU core in under a half-a-second (inspired by this blog post).
In this post I wish to discuss how I went about achieving this goal (spoiler410315 μs (0.410 s) on average) and the hurdles I faced along the way.
Over the past couple of weeks I have been thinking of how feasible it would be to deploy the wedding website I released earlier this year on Kubernetes using a Raspberry Pi cluster.
After a little research, this past bank-holiday weekend I set myself the goal to build and deploy the web application on Kubernetes by the end of the Monday bank-holiday!
In this post I would like to discuss how I went about achieving this goal and what I learnt in the process.
We have been a big fan of DataDog and the level of telemetry/monitoring it provides us for many years now.
One such aspect of monitoring that we employ throughout the services we maintain are HTTP health checks, which are intentionally run on a separate cloud provider to our primary which is AWS.
DataDog has supplied the ability to handle running these checks via their agent for many years, providing us with a sufficient blackbox means of ensuring a service is functioning as expected.
This past week we explored the viability of containerising this responsibility into a service which could be run on a Serverless platform such as the DigitalOcean App Platform.
I have always been amazed by the sheer amount of services AWS offers.
Although I spend a lot of time working within AWS, I am always surprised to find yet another service that I did not know existed.
Better still, is with each new service comes an associated new service icon.
This is why I thought it would be interesting (and somewhat educational) to build a small trivia game which quizzes you on AWS service icons.