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.
Having had great success using AWS Lambda within our insurance product (MyBuilder Plus), late last year we made the decision to move all our web request traffic over to the platform!
However, we noticed when attempting to migrate over one application in particular, that we could not use the latest release of Bref (the PHP runtime) due to a conflict between required Symfony Process component versions.