This January at D55 we decided to create a quick project for all new and budding AWS users out there – a basic Serverless social media site.

Why?

At D55 we are passionate about a few things – our clients, our tech and our people. We want our clients to get the best out of cloud-based technologies, using the latest AWS services with best practices so they can achieve their own objectives. And we want our teams to have opportunities to expand on their cloud knowledge in every direction, in areas that they are passionate in, and that D55 can utilise for our customers.

For this reason, we encourage all of our crew to achieve AWS certifications. In fact, we consider them a key part of our strategy, to keep a level of knowledge across our teams, and a way of constantly expanding our learning as a company and as individuals. We also want everyone to have as much ‘real’ experience with the services they are learning about, and while gamified learning platforms like AWS Cloud Quest can help, but they tend to have only one way of solving a problem and involve a lot of copying code or following pre-written steps. We wanted to give people the chance to experiment, finding what works and what doesn’t, and discover new and more efficient ways of building solutions. And we want to work with, expand and contribute to the wider AWS community. That’s the reason we took part in, and won, the AWS GameDay World Championships in 2022, why we have launched our own DeepRacer Team and why we attend and contribute to AWS events throughout the year.

But why a Serverless Twitter Clone?

It’s been widely believed by many that Twitter’s infrastructure is mainly “on-prem” - that is they buy, maintain and use a lot of their own servers around the world, rather than use the services of a cloud provider like AWS. That is not entirely true, but it made us think; what would an entirely serverless social media platform look like? Twitter has in many ways been a victim of its own success; Jack Dorsey has admitted he grew the company ‘Too quickly’. But serverless architecture is designed with such expansion in mind: elasticity is one of its central tenets. Twitter was notorious during its early years for outages at peak use – the Fail Whale is synonymous with overstrained servers. Well-architected cloud infrastructure should be, by its very definition, highly available. The exercise we’ve created is a very simplified example, but AWS services like Lambda, DynamoDB, CDK and others allow extremely speedy development and iteration – combine that with a well-constructed DevOps setup and developers have the tools to develop at pace, and to demand.

The Stack

The main benefit to any serverless architecture is that it frees us from the day-to-day maintenance of our underlying infrastructure. We simply ask for what we need, and AWS provides it. If we need more of a particular service, we provision more, and if we need less, we simply scale back down. When not being used, the services should cost us little to nothing to operate. This is known as elasticity; the service should expand and contract to meet our demands, and with serverless technology, this process is usually automated for us, so we can be confident that no matter how busy our applications become, we have the capacity to handle it.

For this project, we’ve kept it simple. A standard web application’s backend has 3 layers:

1. An API layer.
2. A Compute layer.
3. A data storage layer.

We’ll keep the same structure, but use AWS’ “Traditional” serverless services instead:

1. APIGateway for the API layer.
2. AWS Lambda for compute.
3. DynamoDb for our data storage.

D55 are Lambda, APIGateway and DynamoDB Delivery specialists, so naturally we’d choose this path! But remember this is just a ‘serving suggestion’. If you want to experiment with different services, go for it! There’s no ‘right’ answer to this solution, and many ways to achieve the same effect.

Infrastructure as code

There are a few options for provisioning your AWS services. To start with you can use the AWS Management Console, using your browser to click and pick your infrastructure. Or you can use the AWS CLI, typing your requests into your computer terminal.

At D55 we use Infrastructure as Code for all of our provisioning. It makes our infrastructure dependable, predictable and repeatable. IaC also comes in different flavours on AWS: you can use SAM (Serverless Application Model), Elastic Beanstalk, and our preferred method, CDK. All these ultimately produce CloudFormation templates, which AWS uses to provide you with the services you ask for.

CDK (Cloud Development Kit) lets you use familiar coding languages like Typescript, C#, Python and Go to describe the infrastructure, it then synthesises the templates and deploys them to CloudFormation. We like this approach because it allows us to use programming idioms like variables, loops and conditional logic in our provisioning. We can also unit test it like you would any other lines of code. For this example project we are going to be using a basic CDK setup, and we’ve done most of the setup for you. If you want to learn more about how to build your own projects using CDK, start here.

The project

We’ve built a basic front-end web page for you – you can find it here. It’s a static web page built using Svelte and hosted on another of AWS’ services, S3. You can use it to test your solution once you’ve built it.

When you’re ready, clone the backend repo here and take a look through the readme file. All the instructions you need to build your backend are in there. You should only need to edit one file, and in its simplest form you should only need a few lines of code, but remember, there is no right or wrong answer, and feel free to experiment!

If you build something cool or interesting, let us know! And if you’ve got any questions feel free to reach out.

And finally, if you want to work with World Championship-winning AWS specialists to craft and perfect your AWS workloads, book an appointment and find out more.