Building a CloudFront log parser for Hugo with Kiro CLI.

And some surprise outcomes!

When I started creating content for the AWS Community Builder program, like many people I started with WordPress. However, it was too complex, had a lot of functionality I didn’t need, and more importantly would have needed a server running somewhere to host it.

All of that led me to looking at static web site generators fairly quickly - a great advantage of this is that you can host them in GitHub or something similar; or given I’m an AWS Community Builder, build it on AWS. And that’s what I described in my article Hosting a Static Website on AWS; just S3, CloudFront and not a server to be seen. I could even tie in a really simple pipeline that would regenerate the site as I commited my changes to a git repo (more info here).

But how do you know that this approach works - I could access the site and see the pages, but how could I see what others were doing and that it worked for them? I did setup Google Analytics, thanks to a Hugo integration, but it felt over the top, and it’s been niggling away for well over a year, that I wanted a different, more aligned solution.

Amazon’s new European Sovereign Cloud.

A Strategic Response to US Law and EU Data Privacy

Organisations outside the US considering the use of Cloud services have been faced with a hard choice. All the major providers, including AWS, Azure, and Google, are based in the US and fall under US legal jurisdiction.

Organisations in the EU or EU-adjacent locations (especially the UK) must consider GDPR and other data regulations. Typically, these regulations state that an organisation in one of these locations should limit the use of outside third parties unless those parties can guarantee parity with EU requirements. For simplicity, I’ll refer to EU organisations for the rest of this article.

Is your monitoring testing strategy chaos?

If not, maybe it should be!

Introduction

Nowadays, many Cloud implementations will make use of serverless architectures, such as AWS Lambdas and API Gateways to implement micro-services, or other similar functionality to deliver business logic without the need to manage servers.

This is now a mature pattern, and we have a wealth of tools and approaches to help us ensure that our serverless code is performing as expected. We can develop and test locally, and use pipelines to deploy, all ensuring the risk of deploying non-functioning code is minimised.

Just starting out? Here's some thoughts

What, no cloud tutorials?

This is not my usual type of topic - but I’ve spoken at a couple of user groups over the last year or so. These often have quite a few people at the start of their career and, several times, I’ve ended up in conversations about the best way to stand out when starting a tech career. Now I’m not claiming that these are going to magically help you win a position, but I do think that they’ll help improve your chances.

Chaos in the Cloud

A Introduction to Chaos Engineering and Amazon's Fault Injection Service

This is the first in a series of articles looking at chaos engineering in general, and in particular how we can use Amazon’s Fault Injection Service to test the resilience of our AWS systems.

When I first started developing, we wrote huge, monolithic applications either running locally on our desktops, or in our datacenters. We’d write applications that had tens or even hundreds of thousands of lines of code. However, the applications we wrote usually consisted of a single component, maybe two if we used a database, handling all of the logic and functionality within a single application. Whilst this meant that we usually had complex, hard to navigate, code bases, it did mean that in terms of architecture, our applications were relatively simple.