About this blog

This is a brief introduction on this blog. It describes the overall architecture and some of the design decisions behind it.

Q&A

What is the purpose of this blog?

Describe how to use certain features of AWS in a simpler way. As of June/2019, AWS has twenty-three categories of products. EC2 by itself holds a lot of subproducts (VPC, ELB, Auto Scale, etc). All products in AWS are quite complex to use, due to the customization options present on each. This blog will bring some of those into more specific scenarios, some of them real use-cases - for instance, this blog itself is a use-case of the so-called "serverless" AWS architecture.
Does the world need another blog?

No. There's a lot of good blogs out about AWS already. This includes the official AWS blog. This blog is a egocentric endeavor, for practicing AWS skills, as well as document writing. Everything published here should be useful in general, that's why there will be some effort to structure it in a didactic way.
Why AWS instead of other providers?

Lack of knowledge. Other cloud providers definitely have good products, but the focus here is exclusive on AWS products. There may be opportunities for other parties, such as using GitHub instead of CodeCommit, but only when the intrinsic value is much higher to the reader. Using the GitHub example, it is better to use it for public code than using CodeCommit with public access.
Will this only talk about AWS?

There may be an eventual comparison, if it brings value to the explanation, but they won't be common. As an example, which will be further described later, Markdown compilation is done using Github API due to the specificity of the service. Spinning up a Markdown compiler in Lambda would take more effort
What is the target audience?

AWS professionals and enthusiasts looking for a practical approach of AWS products.

Architecture

This is a simplified view of the architecture of this blog:

The authoer uploads markdown files and images to an S3 bucket. Images triggers a lambda function to resize it to a standard size and markdowns are compiled to HTML fragments. The MD compiler is provided by GitHub.

Compiled fragments are tagged in a DynamoDB table and used by an extra Lambda function to create the index files.

This means all content becomes static and stored in S3. CloudFront is used to distribute said content, with Lambda@Edge being responsible for applying the HTML template before caching and sending the result back to the viewer.

Assumptions

There is only a single author

This allows a first version with a simpler design, without post ownership or more complex editors. Any markdown editor suffices, and files can be uploaded directly to S3.
Templates and navigation do not change often

Whenever the template needs to change, we have to do a CloudFront invalidation to update it without facing UI inconsistencies. Such operation can be expensive, since the invalidation itself have a cost and can take a while to happen due to Edge latencies. Same applies to changes in navigation (i.e. how indexes are constructed), since the whole page catalog is static.
Minimal effort to operate

Currently, the author is the operator as well. Simple daily operations means more focus on writing content instead of keeping this content on-line.
Frugal (free-tier, if possible)

The author is also the financial owner, so anything that can be done to save some money can be given back to viewers. If the blog can handle millions of views a day and cost the same as it cost for dozens of views per month, then money can be invested on more products, which means more content for this blog.

Architectural Q&A

Why custom-made instead of de-facto solutions like LAMP+Wordpress?

In one sentence: "Eat your own dog food". It is easy to discuss AWS products in abstract high-level ways. Amazon does a good job on that in AWS website and blog. IT bloggers with Wordpress sites are also doing a great job. But documented real-world examples are hard to find.

This also opens the possibility of using different AWS technologies, such as Lambda@Edge, without feeling "forced". It would be harder to justify all costs in time and operations to have a load-balanced EC2 fleet holding a Wordpress cached by ElastiCache when you can just go to WordPress.com and have all of that for free.
Why Markdown?

Markdown is easy to write, without requiring specific custom editors. Some IDEs, like Visual Studio Code have embedded MD visualizers - this is almost WYSIWYG (one can say this would be closer to "What You See Is What You Mean").
Why not HTML+CSS

The classic web combo is more verbose when providing the same structure level. Even with newer HTML5 tags, such as <section> or <header>, there is a lot of manual effort to keep a well-defined structure.

Arbitrary HTML can still be embedded in Markdown, allowing customization when needed, but an entire post written in HTML would definitely require a form of custom editor to be productive.
Then, why not a custom editor?

A custom editor brings a lot of benefits (specially if WYSIWYG), but their output is not optimal. Short-term, this does not matter, since you have results immediately. Long-term you will definitely face issues if you want to migrate out of your current renderer.

If you ever migrated data out of a Wordpress or MediaWiki, you know the issue. It requires a lot of effort to cleanup the generated HTML, and MediaWiki's custom markup is too specific to be reused.

Most blogs don't need complex markup. Only a small list of elements any you are ready to go. For instance, this blog supports this markup:
```
# Title (also used by the index parser)

Text

## Sections

Long paragraphs with [links](http://link).

![Occasional Image](img.png)

> Quote (not used in this page)

* **Questions**
  Answers

  ```
  code
  ```

1. Numbered lists
1. etc 
```
Due to its simplicity, it is not impossible to replace or extend the GitHub compiler. For instance, the parser adds extra HTML tags to images, allowing them to be horizontally centered.
Is this "serverless"?

As defined by AWS, yes.
Why "serverless"?

Given the current scale of this blog, it would not be different to use a LAMP stack. If you don't care about applying security patches (note: you should), then a EC2 instance running Apache, MySQL and Wordpress will run for years without interruption or maintenance.

But, if you care about your infrastructure, then serverless is easier to maintain. There is no server to be patched or rebooted.

Costs are also smaller, since there is no idle infrastructure.