Jon Goodall

Building a Jekyll Blog with AI: An Honest Take on ‘AI Slop’

2025-12-06T15:00:00+00:00

Building a Jekyll Blog with AI: An Honest Take on “AI Slop”

Let’s get something out of the way immediately: I didn’t write most of the code for this website. An AI did. Specifically, Claude (via Kiro IDE) wrote the Jekyll templates, the CSS, the JavaScript, the Ruby scripts, and even this blog post you’re reading right now.

Is this “AI slop”? Maybe. Am I going to pretend I hand-crafted every line of HTML? Absolutely not.

Why Be Honest About It?

I’m a Principal Cloud Engineer. I work with AWS, Terraform, Kubernetes, CI/CD pipelines - that’s my domain. I can architect a multi-region serverless application, but ask me to center a div and I’ll probably Google it like everyone else.

When I decided to modernize my portfolio site and add a blog, I had two options:

Spend weeks learning modern web development best practices, Jekyll internals, Bootstrap 5, and frontend tooling
Use AI to handle the web dev parts while I focus on the content and infrastructure

I chose option 2, and I’m not ashamed of it.

What “AI-Assisted” Actually Means

Here’s what the process looked like:

What I Did:

Decided what I wanted (multi-page site, blog, modern design)
Provided feedback (“the hero header is crap”, “color scheme needs better contrast”)
Made high-level decisions (GitHub Pages hosting, Jekyll, Bootstrap 5)
Said “yes” or “no” to changes
Pointed out when things were broken
That’s about it, honestly

What Claude Did:

Wrote Jekyll layouts and includes
Created responsive CSS with proper color contrast
Built the blog listing and pagination system
Generated category and tag pages
Created Ruby scripts for automation
Wrote property-based tests
Fixed bugs and styling issues

What We Did Together:

Iterated on design (“much better”, “still crap”)
Debugged issues (blog not showing posts, 404s on category pages)
Improved the workflow (automated taxonomy generation instead of manual pages)

The Interesting Part

Here’s what I find genuinely interesting about this process:

1. It’s Not Magic

The AI didn’t just conjure a perfect website. It took iteration, feedback, and course correction. I had to know what I wanted and be able to articulate when something wasn’t working.

2. It’s Still My Site (Sort Of)

The decisions are mine in the sense that I said “yes” or “no” to things. The content is be mine (apart from most of this post, guess which bits I did for bonus points). But let’s not pretend I “architected” this - I just pointed at things and said “make it work” or “that’s ugly”.

3. It Reveals What Actually Matters

Turns out, for a personal blog, the code quality matters less than:

Does it work?
Is it maintainable?
Does it look professional?
Can I focus on writing content instead of fighting with CSS?

The answer to all of these is yes.

4. The Transparency Is The Point

I could have built this with AI and never mentioned it. Many people do. But I think the interesting story here is being honest about the process.

I’m not a web developer. I don’t want to be a web developer. But I wanted a modern, professional site. AI made that possible without requiring me to become an expert in a domain I don’t care about.

What This Means for “AI Slop”

The term “AI slop” usually refers to low-effort, mass-produced content that floods the internet. And yeah, that’s a real problem.

But is this that?

I’d argue no, for a few reasons:

It’s Transparent: I’m telling you exactly how it was built
It’s Purposeful: This site serves a specific purpose for me
It’s Maintained: I’m responsible for it and will keep it updated
It’s Honest: I’m not claiming expertise I don’t have

The alternative would be:

Paying a web developer (expensive, ongoing)
Using a cookie-cutter template (limiting, generic)
Not having a blog at all (boring)

The Real Question

The real question isn’t “Is this AI slop?” It’s “Does this add value?”

For me, the answer is yes:

I have a professional online presence
I can share technical content about DevOps and cloud engineering
I can maintain and update it myself

For you, the reader, hopefully it’s also yes:

You get honest technical content about cloud engineering
You see a real example of AI-assisted development
You can judge for yourself whether the result is valuable

The Workflow

Since this is a technical blog, here’s what the actual workflow looked like:

## 1. Started with a forked one-page portfolio
git clone https://github.com/jdgoodall1/jdgoodall1.github.io.git

## 2. Used Kiro IDE to modernize it
## - Created spec documents (requirements, design, tasks)
## - Iterated on implementation
## - Fixed issues as they came up

## 3. Automated the boring parts
rake generate_taxonomy  # Auto-generates category/tag pages
rake serve             # Runs Jekyll with live reload

## 4. Deploy
git push origin main   # GitHub Pages handles the rest

The entire modernization took a few hours of back-and-forth with the AI, versus what would have been weeks of learning and coding.

What I Actually Learned

Let’s be real: not much. I didn’t suddenly become a Jekyll expert or learn Bootstrap 5. I mostly just said “this looks crap” or “the blog isn’t showing posts” and let the AI figure it out.

Could I maintain this? Eh, kinda. Could I modify it? Maybe simple stuff. Did I learn the deep internals of Jekyll templating? Absolutely not.

And that’s fine. That was never the goal.

The Bottom Line

This site is “AI slop” in the sense that an AI generated most of the code. But it’s not slop in the sense of being low-quality, thoughtless, or deceptive.

It’s a tool that let me focus on what I’m good at (cloud engineering, DevOps, technical writing) while still having a professional web presence.

Is that cheating? I don’t think so. It’s just using the right tool for the job.

Your Turn

If you’re reading this and thinking “I could never build a website”, maybe reconsider. With AI assistance, you probably can. You just need to:

Know what you want
Be able to give feedback
Be willing to iterate
Be honest about the process

And if you’re reading this thinking “This is exactly what’s wrong with AI”, I respect that. But I’d rather be honest about using AI than pretend I’m something I’m not.

Meta Note

Yes, Claude wrote this blog post too. I gave it the direction: “lean into the AI slop label but be honest about it - I’m not going to claim this as my work in any meaningful way, I just think it’s interesting but can’t be bothered to write it.”

And here we are.

Is it slop? You decide.

Update: If you want to see the actual code and process, it’s all public on GitHub. The README is transparent about how it was built, and you can see every commit.

Another Update: The irony of using AI to write a blog post about using AI to build a blog is not lost on me - or Claude actually, it wrote that joke.

AWS Database Savings Plans – Save Up to 35% – FINALLY!

2025-12-04T14:00:00+00:00

It’s AWS Re:Invent right now, and one announcement has me and the rest of the AWS community very excited – AWS Database Savings Plans.

I’ve been asking for this for as long as I can remember, probably because I’m a bit dull, and also a little stingy…

You’re likely wondering why I’m so excited about this, and in no small part, it’s because it makes my life easier. It also gives you, AWS customers, another AWS cost optimisation option to save money on your AWS bill, which is always a good thing.

Before we get into the details about AWS Database Savings Plans, let’s do a bit of a history lesson.

A History of AWS Savings Plans

All the way back in 2019 AWS released “Compute Savings Plans”, and I’ve been a fan since day 1. They make saving money on “compute” (namely, EC2, Fargate and later Lambda) much easier.

Before the Compute Savings Plan was released, if you knew that you were going to keep the same server for 1-3 years, you could lock in a commitment using a Reserved Instance (RI). Savings of 20% were common, and savings of 30% or more were possible. But, if you had plans on moving to “modern compute”, you were a bit stuck. Sure, you could do it, but you’d be paying for the RI you’d committed to for the duration of the term, even if you weren’t using it. This was a real barrier to modernisation, because nobody likes paying twice.

This is an oversimplification, as convertible Reserved Instances exist, which let you trade them for other types. Reserved Instances also “roll up” smaller-sized Reserved Instances to cover larger servers. This has a caveat, though – it only applies if there’s no licence fee built into the hourly spend (sorry, Windows users). But in essence, you were stuck managing servers.

You could move to containers, but you had to keep using EC2 to run the containers on, which was a headache and added engineering time.

Compute Savings Plans are different, though – you commit to an hourly spend and save money. Literally, that’s it.

OK, it’s a spend within the three supported services (EC2, Lambda and Fargate), but so long as you’re spending money on one of those things, you’d be getting the discounted pricing. Purchase terms are the same – commit to longer and pay more up front to save more money. However, the 0% upfront 1-year plan is incredibly compelling, so I default to recommending it.

Compute Savings Plans aren’t perfect, though. My biggest gripe was that they didn’t support database spend. You might argue it’s a storage service, not a compute service, but tell a developer that. The line between “storage” and “compute” is so thin you can see through it at this point. My second biggest issue was the hourly commitment rather than the daily one. With a daily commitment you can account much better for flexible workload trends, but you can’t have everything.

Cool, history done, what’s new?

As of the 2nd of December 2025, announced to great cheers from the audience in Matt Garman’s re:Invent 2025 keynote, AWS Database Savings Plans are a thing! This is “A Very Good Thing”. He really did save the best til last, with only 2 seconds left on the ‘shot clock’!

AWS Database Savings Plans work in a very similar way to Compute Savings Plans – commit to an hourly spend in “supported usage” and save money.

Purchase terms are similar, but currently you can only commit to a 1-year term (come on AWS, give us 3 years!), and we’re also only offered a no up-front payment option at lauch. I’d love to see increasing discounts available for committing for longer, and paying up front as you can with Compute Savings Plans. Despite this, there are still some serious discounts available here, and the best bit is it covers serverless too – with a discount of up to 35%! That’s massive and really cements the idea for me that you should start on serverless options until your per-hour cost outweighs the “scale to zero” benefit. AWS are also pushing ‘Advance Pay’ as a way to pay up front for your database services, but there’s no discount for doing this, so I’m not sure why you’d bother.

They also have day 1 support in Savings Plan Purchase Analyzer – I waxed lyrical about this on an episode of the Logicast AWS News Podcast, so this is a really nice thing to have on day 1. You’d better believe if it didn’t have it, I’d be complaining about it!

Sounds Great, What’s the Catch?

The AWS Database Savings Plan isn’t a perfect offering, as it still suffers from my second gripe of Compute Savings Plans – the hourly vs. daily commitment.

It does also muddy the water a bit, as we now have four different types of Savings Plan:

Compute Savings Plan
EC2 Savings Plan
Database Savings Plan
SageMaker Savings Plan

This is very easy to solve though, AWS just needs to release an overall “Savings Plan” that covers Compute & Database, whilst dropping the EC2 Savings Plan offer. I’ve never found them useful between Reserved Instances and Compute Savings Plans, but maybe some people do. I also don’t use SageMaker to have a considered opinion on SageMaker Savings Plans, so they get to stay for now.

I’m sure it’s not very easy for AWS to do this, for a myriad of internal and technical reasons, but we can but dream.

Now, onto the “supported services” list. This is confusing. It covers:

RDS
Aurora
DynamoDB
ElastiCache
DocumentDB
Neptune
Keyspaces
Timestream
Database Migration Service (who’s running that for a whole year?).

This is a massive list of services for day 1 – remember Compute Savings plans only covered EC2 & Fargate at launch.

However, it’s not all spend within those services that counts. Got a Redis cluster? Sorry, only Valkey is supported. Using a t4g RDS instance? No discount for you. In fact, anything that uses ‘servers’ is only eligible to be included in a Database Savings Plan if it’s using the latest instance types (r7g, m7g, m7i, m8g, etc). This is very frustrating, as many people I’ve worked with need a 24/7 non-prod environment, but only need t4g instances, for example.

The serverless offering somewhat redeems this, as it’s just per-CU (Capacity Unit) hour. This is a much better offering than the current option of “nothing” and goes a long way to solving for “I can’t do serverless, it’s more expensive under consistent load”. This has been a real issue for me personally, as I’m a big advocate of serverless-first, but I couldn’t honestly recommend it for production workloads. Either the warmup time was too long for transactional workloads, or the constant throughput was too expensive without being able to make a committed purchase.

Final Thoughts on AWS Database Savings Plans

I’m willing to forgive the complicated in-scope vs. out-of-scope spend on this one, considering the vast array of services that are covered. Also this is a V1 offering so I’m sure it will evolve to include more services, and more payment options, as per the other savings mechanisms.

This also doesn’t solve for “do I buy a Reserved Instance or an AWS Database Savings Plan”, but the gap is closing, and I’m looking forward to seeing more things come into scope in the future. AWS have committed to including newly released instance types as they become available, so I’ll just have to upgrade my boxes, I guess.

Building a Serverless Podcast Workflow: Adventures with AI

2024-12-29T14:00:00+00:00

As you may know, I’m a co-host & standing guest on the Logicast AWS News Podcast, where we discuss all things in the news about AWS.

What you probably don’t know, is that the preparation & production of a podcast is rather a lot a work, and that anything to speed up & simplify the process is absolutely necessary – especially for a weekly podcast.

On the preparation side, being about recent AWS news helps because we don’t have to do as much work on research side – we just turn up & record. This doesn’t help us on the production side though, which is still a lot of work.

To give you a flavour, the things we have to do every week are:

Pick the articles (and ideally read them)
Share with the guest and answer any questions they might have
Record the episode
Download the files
Convert the files into the correct formats
Create a trailer
Create a summary (the “show notes”, in podcasting parlance)
Upload to the publishing platform
Social promotion

On top of this, because “content is king”, we want to be able to re-use the episode as much as possible. Our current wishlist is:

Create short “clips” for social posting to “drip feed” the content and drive subscribers
Create a long-form blog post from the recording, that isn’t just a transcript
Add full subtitles to each video.

As with any problem, there were a few options to solve both the required tasks, and start on the wishlist.

Option 1: Outsource it.

This looks like a combination of things, from hiring a production & marketing person (much love to Alicja for the work she does), to using 3rd party tools to help with some of the creation (I’m not linking the tool, because they’re not paying us, but we use an AI service for clip/trailer creation)

Option 2: Automate All The Things

Obviously I want to do this, because I’m an engineer, and in my head my time is free. I’m sure Logicata disagrees with me here though…..

However, throw in the fact that we “needed” a reason to talk about AI, we thought we’d better have a go at doing “something”.

Enter the Workflow

Now, I’m a Serverless AWS Community Builder, so obviously I went straight for Lambda & Step Functions here. I started playing around with options, and for once, doing some research. I know! Didn’t see that coming either.

Up in this rarified research-fueled air, I found this AWS blog: https://aws.amazon.com/blogs/machine-learning/create-summaries-of-recordings-using-generative-ai-with-amazon-bedrock-and-amazon-transcribe/

This was a really good foundation for what we needed/wanted to build, it even had a sample project at the time which let me short-circuit hours of dev time

After a bit of tweaking, I came up with this:

Yes, that’s a big scary image, so let’s break it down.

The process is:

Step 1: Kick-off with File Upload

We start by uploading an m4a file to an S3 bucket, and use the bucket notification to trigger the workflow.

I have to download the files from the recording platform, which isn’t a problem, but is a bit annoying.

Step 2: Media Conversion

AWS Elemental MediaConvert transforms the m4a file into an mp3 format, ready for Spotify and other platforms.

We have to do this because the recording platform delivers an m4a, but most audio platforms prefer an mp3.

This is a fire-and-forget approach, so I’m manually checking for the job completion and downloading the file afterwards. Again, not a problem but somewhat annoying.

Step 3: Transcription

Amazon Transcribe converts audio into a text-based JSON document. This is actually the most expensive part of the process, which I didn’t expect at the outset.

Step 4: Run the prompts

Amazon Bedrock reads the transcription and generates summaries and titles using prompts stored in DynamoDB.

Since building this, prompt manager became a thing, because as everyone knows the best way to get AWS to create a new feature is to build it yourself first.

This is all in one Lambda, using a loop in Python. I regret this enormously but it was the quickest option.

Step 5: Outputs

The final outputs are sent to an SNS topic for easy access.

We have a Slack channel email subscribed to the topic, so the messages aren’t lost in inboxes.

We went with SNS & email both because the baseline I used was already doing it, and I couldn’t be bothered to work out the schema for AWS Chatbot. I should probably do this though.

Obviously this isn’t our full wishlist, or even the complete set of required tasks. However, with careful prompting, it does make the required tasks a lot faster to do. The summary is a good prompt to create the show notes & the LLM creates the title – sometimes we use it, sometimes not.

There must be some problems though?

You would be correct there. The issue comes back to my time – it’s only free in my head. Turns out, building this sort of thing takes rather a lot of time & effort, so it has a number of “rough edges”.

Chiefly:

1. It’s really fragile.

Seriously, one dodgy prompt, or an episode that runs a touch long, bang. All falls over, nothing comes out the end. Lately we’ve been hitting rate limits too, presumably because we’re on an ancient version of Claude.

This is mostly because I’m hacking it together, and not spending a proper amount of time on it

2. Transcription is expensive, and the workflow must restart on error.

Again, because it’s fragile, the re-runs have to start at the beginning. What’s worse, because most of the failures are prompt-based and errors in the model invocation are only checked after-the-fact in a downstream task, I can’t take the offending prompt out and re-drive from the failure, thus forcing a full re-run.

3. It’s kinda slow

Nothing doing here, it’s just slow. No parallelisation of the prompts (due to the aforementioned bad Python loop), and a single lambda taking every output response and dumping it onto SNS at the same time.

Improvements.

OK, we’ve run this for a few months (eek), and I’ve even delivered a whole talk on it (see that here), I should probably do something about fixing these rough edges. This was the list:

Improvement 1:

Update the model:

Annoyingly the interface between Claude versions has changed, so some faffing around is needed here.

Improvement 2:

Use Prompt Manager:

What it says on the tin. No more dodgy DynamoDB table for the prompts, use the service properly.

Improvement 3:

Fix the bad loop:

Take the loop through the prompts out of a single lambda, and run them all as single Lambda’s, called using a Map state.

This also solves for speed, as the prompts are the second slowest part of the workflow

Improvement 4:

Less fragility:

Through the judicious use of “ignoring errors”, we want to be able to run all the prompts and get outputs, even if one (or most) of them fail.

Improvement 5:

File conversion result in Slack

Still using SNS -> email, but now we’re checking for the conversion job, creating an S3 pre-signed URL and sending that to the SNS topic as soon as it’s available. The pre-signed URL lasts for a couple of hours.

Yes yes, Show us a picture:

Fine, something like this:

Did it work?

Well, no. Not quite.

With the improvement list as a starting place, I ended up here:

Bigger and scarier than before I know, but it can’t be helped – we’re just doing more stuff now.

Let me walk you through it.

Steps 1-3: Kick Off:

All still the same – kick off with the upload of the m4a file, trigger the transcoding & transcription.

Only slight tweak is the transcoding trigger actually returns the job id, so I can use that later.

Step 4: Parallel State:

Now we actually use the parallel container I built earlier and split into two branches – one for the transcription & LLM invocations, and the other for the transcoding.

Step 5 (Transcoding Branch):

Nothing massively clever here, just a loop in the step function based on an if/else/continue premise to check for the status of the transcoding job.

If it’s not done, loop around again and wait some more, if it failed, if it’s completed generate a pre-signed url and send to SNS, if it failed send an error to SNS but don’t halt the step function.

This last bit is important – as far as possible we’re not halting the step function for errors in the process, especially on the lower-value task.

Step 5 (LLM Branch):

Now we grab the prompts in their own Lambda, but they’re still from DynamoDB, because I couldn’t fathom prompt manager in the few evenings I had to spend on this.

Same goes for the direct SDK integration between DDB & Step Functions really.

I’m sure some of the Serverless DevAdvocates, AWS Heroes & Community Builders I know would dislike me for this, but I didn’t see the benefit of it here.

Using Lambda Powertools in Python, grabbing the list is 4 lines of code. Plus I’d already written said code in v1, so I kept it.

Step 6 (LLM Branch):

Much the same as before, but with another loop – not a map state.

It turns out the rate limiting wasn’t because Claude v2 is ancient. It’s because all of Bedrock has really low rate limits.

This means that we’re not solving for speed, but we are solving for rate limits, with an unlimited number of prompts, so that’s something.

On each execution of the “Invoke Bedrock Model” lambda we’re dropping the prompt we ran from the list of them, as a quick-and-dirty for loop. With some time this could be cleaned up a bit, but for now it works.

Also, we’re using Claude 3.5 Sonnet V1, and have designs on both V2 (or V3.5 Opus when that eventually comes out), and Amazon Nova Pro, as the outputs in the console looked encouraging.

Step 7 (LLM Branch):

You’ll notice that a couple of states have been removed, namely the direct SDK integration with SNS for sending the results, and the “end error” state.

This reduces the re-run cost by allowing me to re-drive the state machine from the point of error in the case of hitting a rate limit – which was 90% of our errors in v1.

Step 8 (LLM Branch):

Back around to the iterator we go, but this time with an arbitrary 2 minute sleep.

This gets us around the 1 invocation-per-minute rate we’re working with, but I could do something a bit smarter here with error code checking & exponential backoff.

The iterator is well-trodden at this point – just check if the prompts list still has prompts in it, and go around again. If it’s now empty, finish the branch.

Step 9 (Both Branches):

End.

Both branches are now done, so we close out.

So, how is this better?

Well for one I don’t have to sit and wait for the transcoding to finish. The pre-signed URL is dropped straight into Slack for me to grab, so that’s nice.

Also, we can run an unlimited number of prompts, and shouldn’t get rate-limited anywhere near as often – if we do, re-drive from failure covers the restart without having to re-do the expensive transcoding & transcribing.

The updated model performs loads better, and because the interface for all Claude v3/3.5 models is the same, I have a route to make each prompt run under a different model – which I thought was the idea behind Bedrock to start with, but seems to be harder than I thought it would be.

Also we have monitoring, sort of.

I put a small Cloudwatch Alarm on the failures of the step function (well, I had Q Developer write it actually, can’t avoid using AI in this project), which also sends to the same SNS topic. That way I can just upload the file to S3, and get on with other things, without having to babysit the workflow.

And of course I have an update on the project I can write a talk for, so I best start shopping that around local meetup groups I guess.

What’s Next?

Expand the Iterator

I still want to be able to run a different model for each prompt, because models aren’t one-size-fits-all, and I’d like an easy way to test lots of different models on the same prompt.

Use Prompt Manager

Still not using this, and I really should be.

Resiliency

We’re in a better place than we were, but it’s still not as good as I’d like it to be. Ideally we’ll handle rate limit exceptions via a retry and exponential backoff, plus have proper alerting rather than a single alert for the whole Step Function.

Finally, What did we learn?

Rather a lot, as it happens.

Time & Effort Needed

Phase 1 showed the sheer amount of effort needed to get these things going, even with a big jumping-off point from AWS. This is compounded by the fact that this is a marketing/hobby project, so doesn’t get a lot of time spent on it. Phase 2 just compounded that lesson – it took the best part of a day to make the change, split across several evenings, and it’s not that different from phase 1.

Pace of Change

The pace of change within LLMs is really high – between v1 & v2 there were 6 different models released just for Claude, so keeping up with the current models is a challenge all by itself. Once you start thinking about other model providers (looking at you Amazon Nova), it’s a whole different challenge.

LLMs are Non-Deterministic

So we knew that already from the documentation, but in practice it can be really frustrating to not have a consistent output between executions, and you need to be aware of it when developing against them.

Skillset

By day I’m an SRE/Platform Engineer/Generalist Cloud Engineer, not a developer and certainly not an AI/LLM expert, so this was a challenge both dusting off my Serverless developer skills whilst learning how to interface with Bedrock. Fortunately AWS have done a really good job of making it an easy service to consume, and I highly recommend you start with the chat interface in the console to test your prompts.

The other recommendation I’d have for you is to dive in – after v1 I gravitated much more towards AI/LLM talks and workshops at the various AWS conferences I’ve attended this year (London Summit, London Partner Summit, Re:Invent), which I got much more out of for having a baseline level of knowledge, thanks to this project.

LLMs Have Rate Limits

Well, yes, you might say. However I didn’t appreciate just how low they are in Bedrock.

When you think about it, it makes sense, and our usage puts a very high number of tokens through the model in a short space of time. But you do need to be aware of them, and handle them appropriately in your own implementations.

So, What are My Tips?

Hopefully you can learn from my mistakes here, but if you want to short-circuit this whole “learning by doing” thing, I’d recommend:

1. Go to a couple of workshops before getting going.

They don’t have to be in-person, and could be watching something on YouTube after-the-fact, but for a good portion of phase 1 I struggled with just understanding the new terminology I needed

2. Test your prompts

I said this above but it bears repeating – use the console to test your prompts and see what sort of output you’re likely to get. It’s much cheaper to do this than run a whole transcription & transcoding workflow for the sake of changing a single prompt.

3. Try to do model evaluation

I didn’t do this, because the project I based on had already done it, and settled on Claude2. I regret not going through the process to get a better understanding of why Claude2 was the correct choice at the time though. You’ll also learn a lot about the various models in the process, which might be useful for another project.

4. Request model access up front

The “non-AWS” models aren’t instantly approved when you request them, so save yourself some time and request them early.

5. Check the rate limits

These are different between models & regions, so you can’t assume that the same thing will work if you port it to another region

6. Be aware of time

If you’re new to LLM development, this is a learning curve that you’ll need to climb, so be patient with yourself. Doubly so if you’re not a developer by day.

7. Learn by doing

Hopefully by reading this you can go further and faster than I did, but there’s no substitute for building things when trying to learn.

To wrap this up I think I’ll quote Amazon CTO Dr. Werner Vogels:

Now, Go Build

AWS Lambda Use Cases: When You Should Use It?

2023-05-30T14:00:00+00:00

Lambda, and Serverless in general, is rather “in” right now in the world of cloud computing. If you listened to all the marketing coming out from the big names about it (and yes, I’m guilty of this too); you’d expect that you can run your whole service on it. For next-to-nothing, with no downtime, and your deployments would be as smooth as silk.

So, how much of the marketing spiel should you listen to – how do you know when to use Lambda? Well, I’m going to try and come up with a reasonable list of use cases for AWS Lambda, so that’s a good place to start.

What Is Lambda?

Before we get into “what’s it for”, it’s worth defining “what it is”, so let’s do that.

AWS Lambda is AWS’s take on “Function as a Service” (FaaS). It allows developers to run code without provisioning or managing servers. With AWS Lambda, developers can upload their code, and the service will take care of the rest – including scaling, patching, and availability.

The idea behind AWS Lambda is to make it easier for developers to build scalable, event-driven applications that run on the cloud. The service is highly-available and fault-tolerant. Which means that it can handle large amounts of traffic without crashing or experiencing downtime. One of the key benefits of using AWS Lambda is that it is fully managed. This means that developers don’t have to worry about managing hardware or operating systems. They can focus on building applications, while AWS Lambda takes care of the underlying infrastructure.

AWS Lambda supports a variety of programming languages, including Java, Python, Node.js, C#, and Go. This makes it easy for developers to write code in the language they are most comfortable with, without having to learn a new language or platform.

Another advantage of AWS Lambda is that it provides automatic scaling. This means that the service adjusts the number of functions serving requests. If there is a sudden increase in traffic, AWS Lambda will scale out the number of functions to handle the load. Conversely, if there is a decrease in traffic, the service will scale in the functions to reduce costs.

AWS Lambda is also cost-effective. Developers only pay for the compute time that their code actually uses. This means that if an application isn’t in use, there are no costs associated with running it. Additionally, since AWS Lambda scales based on demand, developers can avoid over-provisioning and paying for unused resources.

That’s all fine and good, but what exactly do you use it for?

AWS Lambda Use Cases

Use Cases for AWS Lambda #1: Glue

Now I’m not talking about AWS Glue but rather using Lambda to “glue” (or “stitch” if you prefer) other AWS services together.

Why would you use Lambda for this?

A few reasons.

Lambda can bridge two services that don’t talk to each other. For instance, when an API Gateway call is made to retrieve a file from an S3 bucket, Lambda can facilitate the interaction between the two.

In some cases, the services do talk to each other, but filtering the results can be challenging. For instance, API Gateway and DynamoDB. Yes, API Gateway can talk to tables, but it’s not easy to work out how or to combine queries from several tables into a single result.

Event-driven architectures. Say you wanted to process an image after uploading to S3, you could send a notification to a queue and have an EC2 instance handle the message processing. Or do this with Lambda, because it’s only charging you when it’s running. In the same vein, you can use Lambda can act as a replacement for cron-triggered scripts, again saving money.

“Gluing” things together is a lot of the work I’ve seen/done used with lambdas as they’re quick to build & deploy and cheap to run. In most of the deployments I’ve seen, the CloudWatch bill for monitoring the lambdas was higher than the bill for the lambdas themselves.

Use Cases for AWS Lambda #2: APIs

So, you can’t use Lambda’s as APIs by themselves but put them behind either API Gateway or an ALB, and you can.

Most APIs are “call-and-response” in that a client calls an endpoint for “something,”. This could be data, to kick off background processing or anything else.

Why would you use Lambda for this?

Once again, it’s about cost and resource utilization.

Lambdas can be permanently provisioned and react in very short spaces of time. So they complete the processing and respond to the user for a much lower cost than a server or container can.

Use Cases for AWS Lambda #3: Websites

This one is a bit out there but go with me on it.

Most “modern” websites consist of dynamically constructed pages. The pages are rendered and served in real-time, per request to the user.

Most webpages don’t do complex processing on the same thread that is serving the page to the user, as this improves the user experience.

Why would you use Lambda for this?

For exactly the same reasons as using it for the backend or an API.

You don’t have to have a server, which might only get occasional use, and instead, only pay when people are using the service. You also have a lot less to worry about when it comes to scaling to meet demand, as the lambda service does this for you.

Use Cases for AWS Lambda #4: Data Processing & ETL

This is similar to the “glue” use case but different enough that I thought it deserved its own section.

ETL (Extract, Transform, Load) is the process of taking data from one data source, changing its format or adding content, and loading it into another data storage platform.

Why would you use Lambda for this?

A couple of reasons, depending on your requirements:

Lambda can be triggered directly from other AWS services. Meaning when data is added to one of the sources, the processing starts quickly in response.

For instance, you could subscribe your Lambda to the event stream from a DynamoDB table, which allows the Lambda to start working within 1 second of the data being added.

Lambda also scales in response to demand, so if you have a period of a large volume of data being added to sources, it will be able to keep up and keep feeding your data warehouse in near-real-time.

Lambda can be called by AWS Step Functions, which allows for complex processing from multiple data sources, whilst being able to break the logic down into very small component parts. This can make the development easier to break up between team members and improve the testability of the system.

Use Cases for AWS Lambda #5: Containerized Workloads

Again, out of left field on this but bear with me.

Since Docker was added as a Lambda runtime environment, you can use Lambda to run anything you’d run in Docker.

The caveat is that it must complete within 15 minutes and use less than 10GB of RAM. I know I touched on this at the start of the article, but it’s definitely worth going into more detail on this.

Why would you use Lambda for this?

We’re back on the same benefits again – cost and complexity. I’ve done the cost thing a few times now, so I’ll skip that and go to the complexity piece instead.

Running Docker-based workloads in a highly-available manner is difficult and requires some level of orchestration (e.g. Docker Swarm, ECS or Kubernetes.

Managing the orchestration tools is a job in and of itself. Yes, AWS can take some of that away in their managed services; but your engineers still need to understand how to manage the tools.

With Lambda, that goes away as it scales to meet demand. Additionally, deployment is as trivial as uploading a Docker image (though you really should be using a CI/CD setup).

Use Cases for AWS Lambda #6: ChatBots & Voice Assistants

ChatBots are on almost every website these days, so I don’t think I need to explain them. If you have a customer service setup of some sort, you either already have a ChatBot on your website, or are thinking/have thought about it.

Why would you use Lambda for this?

Because it can interface using the API/SDK with things like Lex and Polly, you can use Lambda to get data from APIs or other areas of your infrastructure and send them back to the user via the bot.

I can’t promise that your users will actually like the bot, but that’s more to do with the information it’s sending back than the technology.

Closing Thoughts

The hype is more or less correct, and you can use Lambda to run almost anything for a low cost. The biggest drawback is that you have to reframe your thought process. It’s a bit of a mental jump to think about serving web pages out of the same service that you’re using to shuffle data around in your backend, but it can be done.

Not Another DevOps Blog

2021-07-19T14:00:00+00:00

Look. I know what you’re thinking (well, I don’t. But bear with me OK?); “hasn’t this guy seen any of the other blogs out there? Why would I possibly read his one?”

Well…. Good point. One that I went over a few times before I wrote this if I’m honest. But, I don’t think you’ve seen one quite like this before (and if you have, I’d love to see it). Mine will (try to) be different.

One of my favourite things to do is play devil’s advocate, and whilst that might not win me many friends, should make for an interesting read. I’m going to talk about the other side of DevOps, away from the glitz and glamour that start-ups exude. The side that recruiters and managers don’t want to talk about, but that all too often (at least in my case, but maybe I’m just unlucky?) ends up being reality for those of us stuck in big corporates.

The weekend work. The all weekend, all night work. The 7am server upgrades because downtime of any sort isn’t acceptable — even on legacy infrastructure about as stable as a burning house of cards. Networking teams shudder and their endless reasons why something isn’t their fault, until it magically fixes itself without anyone apparently doing anything — apart from them. And maybe the occasional axe grinding.

This isn’t to say that it’s all bad, or even mostly bad — far from it. It’s a fantastic world to live in, work is usually varied (if occasionally really badly thought out, “because agile”). The people are (largely) fantastic, clever, brilliant people just dying on the inside from all the red tape and “corporate synergies”, whatever that means.

It’s Always Bash in the End

2020-05-12T19:00:00+00:00

Photo by Unsplash

I’ve been told by a few people that “you don’t need to know bash anymore”. No I haven’t, that’s a lie. No-one has told me that, because it isn’t true. You absolutely need to understand bash, the CLI, maybe Powershell (useful on Windows, but lately it’s less important) and probably Python.

Why? It’s always bash in the end.

Eventually you will be writing a bash script (or a hacky bash script, as a friend of mine aptly called them). There is just no avoiding it.

What’s this I don’t hear you cry? I’ll just use a configuration management tool? Good idea, I like most of them, they make life a lot easier a lot of the time. But let’s be honest? They’re basically a wrapper around bash. Or Python.

A Concrete Example

Let’s use a concrete example. I had (well, inherited) a task to get regular snapshots taken, of an Amazon EC2 instance, which was hosting a MySQL DB. I also needed to age them out, because we only needed to keep a few days worth.

I’ll walk you through my thought process.

Step 1: Why aren’t we using RDS?

This stuff is handled.

Step 2: Ah, multiple replication sources, damn.

Let’s use lifecycle rules, 50 lines of terraform handles the whole thing.

Step 3: Oh, can’t do that

I need to flush logs and set read locks. Right, custom script. Ansible anyone?

Step 4: Ah, there isn’t a module for “create snapshots”

(there is one for snapshotting an EBS volume, but not for doing all the volumes attached to an instance, at least not when I was doing this). I guess I’m using the AWS CLI.

Step 5: Bash script

Cron to run it, with a cron monitor (lots are available, I’m not advertising any here as they’re not paying me).

Step 6: Profit

(well, continue to draw a salary, but that’s close, right?).

The Point

So what’s the message here? I’m a really good engineer? Well my ego would say yes, but no, that’s not the point.

The point is I ran through 4 layers of “modern” options, from fully managed to IaaS, and ended up writing a script in a language from 1989.

How about that?

Gitlab vs. Github

2020-05-12T14:00:00+00:00

Photo by Unsplash

Since my I posted my article on DevOps tools, which was all funny names and no real content, Gitlab has launched their #gitchallenge. This is to compare Gitlab and GitHub, so that’s what I’m going to do (and hopefully get a free t-shirt, or socks, I like socks).

I didn’t talk about either tool in the last article, because the names didn’t meet my arbitrary criteria of “sounds a bit funny”. I hadn’t used them either, so wasn’t qualified to talk about it. Since then I’ve used both for work, so can talk about them at some length.

I’m going to avoid going into exhaustive detail, because that’s boring, and I’ll do several tl;dr sections as I go along - like this:

Overall Thoughts

TL;DR: For “home” users (i.e. having an online presence) use github, just for brand-awareness outside of the tech community.

For “doing actual work”, if you already have a git solution, that isn’t a “home rolled git server”, just stay with it. It’s not worth leaving unless you need a specific piece of functionality. Or you’re desperate to not use Jenkins (can’t say I blame you).

If you don’t already have a solution use gitlab, for now. The built-in CI/CD is that much better than Github it’s worth picking gitlab just for that. Github is improving its offering though, so who knows how long that will last for?

See that up there? That’s what I mean, good overview, not too long or boring. At least I think so.

OK, let’s do some sections so you can pick and choose which parts of this you care about. It’ll stuff my reader stats, but oh well.

Sections:

Git Functions
CI/CD
Free website Hosting
Things they let you do but shouldn’t
Other stuff that’s relevant, but isn’t really a feature
Closing thoughts

Git Functions

TL;DR: Doesn’t matter, they’re about even.

Long Version: Ok, so this is the basic stuff. They both do everything that you could want at a high-level, for example:

Multiple team members
Varying level of permissions for team members
Branch protection
Merge Requests/Pull Requests
Mandatory approvals on these
CI/CD pipelines triggers

They both cover these in a fairly similar way, so I’m not going to dwell here. The only thing of note is that Gitlab calls requests to merge code “Merge Requests”, which is logical. Github calls the same action a “Pull Request”, which is illogical. However this has been adopted as a term by other tools as well (e.g. bitbucket), so your lexicon will be a little different.

Winner: It’s a draw

CI/CD

TL;DR: Gitlab wins this by a country mile (is that longer than a regular mile? I don’t know). The interface is better, parallel build steps actually exist, there’s manual approvals built-in and the code-reuse is better.

Long Version: This is where gitlabs’ longer history of offering built-in CI/CD becomes quite obvious.

Both Gitlab and Github offer built-in CI, through Gitlab pipelines, and Github Actions. Github actions has only been available since around December 2019(ish?), and it’s pretty good.

There are a few critical oversights though. I’ll illustrate this with an example, that I’ve implemented in both tools before:

Task: End-to-end automated deployments to production, and all lower environments, based on a merge to the master branch. The deployment to production is behind a manual approval, because you’re not Netflix. You’re rebuilding the artefact here, to ensure that you’ve captured hotfixes.

The GitHub way:

(that’s a bit Zen isn’t it? I kinda like it, might do that again)

Trigger a build based on a push to the master
The build runs each step sequentially
- Build the artefact
- Deploy to the lower environments
- End with a call to the API to create a draft release.
Someone publishes the release, which triggers another workflow to run the deployment to prod.

This seems OK, but the problem is you have to change views within Github to run the process end-to-end, so you need at least two windows open. The manual approval is also a fudge using the API to create a draft release.

Compare this with:

The Gitlab Way:

(yep, sticking with this)

Trigger a pipeline based on a push to the master
The pipeline runs which:
- Builds the artefact,
- Deploys it to lower environments in parallel
- Waits for a manual approval for production
You click the “play” button on the pipeline to deploy to prod, and you’re done.

This is better for a few reasons:

Everything is in the same view, so no jumping around the site to get it done.
The process is more intuitive, as all the required steps are in the same pipeline file.
You don’t have to mess around with the API to implement a manual release approval
You haven’t had to write a script to call the API
Although I would highly recommend that you implement releases and tagging in your workflow as a best practice, you shouldn’t have to do it for the sake of a deployment

Winner: Gitlab. By a mile.

Free website hosting

Tl;DR: Gitlab edges this for tech, but Github has this for name recognition outside of the tech community (e.g. recruiters). I’d call this a draw.

Long Version: Both tools do this pretty well, through the use of “pages”. Each account gets one (1) free “pages” domain to host a static site on. Both offer custom DNS options. Both also offer a pre-generated one - e.g. https://jdgoodall1.github.io/ (disclaimer, my profile is hosted on Github for “sending it to recruiters” reasons).

Where they start to differ is build configuration. This is optional for Jekyll sites on Github but mandatory for all sites on Gitlab, making Github the marginal winner for lazy people. Like me.

Winner: Github, just barely.

Things they let you do but shouldn’t

Nice contentious title that one.

TL;DR: The answer to this shouldn’t matter, and if it does to you then you’re a Bad Person™. Github edges this if you do care.

Long Version: What I’m talking about here is in-browser edits. I’m a firm believer that these should be punished by buying a case of something expensive for the team, because you really shouldn’t be doing these.

Both tools let you do this, for ease of use reasons I guess, and I’ll admit to fixing the occasional typo in-browser, but that’s about it.

If you’re doing any real quantity of work in-browser then for the love of whatever it is you care to love, download an IDE. There are loads of free ones that are very good.

That being said, Github is better at this, because it has found a way to put VSCode in-browser, and let you use that for your edits. By doing changes in-browser though, you lose any ability to run tests on your local environment before committing to source.

Doing this runs the risk of making the git history muddy, so I’m not sure we should be striving to make this a better experience.

Winner: Github. But don’t do this. Seriously.

Other stuff that’s relevant, but isn’t really a feature

TL;DR: Github. If you say to a recruiter “here’s my gitlab profile” they’ll probably say, “Oh, like github?” This is brand-awareness, which is important in a few specific cases.

Long Version: In tech, you’re expected to have an online profile of some sort, and to either blog (which I do) or contribute to open source projects.

The best-known home of such things is Github. Why this is, I couldn’t tell you. However the end result is application forms that have “your Github profile” as a box to fill out, and no alternative options.

Yes, I’ve seen this before.

Winner: Github, because people suck

Closing thoughts

You might’ve noticed that github “won” most of the sections there, but that the TL;DR section at the top doesn’t neatly match the sections. That’s because its not that simple - it never is. Also I’m using negative marking in some places just because I can.

My choice of which tool to use depends very highly on what you’re trying to do.

If you need an online presence, and don’t want to fight the tide, you should pick Github.

For ANYTHING ELSE, use Gitlab. The CI/CD offering is SO MUCH BETTER. So much so that its worth using Gitlab just for that. Yes the online editor in Github is better, but STOP USING IT YOU BAD PERSON.

Once you’ve used Gitlabs’ pipelines you’ll never want to use anything else again. Github is catching up in this area, but it’s slow going. So do yourself a favour and chose gitlab.

Fin.

AWS, a translation

2019-07-21T14:00:00+00:00

I’ve not long passed my “AWS Certified Solutions Architect — Associate” exam (that’s a mouthful), and whilst I was studying for it I noticed that, a lot of the service names are “odd”. Or acronyms. Or Greek. I’ve covered this sort of topic before, (see: here), so I thought I’d do it again, with a similar level of brevity. And snark.

There are a lot of services available, so for the sake of my own sanity I’m not covering them all. Also, Amazon has a habit of releasing new services quicker than the drink runs out at an open bar, making it highly likely another few will turn up whilst I’m writing this.

Also worth noting, just by reading this you WONT pass the “AWS-SA-Assoc” exam as there aren’t any questions about what the names mean. It’s more about how you use the services.

AWS

Yep. Starting here. AWS is an acronym (and there’s a lot of them coming up) for Amazon Web Services. But you probably already knew that. A word of warning, a lot of the names are about this creative. le sigh.

Fun(?) fact, AWS made up 58% of Amazons’ profit in 2018 (source: Investopedia). So you can feel better about all the money you’ve spent on Amazon. At least that’s what I’m clinging to.

The Starting Tools

OK. Seems like a good place to start. Well, re-start. These are the tools that AWS is most known for. It’s probably where you’re going to get started with it too.

EC2

Elastic Compute Cluster. Yep. Gonna need to define that one a bit.

In this sense “Elastic” is not that far from an elastic band. The capacity of your resources can stretch and shrink to meet demand, within limits. Compute is running apps, although in this case it refers to virtual servers. Cluster means there’s more than one.

Still awake?

S3

Simple Storage Service. It’s got 3 S’s, so S3. This is an object store, rather than a file store (though Amazon does have one of those too). It’s interchangeable with file storage to an extent. But instead of using native OS commands you interact with it using the AWS CLI tool. Yes I know, more acronyms.

VPC

Virtual Private Cloud.

To understand this you need to understand the difference between public and private cloud. The short version is “with private cloud you own it all, and are the only person (or company) on the hardware. With public cloud, none of that is true (in most cases, but I’m not going to go into that here).

A VPC allows you to treat AWS as if it’s all yours. You’re not going to see anyone else’s resources when you log in, and they wont ever see any of yours either.

For the most part in AWS you have no idea that anyone else is using the service, except for a few unique naming rules.

Route53

DNS (I’m sorry, I’m at it again), Amazon style.

Domain Name System is a translator, between human readable web addresses and an IP address. For example www.google.co.uk has an ip of 216.58.204.3 which your PC uses on the internet (yes that is actually google.co.uk’s IP). Route53 is Amazons implementation.

It’s named after 2 things. Route66 was the first highway in the U.S.A., and DNS servers work on port 53. Kinda creative I guess?

CloudWatch

You can “watch” your “cloud” resources. CloudWatch. This covers metrics and logs, but there are different charges depending on what you’re looking at.

You can do some cool stuff with logs, like exporting them to other tools for analytics and graphing.

CloudTrail

Auditing. Well, an audit “trail” on your “cloud”. Same sort of naming convention here.

EBS

Elastic Block Store.

This is virtual disk, but it’s a type of disk suited to reading and writing in “blocks”. Databases tend to use this sort of storage type, as it has a much faster read & write speed.

RDS

Relational Database Service.

Amazon will set up and manage a “Highly Available” (HA) cluster of a database engine of your choice. Not all DBMS’s are available (sorry Sybase users), but the common ones are there.

You still get CLi and SSH access too, which is nice if you need/want/like to fine-tune anything.

You can pretty much use this as a drop-in replacement for an on-premises DB cluster, but you can’t quite do without a DBA. You will also need some EBS (see above).

IAM

Identity Access Management (what?)

This is AWS’s “permissions” setup. It’s a way to control who gets access to what. Broken down into users, groups, roles & policies. Users go into groups. Roles can be applied to groups or users. Policies are attached to roles.

The upshot of this, is servers/other resources can hold an “IAM Role”. This allows them access to do/see/get/change something from another service, without having to create service accounts. If you’ve ever used them in the past, you’ll understand why this is “A Good Thing TM”.

EFS

Elastic File Store.

Basically a network drive. Cool pricing model — you just use it, and pay for what you use. Unlike disk-based storage pricing, where you have provision and pay for a whole disk. One less headache.

Phew. Time for a break. Actually please don’t leave. It gets better I promise.

Have a coffee. On me.

The Intermediate Tools

These are tools that you will use a lot, once you’re over the initial “what’s this cloud thing?” hurdle. If you’re lucky, you’ll skip the hurdle and crack right on with these too.

ECS & ECR

Elastic Container Service & Elastic Container Registry.

Right, containers. They’d come up eventually.

ECS is Amazon’s service for orchestrating Docker containers (sort of Amazon’s take on Docker Swarm I guess?). ECR is their version of Docker Hub, so you can store all your Docker images inside AWS. Great if your InfoSec people don’t like the idea of data leaving controlled environments.

SQS

Simple Queue Service

It’s a queuing service. Don’t really know what else to say about it? Nothing creative about the name. It was AWS’s first available service though, way back in 2004, predating AWS itself by 2 YEARS!

OK, that’s interesting.

SNS & SES

Simple Notification Service & Simple Email Service

It sends notifications (think text messages), and emails. This is sort of writing itself at this point.

SNS will send emails, but SES gives you more control over the email content.

Aurora & DynamoDB

Aurora is part of the RDS family, but is fully managed, so you don’t get access to the underlying servers. It’s both MySQL and PostgreSQL compliant. Either/or, not both at the same time. The name is Latin for “dawn”.

Little bit of mental gymnastics here, but maybe they mean “dawn of a new database technology”?

DynamoDB is the next extension of AWS’s DB offering. Dynamo is a NoSQL (Not Only SQL) database. It’s largely cheaper to run than RDS/Aurora, and is fully serverless, but doesn’t enforce referential integrity (see here for an explanation). So if you can work with that (and being honest, you probably can) go for DynamoDB.

The name is a derivative of the storage system Dynamo (reference). This in turn is probably based on a physical dynamo, which turns kinetic energy (rotation) into electricity. I can’t work the link out, but it sounds cool

Elasticache

AWS has two offering for caching services, both under the banner of Elasticache. Redis and Memcached. There are reasons why you’d use one over the other, but I’m not going to go into that here (use Redis if you value your sanity). Again a fairly traceable name. Cache because it’s a cache, elastic because it implements elasticity in the same way the EC2 service does.

Redshift

This is AWS’s data warehousing solution, using columnar storage (most DB’s are row-based, with the notable exception of SybaseIQ. Take 10 imaginary points if you’ve heard of that before).

The name is based on one of 2 things, and I can’t find anything definitive to confirm either.

Option 1: Redshift is a physical phenomenon, and part of the doppler effect, where items getting further away appear red. This is usually due to expansion, so this could be the easy way you can expand the size of your redshift clusters.

Option 2: It’s a swipe at Oracle, who have a red logo. The idea being that teams would shift away from Oracle.

Take your pick which you believe. I think option 2 is more likely, but because I’m a nerd I like option 1 more.

Well-Architected Tool

This really dry name sits in front of a really useful tool (isn’t that always the way?). The well-architected tool is AWS’s attempt to automate some of the work their consultants were doing with their customers. Particularly around how best to setup their infrastructure against the well-architected framework:

Operational Excellence
Security
Reliability
Performance Efficiency
Cost Optimization

API Gateway

An API is an Application Programming Interface (but you knew that already, right?). API Gateway is an easy way to create and publish your API’s, so that you can use them with other services (both AWS and not).

The upshot of using API Gateway, rather than self-hosting your API, is it talks natively to other AWS services, including Cloudwatch. Meaning that you can monitor your API service just like any other AWS hosted service. And it’s PaaS.

Cloudfront

Cloudfront is AWS’s take on a CDN (Content Delivery Network. Can’t get away from these definitions that use more acronyms. Symptom of the industry I guess?).

Cloudfront is pretty cool, because it’s using AWS’s existing (and massive) network of servers. It talks natively to other AWS services, so you can include the setup/teardown of your CDN with your web-app deployment. Or make your S3-based static site globally available with really low effort.

Direct Connect

This creates a direct link between your data centre and the AWS backbone, so you’re not talking over a VPN. This is significantly faster than a VPN, and more consistent — no more spikes at peak times.

ASM

AWS Secrets Manager. To be fair this is usually just called Secrets Manager.

It manages secrets (key/pair usually) and allows you to refer to them via their ARN (Amazon Resource Name. I’m not defining ARNs any further because its not a tool as such). This gives you powerful options inside your resource stacks. Like not putting access keys or database passwords in source control, but referring to their ARN.

ACM

AWS Certificate Manager

It manages SSL/TLS certificates. Like ASM but for certificates. Same advantages really. It’s also one of two ways to attach SSL certificates to elastic load balancers. The other is via IAM, but ACM has a better interface & certificate rotation options, in my opinion.

Shield

DDoS protection. Sort of what it says on the tin. Works on OSi layer 3 or 4 (OSi model), 24/7 coverage, with a human on the other end for when the heuristics fall over. Nice price protection too — stops you running up a massive scaling bill because you’ve been DDoS’d.

WAF

Web Application Firewall. Firewall as a service at a basic level. At the advanced pricing level for Shield, this comes free. Which is nice.

Storage Gateway

This is a piece of kit that you put in your existing datacentre. It gives you access to the storage services (EBS, EFS, S3, etc) using standard network file transfer protocols (SMB, NFS, iSCSI). Could be viewed as a stepping stone to getting into the cloud, but I think it’s more aimed at being an easier backup solution.

Right. Break number two. Tea anyone?

The more obscure (but still on the exam)

These are not common in early-phase cloud adoptions, but are on the “AWS-SA-Assoc” exam. A couple of the more interesting names here.

Athena

Athena was (is?) the Greek goddess of wisdom, and the tool allows you to query files directing in S3, using SQL. Thus gaining wisdom?

QuickSight

Quicksight is the graphing tool you can use on top of AWS Athena, to give quick (in)sight into your data.

Glue

This is an ETL (Extract Transform Load) tool. ETL is used a lot when creating derived data sets (e.g. data aggregations). Essentially it’s “gluing” data back together.

Kinesis & Firehose

These are two different tools, but I’ve lumped them together because they’re used together quite a lot.

Kinesis is (loosely) Greek for movement, and that’s what it does. Moves data.

It comes in two forms Streams and Firehose.

Kinesis Streams take streaming data , lets you do transformations on the data, before outputting it. You could use this to dynamically change the content of a webpage as a user is interacting with it. Pretty cool huh?

Kinesis firehose allows you to continuously stream data from disparate inputs (like IoT devices) into either analytics tools (e.g. kinesis streams or custom lambdas) or S3.

OpsWorks

OpsWorks allows you to run your existing chef (and puppet) code in your AWS account. I think it’s called OpsWorks because in a traditional setup that’s the work of an Ops team.

That’s it. Simple. For once.

Config

This monitors your AWS estate and gives you some control over the change management, and compliance monitoring. Handy when you have a regulator to worry about.

Snowball & Snowmobile

These are cool. These are seriously cool.

They are variations on the theme of moving large amounts of data from an on-premises setup to AWS. The snowball is a box with a bunch of disks in and a shipping label. It connects to you network via Ethernet, and one type of snowball will do basic compute operations on the data whilst in-transit. The snowmobile is this, but bigger. Much bigger.

Comes with armed guards if you want them. Now bear with me whilst I pick my jaw up off the floor.

Last stretch now, hopefully the caffeine from the tea and coffee is still with you.

The “Cool” ones (but not on the exam)

These are good fun. They also have a habit of showing up at places like re:invent with flashy demos.

Polly

Want a cracker?

Amazon’s text-to-speech service. Uses machine learning to make natural-ish sounding voices. Pops up in a few training courses for the AWS-SA-Assoc exams, because it’s cool and makes an impact.

DeepRacer

Deep learning & racing cars. Cool.

This is/was/will be the main feature of 2019’s Re:Invent.

It’s a cool way to get started with reinforcement learning, but I can’t sell this better than Amazon can, so if you haven’t already, take a look at it here.

Sumerian

This was the language spoken in Sumer, and ancient mesopotamia (sort of where Iraq is now). How this turns into AR & VR with AWS I have no idea, but it does.

Lumberyard

A lumberyard is an American term (I think, not heard it in the UK before) for somewhere you buy large amounts of wood (called lumber).

AWS’s version is a game engine, for free, that integrates with Twitch (a game streaming platform that Amazon owns, but doesn’t publicise that they do).

Lumberyard itself is free, which is cool. You pay for the AWS resources (S3, EC2, probably lambdas) that you use, on their own pay-as-you-use pricing models, so you can work out your costs pretty easily.

I don’t actually write games, but if I did, I’d probably start with lumberyard. If only for the line in the licence that says:

57.10 Acceptable Use; Safety-Critical Systems. Your use of the Lumberyard Materials must comply with the AWS Acceptable Use Policy. The Lumberyard Materials are not intended for use with life-critical or safety-critical systems, such as use in operation of medical equipment, automated transportation systems, autonomous vehicles, aircraft or air traffic control, nuclear facilities, manned spacecraft, or military use in connection with live combat. However, this restriction will not apply in the event of the occurrence (certified by the United States Centers for Disease Control or successor body) of a widespread viral infection transmitted via bites or contact with bodily fluids that causes human corpses to reanimate and seek to consume living human flesh, blood, brain or nerve tissue and is likely to result in the fall of organized civilization.

Any service that has a zombie outbreak exemption is OK in my book.

END!

Yep. Bored now. Hopefully you made it this far and found this at least remotely useful.

Like I said at the start (but it’s worth saying again) reading this WILL NOT ensure you pass the AWS-SA-Assoc exam, but it might at least get a few of the tools to stay in your mind. Or maybe you’ll start playing with DeepRacer — just watch your billing though!

What’s In a Name? DevOps Edition

2019-01-19T14:00:00+00:00

I’ve been working in DevOps for a while now, and I’ve yet to come across a tool that didn’t have something odd about its name. It’s either got a backstory, a meaning, or it’s Greek. I don’t know why, but I’d postulate that it’s because the market is completely flooded with tools, and you need yours to stand out, so you can make money — either from the tool itself, or a support package.

With that in mind, I thought I’d translate them. In case you ever have the misfortune of having to explain to someone at C-Level (‘C’ as in CEO, not the swear word), why you’re trying to install an octopus.

I’ve listed them here, and linked to the explanation, so you don’t need to read the list. But please do, the stats are a great ego boost.

Docker
Jenkins
Bamboo
Drone
GoCD
Octopus Deploy
Ansible
Chef
Puppet
TeamCity
UrbanCodeDeploy
Consul
Vagrant
Kafka
Kubernetes
Terraform
Vault
Sentinel

Docker

The tool: creates, operates and managers containers.

The meaning: Containers are in a dock at some point. A “docker” is an occasional shorthand for someone that works at a dock, with containers.

Jenkins

The tool: General purpose CI tool. CD was retconned into it with plugins that let you write pipelines (which I happen to quite like).

The meaning: Stereotypical name for a butler. Butlers run households and “get stuff done” in a general purpose sort of way. Not to be confused with a valet (essentially a male equivalent of a lady’s maid). Also lots of creative definitions on UrbanDictionary, but I refuse to link to that (because no doubt someone will send me a bill for it).

Bamboo

The tool: CI/CD tool from Atlassian. Works with other Atlassian tools (jira, bitbucket etc.) much better than other tools as a result.

The meaning: Fast growing plant, not very nutritious, pandas eat a lot of it — this one doesn’t make sense to me.

Drone

The tool: Yet another CI/CD tool. This one runs in Docker, with pipelines written in a version of docker compose. I guess you could call it “container native”, if you like. They do.

The meaning: The proper name for most “worker” insects. And what every corporate employee feels like many times a day. Well, I do anyway.

GoCD

The tool: ANOTHER CD TOOL. The odd names are making more sense now… (This definition is a little unfair, because it’s actually a really good tool. Lots of built in functionality, runs on kubernetes really well.)

The meaning: It’s written in GoLang. You could take it to mean “Go and do CD”.

Octopus Deploy

The tool: One of the few deployment specific tools (outside of a couple of DB deployment tools) that I’ve come across. The sales pitch is that it gets you away from writing massive scripts. This will do the “heavy lifting” for you. Not sure I buy that. Not sure they do either, as they have a method of writing pipelines as code.

The meaning: Feels like someone thought they were being clever with this one — “an octopus has tentacles, we’ll call our remote agents tentacles”. Nice Octopus graphics though.

Ansible

The tool: Configuration management tool (there’s a few of these in the list, and in essence they all let you determine the state of a server in code). Uses YAML (Yet Another Markup Language) file to store its config. Steps are executed sequentially by default, so ordering is simple.

The meaning: I think this one is quite clever, if you like science fiction.

“The name of Ansible originally came from the book Rocannon’s World by Ursula Le Guin, published in 1966. She used the word as the name of an instantaneous communication device that would allow contact over vast interstellar distances” — https://h2g2.com/edited_entry/A1165501

I don’t know if that was the inspiration for the name, but I like to think it was.

Chef

The tool: Configuration management tool. Steps in “recipes”. Really nice interface.

The meaning: Chefs read cookbooks or create recipes to achieve the same end result each time (well, nearly. Depends on the restaurant. Hopefully the same isn’t true here).

Puppet

The tool: Configuration management tool (again). The IDE is called “geppetto”, which is nice. (Geppetto made Pinocchio, in case you didn’t know. I didn’t until I looked it up).

The meaning: You control a puppet on a set of strings from elsewhere. Puppet itself though is the other way around most of the time, as the deployment targets ask for the changes.

TeamCity

The tool: CI/CD tool from JetBrains (who make Intellij and a bunch of other tools).

The meaning: Erm. Right. No logic or clever backstory here that I could find. Seems like it was made to sell to large corporations — which to be honest, I can understand.

UrbanCodeDeploy

The tool: IBMs’ take on a deployment tool. The only tool I’ve found that doesn’t have a free trial or download, so I couldn’t try it out.

The meaning: I couldn’t find any reason behind this one, so I think it’s just a name.

Consul

The tool: Key/Value store from Hashicorp. Nice CLI and API’s. Also does service discovery, health-checking and DNS (via agents).

The meaning: This one makes absolutely no sense to me. A consul is an official appointed by a state to live in a foreign city and protect the states’ interests there — e.g. they work at the consulate.

Vagrant

The tool: Allows you to make quick and cheap virtual PC’s on your existing physical PC. Saves you the pain of having to use VirtualBox/VMWare tools directly. Although you do still have to install them.

The meaning: Colloquialism for a wandering beggar. If you do a little mental gymnastics you can see where they were going with this — person of no fixed address, virtual PC with no permanent home.

Kafka

The tool: Used for building realtime data streams.

The meaning: Apparently it’s named after Franz Kafka.

Kubernetes

The tool: Kubernetes is a “container orchestration tool”. Which translates to it controls large amounts of containers

The meaning: Loosely translated from Greek as a helmsman, or habour pilot. Essentially a controller. Yes the spelling is a bit different, but you can see the logic here.

Terraform

The tool: Infrastructure as code from HashiCorp. Lets you make anything in the major cloud providers, and manages their state. So that if someone changes something by hand, terraform can correct it.

The meaning: SciFi staple. Changing the environment to suit you. We (as in the species) might do it to Mars (the planet, not the chocolate) one day.

Vault

The tool: Keeps data secure, only known people have the keys. Can seal/unseal/re-key. Various access policies

The meaning: Another analogy. Not a Hollywood vault with a big room behind 1 massive door, but more a vault with lots of safety deposit boxes in it. For a film reference I’d go with “The Bank Job (2008)”.

Sentinel

The tool: Policies as code. Works with other HashiCorp tools (enterprise version, you’ve got to pay for this one) to ensure that they are only used in a pre-defined manner. Lots of good examples on their website, go check it out.

The meaning: Sentinels guard or watch things to ensure that people don’t do things they aren’t meant to. Typically military personnel.

Wrapping up

Right, that’s it for now, because I’ve run out of brain. If you’ve made it to this point I’m impressed. If you’ve skimmed the list to see if there’s a witty final statement “hi, waves”. If you only wanted to see what Sentinel was and saw me waving, I don’t blame you.

I’ll try to post a follow up at some point as I find/try/use more tools — particularly ones with “odd” names. If there’s any you’ve come across and I’ve missed, or if you have a better reason/definition for any I do have drop me a comment.

Hopefully this (very dry, quite boring) list saves you a bit of a headache, or gives you one, who knows. I promise next time I’ll write about something interesting and maybe grind an axe for a bit.