Asaf Zamir – Chief Technology Officer & AI/Cloud Consultant. Founder of CloudExpat, AZdev. Author of Coder to CTO.

Using GitHub Actions to deploy your static website to S3?

Great!

Using AWS S3 Sync command?

Amazing!

Did you make sure you have the `--size-only` flag on?

Without `--size-only`, your entire bucket will be uploaded each time your push to your branch. This includes contents that haven't changed at all.

Why?

By default, AWS S3 Sync compares the timestamp of your source and destination files. If the timestamp doesn't match - the file will be uploaded. This is a problem, since the files are newly created on each build (they are checked out as part of the workflow). To ensure only size is compared, use the `--size-only` flag like so:p.s. You may have noticed I've also excluded the .git/ and .github/ folders.

You're welcome ;)

I respectfully disagree with the arguments made on Last Week in AWS against Serverless.

Regarding portability issues

The problem described is down to architecture. Do you need to add logic that handles the API Gateway? Yes. Does it have to be an integral part of your Lambda functions? No. In the majority of Serverless stacks that I've seen, the handling of the API Gateway event (think auth, middleware, different content types, etc.) is done in a separate package and can be relatively easily re-implemented for another Cloud provider. I do accept the premise of AWS Step Functions being the exception to this rule, but I don't believe they are absolutely necessary (nor do they feel productive to work with). Most Step Functions structure can be replaced by either a Queue or Messaging system, depending on the requirements.

Regarding the perceived value fallacy

Essentially the argument is about the limited impact savings Serverless could bring to the table compared to the overall budget. One critical thing isn't taken into account - The inevitable DevOps department. I have seen plenty of early stage startup with 5-10 engineers and zero DevOps. Nearly in every one of those cases they were able to do that by going either fully managed (e.g. Vercel, Auth0) or fully Serverless. Those saved salaries count for much more than the net savings on the infrastructure budget.

Regarding the difficulty of collaboration compared to WordPress

It is unclear in your argument whether those collaborators were writers or engineers, but I'm assuming writers. I do agree that it is much easier to write articles using WordPress than your home-made lean Serverless solution. This however completely misses the point. It is not WordPress the writers are missing, it is the WYSIWYG editor (In WordPress's case - Gutenberg). There are plenty of full-featured Markdown editors that can directly save to GitHub. A website generator such as Hugo could easily connect those repositories with your website and presto! Writers are happy again.