How do you begin architecting a solution in AWS? Part 1

Every so often we may be presented with an idea or business problem that needs to be solved. Often as engineers or architects we are the ones that are presented with the challenge of coming up with a way to solve it. Do you ever wonder "Where do I start?". In this series of blog posts, I will break down how I like to approach these to deliver a solution that works.

Use case

Let's say we wanted to create a shorturl service that anyone on the internet could use hosting it in AWS. For this use case, we will keep the feature set fairly basic. We want to be able to:

• Create a short URL

We want a user to be able to go to our website http://urlshort.com/ for example, input a long URL that they want shortened and have this optionally emailed to the for their records.

The short URL will look something like http://urlshort.com/XmPLe which would be in place of a longer URL such as http://mywebsite.mydomain.com/downloads/2021/april/files/private/shared/trailer.mov

• Access the real URL using the short url

We want a user to be able to enter the short URL http://urlshort.com/XmPLe into their web browser and be redirected to the real URL such as http://mywebsite.mydomain.com/downloads/2021/april/files/private/shared/trailer.mov

Beginning the process

The stages of my process usually follows a pattern similar to this:

1. If I was to do this as a human, what does the process look like from a high level or how would I do this physically?

• Lets say the long url is someone's name and address (real URL / value) that they have asked me to store. I could write these details in a green notebook (website/frontend and datastore). Each name and address would appear on its own page in the notebook starting from 1. Let's say we have 10 different entries across 10 pages numbered 1 – 10 (keys). With this we have a way to translate a short url (key) to a real url (value).
• If I or the user wanted to add a new entry, I would open the green notebook, go to an empty page, say page 11, check if it is empty. If it is, I would enter new details. If it was not empty, I would go to the next page (creating a different key) until I found an empty one to create the entry (API / backend logic).
• After creating a new entry, I might write down the key on a piece of paper saying "Dave's details are on page 11 in the green notebook" and hand this back to the requester to share with anyone they wanted to (notifying a user to remind them where the details are).
• Someone might come to me and say "I want to see the details at number 7 as I need to retrieve/use this address". I would go to the green notebook, find the key or page "7" and get the details. From there I would return the details to the requester (API / backend logic).

This analogy and human process translates to what our shorturl service would be doing.

2. "How would I mirror that human process and do this using a single machine/server ONCE?"

One way could be to create a text file in a folder with a unique name and add the information I need stored inside that text file. If we follow the number pattern from 0, our file name would be 0.txt and our real url would be stored inside that file. To retrieve the details I'd open the file and copy / paste the url into the browser.

The goal here isn't to work out the most efficient way to do this once. It's just to do it once. Working out the most efficient way will come later. We generally refer to that type of thing as an "implementation detail" which is something to be solved later.

3. "How would I do this TWICE? How would I do this X times?"

If we refer back to point 2, we have a very basic approach to doing this once. Doing multiple times could range from a number of approaches.

• One way would be a program/script with a menu. One option would prompt the user for a value to be stored, the script generates a unique file to store the value and gives the user the filename as a key. Another option on the menu would prompt the user for the key. Once input, opens the file, reads the value and returns this to the user.
• You could also use the previous approach but store the data differently. You may choose to store all the data in one file, like a json file called urls.json and append new entries to the file.
• You may even also install a small database on the local server to store your data there.

Again, the goal here aren't to work out the most efficient way to do this; it's just to get a feel for our options.

4. What are the main components we have identified?

For example "Do we need a webpage? Do we need to store any data? How / where do we store the data? etc". So far it would look like we need the following to meet our use case:

• A website / frontend (for users to input the real url details)
• A datastore (to store details of the short / real url)
• A backend API or program (to create, add and retrieve values from the datastore)
• A way to send notifications (to let a user know the details of the short url)

Once I have covered these main areas to form a basic outline of the main components, I would then be able to evaluate which AWS services fit the use case.

Important considerations

It is important to remember this is one of many approaches when trying to come up with a solution to implement. As there is some ambiguity in the use case in what exactly is required (5 Pillars of the AWS Well Architected Framework anyone?), we would likely have more questions to clarify the requirements and not do more (or less) than is required. This approach can help us to avoid skipping steps and optimise for a better solution. However in the "real world" there are a number of other important considerations that you should factor in with your approach. Some of these include but not limited to:

• How much time and resource do we have to finish the project?
• What are the cost constraints?
• What are the absolute "red lines" or boundaries that cannot be crossed? For example stakeholder / business deadline, must meet a regulatory standard or data must be kept for minimum of 5 years for reporting etc
• Do we have to learn new technology? Can this be done without affecting a currently deployed application?
• What sort of performance do we need? Do we need it to be highly available, fault tolerant, redundant, secure and scalable?
• Do you want a monolith solution or make use of a microservices architecture?

Coming up in Part 2

In the next blog post we will begin to look at each of the main components and evaluate which AWS Service or combination of services would help us achieve an end to end solution.