My previous post explained how AWS S3 could to be configured to host a static website. However, AWS S3 static website hosting might not provide all the necessary options required by modern Single-Page Applications, nor the flexibility to handle custom domains or SSL certificates. This blog post will demonstrate how AWS CloudFront can sit on top (or in front) of AWS S3 to provide a more fine-tuned web service.
Lately I have been working on a single-page application (SPA). From a high-level perspective, the goal is to provide a documentation portal for a set of RESTful APIs. The APIs themselves were designed with Swagger, so all information could be easily discovered and consumed from the Swagger output (JSON file containing path, resource definitions, security details, so on). Additional information, not provided by Swagger, is written in markdown files and presented in a separate location (things like getting started guides, how to authenticate, so on).
With the reoccurring need of PowerShell to manage infrastructure setup, monitoring and deployment, it's vastly important that we have the right tools in place in order to keep PowerShell scripts organized and properly maintained. Nowadays, the development of software applications require a common set of strategies/practices so developers can feel confident about making new changes and/or refactoring existing code. Techniques like test-driven development are quite common in the object-oriented programming world. Unfortunately, when it comes to infrastructure code, developers tend to ignore the same strategies. Mostly due to time constrains or the lack of reliable tools to test PowerShell, Shell or Batch scripts.
As you might have noticed, I have been absent from this blog from the last couple of months. Not that I ran out of topics or I don’t want to share my opinions, it’s just “life got in the way”. Putting it bluntly, my priorities shifted so I choose to spend more time doing other tasks. Obviously, I could spare a few minutes here and there to write a new blog post, but sometimes you just need a long period of reflection to observe and rethink what to do next.
OpenSSL became publicly known (unfortunately) for the wrong reasons. Their development team got the typical backlash that System Administrators usually get: if everything is working fine nobody cares, as soon as something bad happens everybody loses their mind. I'm obviously talking about the Heartbleed bug. Before Heartbleed was found, it was estimated that 61% of all Apache servers used OpenSSL to handle TLS/SSL connections. As soon as it was found a lot of people freaked out. Successfully using this exploit could allow an attacker to read a target server memory, extract its private key and ultimately mount a man-in-the-middle attack . On the other hand, OpenSSL development team consisted of 11 contributors and a budget of less than $1 million a year (most of it from donations). In a world where even large Corporations, with almost unlimited resources, consistently release buggy software, a team of eleven developers should be allowed to make a few mistakes.