Subscribe to Cat Facts!
I like cats.
Wait. I don’t think you understand. I really like cats.
You remember that joke eHarmony video about the lady who loves cats.
I’m that person.
A while back there was this cat facts text conversation. I really liked the idea of subscribing to something like this and was also looking for an excuse to try another AWS service. So I made it.
I’ve ported the page from my old website and you can now find it here.
Like many of the projects you will see on here, the architectural decisions behind Cat Facts were heavily weighted in terms of a low cost solution. This means that the actual implemented architecture is different from what I would propose for a corporate environment.
The total cost of this solution is $0.00.
That’s right. It costs me absolutely nothing to run this service. And that’s due a carefully selection of AWS services and trade offs which I’ll detail below.
It’s also due to some rounding. AWS charges per Gb of hosted content in S3. My entire costs of S3 is currently $0.01 per month. I think it’s unfair to charge this cent to Cat Facts. This would be covered under the free tier if the account was under a year old.
The current implemented architecture looks like this:
I’ve already talked about S3. It’s great for hosting static content. It’s basically free cost wise and basically worry free as well. I use it and recommend it for serving any static content.
As an aside, missing from this diagram is CloudFront. Prior to migrating Cat Facts to this blog, there was no CDN in between the S3 bucket and the end user. In order to maintain simplicity, I’ve kept it out of this diagram.
Huh? S3 back again?
S3 is an object store and can be used for storing more than static websites. Instead of storing all the facts in a database that charges hourly, I put all the facts into a text file and dropped them in S3 as well.
These facts are stored in a seperate S3 bucket to the webpage that is not publicly accessible. Although, all the facts are available in the GitHub repository. This was not entirely necessary as access control can be configured on a per object basis. I opted for a bucketwise solution out of convenience.
Cognito is Amazon’s authentication and authorisation service. It’s touted as a mobile service, but it’s applicable use extended far beyond this.
Cognito is used to provide access to AWS resources and services to logged in users. Authentication can be handled by Cognito or via configured 3rd party services such as Facebook or Google. Once authenticated, Cognito talks to AWS Identity and Access Management to provide a role which enables access to configured services. Unauthenticated users may also receive a role if this has been configured.
As Cat Facts is intended to be publicly available, there is no authentication, only authorisation. The unauthenticated Cognito role for Cat Facts allows access to the make subscription requests to the Cat Facts SNS topic. The role does not allow access to anything else and so is secure for the purposes layed out.
Due to the lack of authentication, it is possible for any user to sign up any email address. This could be considered a security flaw, however as this is intended to be a mock spam service it’s considered a feature here.
Those familiar with AWS services might notice this choice of service is quite strange.
The obvious service of choice here would be the Simple Email Service (SES). SES offers rich formatting, monitoring, email receiving, authentication and much more. All of which is unnecessary for Cat Facts.
The Simple Notification Service (SNS) on the other hand offers more useful features. SNS offers automated subscription management, SMS (txt messaging) and lots of other stuff that’s irrelevent to Cat Facts. But the automated scubscription management was the key selling point of this service.
If Cat Facts was using SES instead of SNS it would have to manage subscriptions itself. This would mean a lot of extra work:
The downside is that Cat Facts looks even more like spam, as it cannot embed images, or links or anything pretty. It’s also forced to come from firstname.lastname@example.org and has an ugly footer that includes a link to Amazon support.
As with most projects you’ll see here, cost and convenience wins out.
Serverless is great. AWS Lambda is great. It ticks all the boxes, it really does.
The only downside is that it’s stateless, but that’s easily solvable in conjunction with other services.
The Lambda function for Cat Facts runs weekly and follows this process:
:3to the line. That’s a cats face
This process takes less than 5 second, uses hardly any memory and costs nothing, as it’s under the free usage of AWS. This free usage is for all accounts and not just new ones. Bonus.
This Lambda function requires permission only to access the specific facts file and publish to the Cat Facts SNS topic. It is not publicly accessible and is completely secure.
I will be the first to acknowledge that Cat Facts is unlikely to exist in a corporate environment in isolation. You will likely want to include Dog Facts, Bird Facts or even Fish Facts!
Jokes aside, the primary use case behind Cat Facts (a subscribable weekly mailing list) is a popular addition to many online services and the proposed architecture is worth being analysed.
There are two recommendations for the architecture of Cat Facts in a corporate environment.
The architectures differ on the web components only.
Recommendation 1 is a typical monolithic architecture while recommendation 2 is a microservice architecture. Each solution makes use of the most effect AWS services for the designs.
Recommendation 1 utilises an autoscaling web layer that serves the application to the user. This is typical of modern architectures and well understood. The group scales horizontally to increase capability as load increases. This can be handled automatically through AWS alerts captured via AWS Cloud or manually through calling the AWS API.
The entire application and all components will exist on a each virtual machine. It’s possible to place a content delivery network (CDN) in front of the web layer to increase caching if desired.
Recommendation 2 utilises an serverless microservice API architecture with static resources stored in an S3 bucket. Microservices are the new hot trend, and in conjunction with AWS Lambda and API Gateway, can cut a lot of costs without sacrificing performance.
I’ve documented the benefits of S3 already in this article and strong stand by it as a tool for serving static content. In a corporate environment it is recommended to add a content delivery network (CDN) in front to increase performance.
For a production environment it is useful to have a full database to capture data. This may include user data or other statistics. Having a database will increase costs but also increase performance.
AWS offers a number of different managed databases and the right one for any project heavily depends on the data to be captured and the teams skill set.
I will detail the differences between AWS database services in a later post. Watch this space.
The obvious change was to replace SES with the real email service.
Having a rich, fully configurable email service is vital for any online business. Having full control over your mailing lists becomes a positive for rather than a negative when the driving factor of success is not implementation and service cost.
You may notice that there is a random cat image on the page. This image is provided via The Cat API. They like cats too.
When I originally developed Cat Facts SMS via SNS was only available to American phone numbers so I did not implement it. Now it is supported so this is something I will likely add in the future.
There are enough facts to run Cat Facts for the next 3 years without intervention.
I really like cats, and I really like Cat Facts.
I hope you will subscribe.
If you enjoyed the content please consider leaving a comment, sharing or hiring me.