In the last post we set up our deployment, fully automated on merge to our main branch. In this post we will be building our UI (Frontend) applications. See the full overview of posts here.

At the end of this post we will have:

• A Next.js Frontend app with support for localization, using Tailwind CSS.
• A Leptos Rust/WASM Frontend app with support for localization, using Tailwind CSS.
• Automatic deployment of our Apps AWS using CDK, statically hosted using S3 + CloudFront.

We are essentially hedging our bets by building both a JavaScript-based Frontend, which is the safe bet, and a Rust/WASM-based Frontend, which is the future bet. We will be using the same GraphQL API for both, so we can easily switch between them.

There is quite a lot to cover. My recommendation is to clone down the Part 3 branch in the GitHub repository and use this post as an explanation of what is set up.

Read more →

In the last post we created our Control Tower structure with all of our AWS Accounts in it. In this post we will be automating our deployment process for each of these environments. See the full overview of posts here.

At the end of this post we will have:

• A workflow for bootstrapping our AWS Accounts for CDK (see here).
• A workflow for deploying our CDK stacks, including synthesizing and testing before (see here).
• Set up automatic staggered deployments when changes are merged to our main branch.
• And fallback to manual deployments if we need to.

If you want to jump straight to the code, you can find it in the GitHub repository which links directly to the Part 2 branch.

Otherwise, let’s jump in!

Read more →

In the last post we went over the overall goals of “The Stack” and what we will be building. In this post we’ll be setting up our AWS Account structure. See the full overview of posts here.

• Set up Control Tower
  • Step 1
  • Step 2
  • Step 3
  • Step 4
  • Step 5
  • Cleanup
• Adjusting Account Factory defaults
• Set up our Development Organizational Unit
• Set up our AWS Accounts
• Next Steps

As a reminder, here is the structure we are aiming for:

• Control Tower: This is your central place to control access and policies for all accounts in your organization
• Production Multi-tenant: Your primary production account for multi-tenant setup, and most likely were the majority of users will be
• Production Single-tenant: While desirable to avoid the operation overhead for single-tenant setups, its good to think in this from the get-go
• Integration Test: This will be the account that IaC deployments get tested on to ensure rollout works
• Preview: This will be used to spin up Preview Environments later on
• Individual Developer: Individual developer accounts to allow easy testing of IaC testing and exploration
• Monitoring: Centralize monitoring and observability into one account, allowing access to insights without access to sensitive logs or infrastructure from the other accounts
• Logs: Centralized storage of logs, which may require different access considerations than metrics and traces

Read more →

This will be a series of blog posts where we will build up the perfect infrastructure setup for the majority of usecase, aka “The Stack”. We’ll be building everything on top of AWS.

Before diving in, let’s first establish some goals:

• Performant: Latency and performance is important as this will serve end-users.
• Low cost: We want our base cost to be low, and our costs to scale well with high traffic. Ideally, it should cost nothing if no users are using it.
• Low operational overhead: It’s >=2023, nobody wants to nurse servers or services anymore, things should scale up and down without intervention or oversight.
• High flexibility: Everything should be built with the foresight of future scalability, both organizationally, code-wise, and in the way things fit together.
• Modular: Pieces of the infrastructure should be opt-out, e.g. if you don’t need Pub/Sub, it can be skipped.

Obviously, this is my personal opinion on it, but I’ll be sharing the thinking behind each of the choices as we go along.

Some technology choices upfront:

• Everything will be infrastructure as code using AWS CDK.
• We’ll be using Rust throughout for each service, as it allows us to squeeze out the most performance while still giving us a nice developer experience.
• Federated GraphQL will be our way of facilitating microservices.

Read more →

Recently I was faced with the challenge of having to migrate a set of AWS DynamoDB tables to completely new tables. We wanted to achieve this without affecting any of our users, and without having a maintenance window while migrating data from the old table to the new ones.

The following will be a very high-level overview of how you:

• Get all your DynamoDB events onto a queue
• Replicate your DynamoDB tables to the new tables (or even a different region)
• Continuously synchronize your original tables to your new tables
  • Restart the migration if you made an error
• Complete the switchover after validating everything looks OK

Read more →

Having recently discovered sameroom.io I wanted to update the codetalk IRC server to be compliant with their authentication method. This basically just meant enabling SASL support, but while I was tinkering with stuff anyways, I thought I might as well streamline the setup process for the IRC server. In short, everything is fully automated and set up on AWS using EC2 and S3.

This will go through the process of doing exactly that, by talking about:

• enabling SASL support
• installing UnrealIRCd
• installing Anope
• a little about automating the launch of the EC2 instance that the IRC server will run on, using the user-data field as input for a setup script.
• all the important files gathered in a github repo

Read more →

I have recently started caring a bit more about security on my AWS applications, and to this end Identity & Access Management (IAM) users are a great way to limit access to a need-to-use-only basis.

Recently I set up my IRC server to download its configuration and install files from an S3 bucket. This meant that it needed to have read access to a specific bucket, and for this an IAM role was created.

There are two ways to generate policies:

• Using the policy generator
• Manually creating a policy

I will generally advise to either use the generator completely or at least use it for the basis of the policy you want to create.

Read more →