I already spoiled in my first post (Hello World!) about deciding on WordPress as the Content Management System (CMS) for this blog and when finishing the KISS and COD post I also mentioned that WordPress was the chosen one after reevaluating Flutter. I think it is now time for us to double click on the decisions/technology/stack/cloud provider and ask a lot of questions because as we discussed in the previous post more questions = Better decisions!
Do you see how everything is connected? It is NEVER about tech only!
This is where things don't go linear and it is very hard for me to write a narrative on how it happened but I'll do my best! One thing that I have decided early was to host this blog on Amazon Web Services (AWS) mainly because most of my past cloud experience was with Microsoft Azure, I wanted to learn something new and why not to take a look on what the market leader is doing? Also, honestly, if you pick any of the 3 major cloud providers and stick with one you should be in good hands.
Ok, now that this is settled, the hardest questions start floating:
What is the simplest and fastest way to get a blog out there in AWS? Should I use a CMS?
Remember KISS and COD here
It is a hard question to answer. A static site with pages would probably do it, something like MkDocs would be sufficient for the initial needs and easy do deploy. But I could complicate things a little bit and work on my first Jamstack project! Sounds cool but it won't be the fastest way to put something out there for sure, maybe an evolution would be to use a Jamstack and as I said in the previous blog post, this is where CMS shine! Ready-to-ship, simple to deploy, good interface to manage your content (posts, pages, images, etc.), many themes, a full ecosystem with plug-ins and apps to extend your blog/site to almost whatever you want.
Well, even for a simple thing like CMS selection there are plenty of options nowadays! The frontrunners in blog usage are: WordPress, Ghost and Strapi.
Functionality wise, they are all very similar and with very simple steps you can deploy locally to test out and why not? Let's do some quick "It works in my machine" testing!
But what should I test in this Proof of Concept (PoC)?
I told this was not a linear thing
In order to do some meaningful comparison, I created a quick site map for the blog (image below) to bring more clarity in my head on what were the main pages (e.g.: check out some Recommendations I have added for you dear reader!) and functionalities (like being able to comment on a post) I would consider for the blog and selected a few things to test from my initial prioritized features/capabilities list (we already covered this in the features/capabilities blog post):
I told you it was all connected
- Able to create a blog post and comment
- Implement a "progress bar" for reading and "reading time" for posts
- Check templates/themes options to see if there is any free one that would speed up the blog launch
- Plug-ins extensibility: Send e-mails and Google analytics integration (at a minimum)
Hosting
Ok, tested everything locally and all passed to the next phase some quick and easy test in AWS to see what are the hosting options now!
DO NOT FORGET TO DELETE THOSE TEST INSTANCES AS SOON AS YOU FINISH THE TESTS! SAVE MONEY PLEASE!
If you ask me, I would love to put everything in a docker container to make things scalable and with different availability zones to guarantee reliability (and maybe I'll do that later on the road just for fun/learning/cost comparison) but... do I really need that to start? what is the cost to make all of that happen? Is it worth for the expected ~100 different users per month?
Selecting the services you need from a public cloud provider comes with more questions and just to complicate things a little more as there is a ever growing list of new services. Last time I checked, AWS passed the 300+ mark on different services and googling about blog hosting options that are cheap and easy/fast I came across AWS Lightsail:
- It is one of the cheapest services in AWS costing 3.5 USD per month (3 months for free to try out)
- You can use the Bitnami WordPress and Ghost images pre-configured (bye bye Strapi?)
- No need to configure other services (such as Route 53 for DNS or S3 for storage)
- Easy snapshot backup (less work for me sweet!)
CMS Selection
Finally! OMG how long to get to this point!
With Lightsail settled, if I REALLY wanted to stick with Strapi, I could probably get a regular linux machine in Lightsail and configure it there, but with pre-built images for WordPress and Ghost, It was time to say good bye to Strapi.
Like the cloud providers, I think if I either picked WordPress or Ghost here I would be just fine as both offered everything I think I need. Also, I haven't worked with any of them so great to learn something new. The things that made the case for WordPress were:
- WordPress simply dominates the entire web with 37% market share, Ghost is in the 2% area
- Much bigger community and dedicated good posts to answer my google questions
- Lots of themes available
- Lots of plug-ins available
The think that I liked more in Ghost is that it uses Markdown natively for writing posts. Could I do it with WordPress? Of course I can can with a plug-in (damn this thing is extensible! there is almost a plug-in for anything I want to do). Being able to use Markdown to write posts is important for me because when deciding things for this blog one of the crucial decision I made for my content was to write posts and pages using Markdown.
Which brings us to talk about Lock-in and the importance of shifting the focus for decisions.
Lock-in
We are almost finishing it!
Just to clear things out a little bit before we start: There is always some level of vendor lock-in. You can use a vendor software, an open source project or you can build your stuff, if later on you decide to switch technology/framework/cloud provider there will be a cost, some time and effort you will have to put on that will be associated with this decision to move to something else.
So, if there is always some level of lock-in, why Markdown? What is the benefit?
I think that the biggest benefit is to treat text I write here as code. This is amazing with many positive things such as storing the blog Markdown files in a free GitHub repository along with the images and everything else I think is important for this blog. Also, I get great version control for my text and an easy way to compare what I wrote yesterday before changing this paragraph entirely with the power of Git! Finally, I can use Visual Studio Code to write on my personal laptop or use the repo link directly to change stuff using the browser.
Also, it will help with reducing lock-in. If later on I decide to change from WordPress to something else (even if my heart wins the battle and I decide on Flutter again) markdown will act like the translator between all those different worlds!
Just DECIDE and move on!
I promise this is the last part!
Now, if you want to make better decisions, the focus should not be in the technology or framework to use (in this case which CMS to use) because this can be changed easily in the future! The key here is shift the decision and focus on the stuff that is hard to change (in this case deciding on using markdown for the posts/pages and storing the important blog stuff on a git repository). Martin Fowler said this in 2003 (this is not new folks!):
"I think that one of an architect’s most important tasks is to remove architecture by finding ways to eliminate irreversibility in software designs"
Martin Fowler - Who Needs an Architect?
Just acknowledge that some lock-in will always exist and be happy with the decisions you made!
A bad (but intentional) decision is 100x better than making no decision at all!