I recently completed my challenge of spending at least 1 hour a day learning about (serverless) cloud for 100 days almost* in a row.

In this post, I summarise the main topics I covered and the best resources for each, the projects I built, and some lessons for future self-directed learning projects.

*It took me 114 days - with a pandemic and some vacation time thrown in, that's close enough I think!

Topics and resources

The topics that I spent the most time on and found the best resources for were:

1. Fundamentals and the serverless landscape

2. Data modelling with DynamoDB

3. Best practices and design patterns

4. The business case for 'serviceful serverless'

Fundamentals and the serverless landscape

Despite having an AWS SAA cert and having used AWS at work before the challenge, a key focus for me was gaining a stronger foundation by really understanding the serverless landscape, including tools, best practices, and design patterns.

For this, my favourites were:

• Off-by-none: Jeremy Daly's weekly serverless newsletter. More resources than you have time to read, but always some great stuff for all levels in there.

• Serverless Stack: an excellent, free resource that gets you going with building a full-stack project using React and Serverless Framework. Having an opinionated guide with links to further best practices and little tricks (like this one) was a life-saver.

• Serverless Airline Booking and its accompanying Twitch streams (14+ hours of content). Covers a lot of ground despite not assuming much prior knowledge.

• Real-World Serverless: no fluff podcast that goes in-depth on best practices, architectures, and more. I have listened to all the episodes until now.

Data modelling with DynamoDB

I spent a good chunk of days on NoSQL data modelling with DynamoDB using various resources and applying the lessons to my Virtual Watercooler project.

My favourite resources were:

• This episode of Serverless Chats (also a great podcast) with Alex DeBrie.

• Alex DeBrie's re:Invent talk.

• Once I'd watched Alex's talk, I graduated to Rick Houlihan's talk.

• After the talks, I read Alex DeBrie's excellent and well-named book, The DynamoDB Book.

• The NoSQL Workbench was an excellent thinking tool when applying the lessons.

Best practices and design patterns

Due to the dizzying and constantly increasing number of serverless building blocks, having good examples and understanding best practices to combine them into solid microservices within solid overall architectures is essential.

My favourite resources were:

• Jeremy Daly's summary of 19 serverless Microservice Patterns. Excellent reference. Explains e.g. the 'Frugal Consumer' and 'Scalable Webhook' patterns used in my Virtual Watercooler project to cope with a maximum emails-per-second limit for SES.

• Serverless Application Lens. Quite readable paper from AWS giving detail on various serverless architectures and considerations.

• The intro and linked video in this article by Yan Cui. Gave me the idea to use Algolia as a 'serverless ElasticSearch' and DynamoDB Streams to trigger a Lambda that synchs changes to it in my Sentimental Robot project.

• These episodes of the 'Real World Serverless' podcast:

  • Episode 15 with Ben Kahoe from iRobot.
  • Episode 18 (with Aleksandar Simovic and Slobodan Stojanovic) and 22 (with Gojko Adzic) contain good discussion of hexagonal architecture (Ports & Adapters).

The business case for 'serviceful serverless'

Spending so much time on serverless while working in a very 'servermore' (?) environment at work prompted a lot of thinking about this topic. I've got a ton of notes, so will have to write about it soon.

Some great resources are:

• Joe Emison's The Serverless Sea Change. Coining the term 'Serviceful Serverless'.

• These episodes of the 'Real World Serverless' podcast:

  • Episodes 2 and 3 with Joe Emison.
  • Episode 17 with Aleksandar Simovic and Slobodan Stojanovic talking about e.g. 'FinDev' and Wardley Maps.
  • Episode 24 with Zack Kanter from Stedi.

• Some good discussion about serverless for start-ups between Nader Dabit and Tom McLaughlin in these three threads: one, two, three.

• This was a great thread to illustrate both (a) a ridiculously small AWS bill and (b) the internet (Alex DeBrie) helping make it even smaller.

• Cloud Programming Simplified: A Berkeley View on Serverless Computing. 35 page paper with the bold claim that serverless 'represents an evolution that parallels the transition from assembly language to high-level programming languages'.

Projects

The majority of my learning was structured around the following projects. Whenever I learnt something new, I would go back and apply it to these.

Virtual Watercooler

Allows you to create an 'organisation', add members to it, and then randomly pair members for coffee chats - either by clicking a button or by choosing a frequency.

Backend tech stack: DynamoDB (single-table design), API Gateway, Cognito, Lambda (Javascript), SQS, SES, Cloudwatch, s3, and CloudFront. All packaged up with Serverless Framework.

Code available here. Wrote this to help me confirm that my approach to letting admins schedule recurring chats made sense.

Sentimental Robot

Scrapes BBC news headlines each morning, runs them through sentiment analysis, and allows the user to search through headlines and sentiments, or just get an overview of the past few days' sentiment. Had already started this but built a lot on top during the challenge.

Backend tech stack: Algolia, DynamoDB and DynamoDB Streams, Comprehend, CloudWatch, API Gateway, Lambda (Javascript), s3, CloudFront. All except Algolia packaged up with Serverless Framework.

Code available here.

ForgotMyGlasses

Tend to forget your glasses? No problem, teach the robot what your friends look like and use it to help you recognise them in the wild.

Backend tech stack: Rekognition, Lambda (Javascript), Cognito Identity Pool (unauthenticated role), and Cloudwatch. Using Serverless Framework as always.

Code available here.

SimpleQuiz (in progress)

Started this right at the end of the challenge. Decided on the data model and got a basic real-time connection working with subscriptions.

Backend tech stack: AppSync (GraphQL), DynamoDB, Lambda (Javascript), Cognito Identity Pool (unauthenticated role), and a few more probably.

Lessons for future learning projects

Open-ended 'benchmark projects'

For my learning, I like to define what Scott Young calls 'benchmark projects', where you pick something that you cannot do right now, but you might be able to do if you improved your skills, e.g. earning a difficult cloud certification.

This strategy worked well for me for the challenge. Had I tried to define specific topics and learning objectives at the start, I'd have failed as I simply did not have enough of a foundation to do so. The learning objectives I'd have set on Day 0, would have hindered rather than helped me on Day 20.

Had I set a more concrete goal or planned my journey in more detail at the start, for example, I'd never have spent the 30 or so hours on NoSQL data modelling that I enjoyed so much.

Instead, I set the goal of building 2 - 3 relatively 'production-ready' fully serverless projects and let that guide my learning. On day one I started building, and then discovered the missing pieces (such as NoSQL data modelling) I needed to fill in.

I wasn't interested in earning another certification (there aren't any fully serverless ones), but I think that would've been an excellent way to guide learning as well.

Learning vs. reporting

At the start, I stuck diligently to reporting progress and learning every single day. Gradually, I ran into two problems, however. Firstly, as topics got more advanced, I did not always have much to report from a day's worth of learning. Additionally, some days I only had 60 minutes available, so reporting would steal away scarce learning time (with the potential to get distracted on Twitter along the way).

In short, I started having more fun and being more effective once I switched to reporting by progress rather than daily. Sometimes that meant grouping 2 - 3 days, sometimes it was daily. But fitting reporting around the learning rather than the other way around is how I'd approach future projects like this.

Becoming 'active on the internet'

Since I stopped playing World of Warcraft and Counter Strike many years ago, I'd become mostly an 'observer' on the internet.

Seeing the 100 Days of Cloud community grow on Twitter and Discord, frequently reporting progress on Twitter, and following other people's learning challenges was super rewarding and got me back into being 'active on the internet'.

'Learning in public' like this is extremely powerful, making for better learning, networking, and accountability all in one. For my future projects, I'd need a very good excuse not to build or learn 'in public'.

Feedback or questions?

I'd love to know if you found this helpful, got any questions I might be able to help with on your cloud journey, or have feedback for me. Twitter or Linkedin are the best places to connect.