This week I learned a lot about AWS, and I need to write it down before I forget it again. If you came here for high drama, I apologise; if you came here for information on the AWS Python CDK, you’re in luck (and a tragic minority)

AWS(hit)

I am writing this after five hours of sleep, because I was awake until 3.30am wrestling with the AWS Cloud Development Kit. It is immensely powerful, and a real pleasure to work with – I’ve talked before about the really pleasing way you can treat massive pieces of infrastructure as Python objects, and manipulate them in the same way. This is jusAWS(hit)t very neat, for example:

class CatFeeder(Construct):
    def __init__(self, scope: Construct, feeder_id: str, **kwargs):
        super().__init__(scope, feeder_id, **kwargs)
        feeder = Bucket(scope, "feeder")
        cat = User(scope, "Rocket")
        feeder.grant_read_write(cat)

That is, we can create a Python object, we can use regular Python methods, and in doing so we construct an S3 Bucket, a User, and grant that use permissions to read and write to that bucket. It’s readable, it’s pythonic, and it’s clear.

If it’s so easy, why on earth was I up until 3.30? Was I just having too much fun?

No, dear reader. I was not. I was up until 3.30am because I was struggling specifically with AWS’s continuous integration/continuous deployment tool, CodePipeline.

CodePipeline does something that’s a bit magic, and I do not like magic. The reason I don’t like magic is that it’s just reality by different rules, and I barely understand the ones we’ve got. It synthesizes itself. That is, you write the instructions in Python, and it synthesizes those instructions (one of which is creating itself!) and deploys them. This is why you need to deploy it once first, but also why if the synthesize step fails it’s stuck – because it’s eating its own tail. It can’t synthesize your fix, because it’s broken, and it needs to be working in order to synthesize the fix – the fix that’s only needed because it’s broken.

class MentorMatchPipeline(Stack):
    def __init__(self, scope: Construct, construct_id: str, **kwargs):
        super().__init__(scope, construct_id, **kwargs)
        pipeline = CodePipeline(self, "MentorMatchPipeline",
                                pipeline_name="Pipeline",
                                synth=ShellStep("Synth",
                                                input=CodePipelineSource.git_hub("mentor-matching-online/mentor-match", "main"),
                                                commands=["npm install -g aws-cdk",
                                                          "cd mentor-match-infra",
                                                          "python -m pip install -r requirements.txt",
                                                          "cdk synth"],
                                                primary_output_directory="mentor-match-infra/cdk.out"
                                                )
                                )

This code is taken from the mentoring project I’ve been working on. An incomplete list of the things that tripped me up:

• you need to put a GitHub token into AWS Secrets Manager, as plaintext. It must have the name github-token
• the GitHub token needs sufficient scope to install a webhook and, if the repo is private, to read from it
• if the step marked synth fails, you need to re-deploy the entire Stack. Just adding a new commit is, annoyingly, not enough. The pipeline will keep using its old version until you forcibly re-deploy it. This feels very stupid.
• the step marked synth will fail if you’ve made a mistake anywhere in your infrastructure. Check that it at least synthesizes by running cdk synth before you commit. I’d like to write/find a wee pre-commit hook to do that for me.
• despite being a Python object, the only way I’ve found of testing it is deploying it. Every commit therefore becomes a little bit spicy
• in order to deploy into your own account, you need to bootstrap permissions to do that. The command is

cdk bootstrap aws://ACCOUNT-NUMBER/REGION --profile ADMIN-PROFILE \
    --cloudformation-execution-policies arn:aws:iam::aws:policy/AdministratorAccess \
    --trust PIPELINE-ACCOUNT-NUMBER

• don’t forget to commit cdk.context.json, because otherwise the tooling account (where you have your pipeline) won’t be able to deploy into your deployment accounts, even if they’re the same account, because this thing is locked down like the White House on Guy Fawkes
• if your cdk.out is somewhere non-standard, don’t forget to add that as a line. For me, that’s primary_output_directory="mentor-match-infra/cdk.out"
• if you delete a Stack of resources while some are still being created, AWS gets incredibly confused and sulks for several hours. And blocks your pipeline
• Your main Stack will define a Pipeline which will define one or more Stages which are comprised of one or more Stacks which, if you’ll remember, is what we defined at the beginning. There is a continuous sense of chasing your tail with this stuff, but it’s got that programming feel, that Everything is an object, even the things that describe objects

Despite all this, I am still finding it absolutely thrilling. There’s a clear sense of something here that I can work with, that I can get really darn good at. And it’s so fantastically compelling. It reminds me very much of the beginning of my career.

Work

Work is going well! I’ve got a decently large chunk of work to do, and I finished up something on Thursday that I presented at Show and Tell on Friday. It’s going to help the operations side of our team, and I’m really glad that I’ve got to do something for them. This sprint it’s all stuff I care about – it’s even more CDK (see above) as I look at firming up the security around our infrastructure.

I chatted to my manager about something that’s been bothering me, and we agreed a plan to monitor it. My manager is genuinely very good, and is one of the reasons I can see myself sticking around longer than I expected. A good manager is an incredible force multiplier.

MiSc

A slower week this week. It’s interactive and interesting, while also highlighting that most of the folks writing standards do it as part of their job at MassiveCo, or BigGovernment. These standards aren’t always so useful for smaller organisations, and don’t offer anything for smaller organisations. To a certain extent, folks like NCSC with their Cyber Essentials standard are filling that space, but by and large SMEs are not well-supported in this field. There might be an interesting project there – but then again, maybe not? I suspect each case is unique enough that there’s not more to be done than just encouraging folks towards Cyber Essentials.