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.
I am a big proponent of the Serverless movement.
The ability to concentrate efforts on only the code and infrastructure concerns which directly add business value is very powerful.
Function-as-a-Service (FaaS) offerings like AWS Lambda impose limitations which help aid in designing more fault tolerant/scalable systems; leaning towards event-driven architectures.
However, there are times when we need to execute behaviour which exceed common-place FaaS duration limits (i.e. AWS Lambda’s 15-minute limit).
In this case we ideally do not want to resort to a lower-level of compute (i.e. a VPS such as EC2), but instead be able to define and run such behaviour alongside our FaaS counterparts.
In this post I would like to discuss a Serverless Framework plugin I have written which aids in bridging this gap, by-way of ECS and AWS Fargate.