Way back in January 2012, when I started a new role at Amazon, I needed to learn how to code using Ruby and Rails. As a personal exercise, I decided to put together a simple blog platform using the language and framework not only to get my feet wet, but also because I didn’t like the idea of using another platform like Wordpress; I wanted to have intimate knowledge of how it worked and be able to make changes to it on a whim if I wanted.
The requirements I had were pretty straightforward: * Written entirely in Ruby and Rails. * Learn something new to bolster my “tool box” of skills. * Be able to create, read, update and delete posts. * Be able to tag posts so they’d be able to be categorized. * Use a single blogging platform for multiple domains and have the posts that are shown for each domain be relevant for only that domain, including being able to show the same post across multiple blogs. * Use media wiki to format the text. I used this format on a daily basis so it made sense at the time to use this.
Thus, my blogs were born: one for personal stuff (family and friends), and another for more technical stuff that I want to share with the world. Let’s be honest though, it’s usually just for me, apart from the occasional recruiter that contacts me on LinkedIn that mention my blog. I haven’t written to them very often (my last post was in September of 2018, and before that it was 6 years earlier), but I do aspire to write more often than I do, which has caused me to give more thought into my blogs lately.
There are a number of things that get in the way my writing posts, the least of which is having many commitments in my day-to-day (work and family mostly). It’s also the lack of accessibility in writing them, however. Like every other hobby-like thing in my life, I need to be able to maximize the little time that I have which means planning and being able to make gradual progress; sometimes a few minutes here and a few minutes there. In a nutshell, being able to write posts where ever any free time presents itself. In order to do that, I would ideally have an app on my phone that would let me keep track of post ideas, and put them together and post them whenever I can.
Another, perhaps more important thing, is having something compelling to write about. You don’t just start a blog for the sake of doing so. You do it because you have some knowledge or experience to share. While I’ve been able to write a thing or two over the years that satisfy that requirement, I’ve never been able to do it consistently, both because I wasn’t spending a lot of my free time doing things that I felt like sharing, and because I wasn’t in and found it difficult to get into the habit.
Finally, there are constantly so many cool things being done in the tech space, and being able to experiment with those things and do things that generally take me out of my comfort zone, will help keep me fresh and not stagnate in my career. The urge in me to continually learn new and interesting things is enough that rolling my own software is the best option. Being able to share those things with people is really exciting to me. If I can help show somebody the ropes, or to help plant a seed in somebody’s head for their own ideas, then I feel very rewarded.
While putting together a blog with Rails was a great exercise for me at the time, my career has been heading in a different direction the last 3 years or so. While my current role does include some front-end work, it’s minimal at best. Most of what I do is back-end work, and it’s starting to move into the pure AWS space, as opposed to some AWS, and some internal Amazon stuff (though there’s still a lot of that). With my team starting to head in that direction, I’d like to be able to learn more about AWS services and how they can help solve the problems I’m keen on solving (personally and professionally). This seems like a good opportunity to rewrite my blog platform using AWS services and other frameworks, languages, etc. to put together the full stack. This is not going to be a small amount of work, but I think it will be interesting enough that it will keep me engaged through to the end, and I’m hoping that my experience can help other people putting together similar projects. I’d also be keen on putting all the source code up on Github so others can benefit as much as possible.
I’ve already started on some of this work, and the rabbit hole is a bit deeper than this, but I’ll get to the other details in subsequent posts.I should note that I’m trying to design the full stack in such a way that it can essentially scale infinitely, though I realize that my blog in particular doesn’t need to. As this point, most of the stuff that I have planned should be easily accommodated by the AWS free tier. To that end, here’s my high-level plan for putting this all together.
Except where otherwise mentioned, I’ll be writing most of the code for this project in Java, which is the language I’m most comfortable with. When using Java, most of the new stuff I’m learning will be related to AWS services or different frameworks. There will be other components later on that will provide new learning in different languages. I’ll also be using Maven for dependency management.
The AWS CDK (Cloud Development Kit) was introduced in July, 2019. It’s a framework that allows you to write code in Java, TypeScript, and others that generate Cloud Formation configuration to deploy your CFN stacks. It takes care of a lot of the heavy lifting for you, and adds very user-friendly APIs to manage permissions and other aspects of CloudFormation, not to mention the ability to auto-complete your code in whatever IDE that you use. I’ve used this a bit for a small project at work and am smitten.
I’ll start by defining the APIs that will be needed to create blogs, articles, tags, etc. via AWS API Gateway. Defining how you want to interact with a system is a great first step, which will help define the implementation details more formally. I want to use the OpenAPI specification to define the APIs and create the API Gateway end points to make the process as easy and maintainable as possible. While the group that defined OpenAPI has tools to generate code based on those specifications, I wasn’t able to find one that works with API Gateway, and certainly not the CDK as it’s fairly new. It’ll require writing some custom code to generate the APIs using the CDK.
I’ll be using DynamoDB to store all the data needed for the blogs. While I’ve thought about blogs from a relational perspective, pushing the data into Dynamo will force me to think in a non-relational way.
Ever since SwiftUI was announced at WWDC earlier this year, I’ve been really excited to jump into it to build an app. I think the blog platform will be the perfect opportunity to do so as it should be fairly straight-forward once the API is defined and implemented.
Along the way, I’m willing to wager that there are several other tools or technologies that I’ll need to learn in order to implement the platform as effectively as possible. The fact that I already have a blog platform in place means I don’t have to rush through this, but rather I can do it right. Beyond that there may be some other not needed but nice to have things I could learn such as setting up a continuous integration environment using AWS Code Commit, Build and Deploy. As the project grows, any sort of automation that I can implement may help save time in the long run (help me utilize my time as best as possible), and also be far more fun than doing things manually.
This is a pretty big project, and has a lot of bits and pieces that need to come together in order to make the whole. Turning anything into a habit can take quite a while; not the 21 days that I’ve previously heard. I don’t want to overcommit myself, which I’ve shown is something I typically do, especially when it comes to writing. To that end, I’m going to commit to writing an average of 12 articles over the next year that will gradually document the effort I go through to get all this stuff setup, including migrating all my previous posts from my Rails/PostgreSQL stack. Some of them will be longer than others, and I may even do more than that as I run into problems, or new tech that I want to take a stab at to solve a particular problem. Expect some tangents as I go.
As a final note, since I’m most comfortable writing in Markdown, but my current blog implementation only understands mediawiki, I’ll be using Pandoc to convert to that format, until I get the current platform up and running. I’ll likely also use it to convert all of my existing articles over to Markdown. We’ll cross that bridge when I get there.
In my last post I talked a bit about my desire to give recreating my blog using AWS, and in particular using a serverless setup (API Gateway -> Lambda, etc). One of the things i failed to mention is that I’ve already been working on this off an don for a while and already gotten deep into what’s needed to get it done. My general intention for these posts is a sort of development journal, documenting what I’m doing, the issues that I ran into, ways that I ended up fixing those problems, and general thought process I went through to get things done.
Since I’ve already started working on this, I’d like to share what I’ve gone through so far, to get more or less up to date, and then start doing proper journal-like entries. I’ve already started to take notes for some of my future posts, but for the time being, let’s get started on what I’ve done so far.
While I’ve worked with AWS services on and off for years, the number of services that I’ve been exposed to have been minimal; generally S3, DynamoDB, and a smattering of others, none of which I would claim to have any sort of serious expertise in (especially given how quickly the services are built upon and improved). My current team at Amazon spent the last year building up a service using mainly the serverless model that I’m going for with my blog platform using Cloud Formation (essentially configuration to define AWS infrastructure). I’ve had some opportunities to make changes to the CloudFormation configuration, but I didn’t find updating the YAML to be very friendly or fun.
When the CDK’s GA was announced in July, I was excited by the prospect of putting a user-friendly layer on top of Cloud Formation and started to experiment with it a bit to understand how the APIs work in general and to setup some infrastructure as well.
If you found the idea of writing code to create infrastructure, with all the bells and whistles you expect from an IDE experience intriguing, then a great place to start would be the CDK Workshop that the CDK team put together. It will walk you through the prerequisites for which ever language you choose (though I expect to be doing all of the implementation in Java), as well as walk you through setting up your first application. This makes for a good jumping off point for playing around with creating and updating new resources. This experimenting has also helped me to understand the different AWS services that I’ll be using at a much more fundamental level. Being able to use auto-complete to make suggestions is awesome.
Starting hear will allow you to get up to speed on things in preparation for the next post.
This whole project is intended to be a thorough deep-dive on the entire process from beginning to end. I’ll be sharing as much as I can as I go. I may go on some tangents here or there if I find that I keep doing things the hard way. I basically want to automate as much of the process as possible. I’ll try and keep any tangents I go on as separate posts so you can know ahead of time what you want to read and what you want to avoid, though I hope that all the posts will be helpful in some way.
In my next post, I’ll go through some example code for defining an API in API Gateway, and why doing so with out-of-the-box CDK code won’t scale.