One of the biggest barriers to going serverless is getting through the mental hurdles of using other people’s services to create your architecture. It’s not always natural if you come from traditional software development and can take some practice. But don’t worry — if I can serverless, you can too — and I’m going to show you how.

AWS has services for almost everything so let’s see how we can put these to good use in building a complicated mobile app. There’s no code ahead — this is purely an architectural exercise for anyone nervous about designing for serverless!

And don’t worry — there are endless ways to build this same app, so if you have other ideas, let me know in the comments.

Welcome to the zoo

Our client has a zoo. It has 25,000 visitors a day, with up to 50,000 during special events and holidays. The zoo features 100 separate exhibits.

They need to create a mobile app for visitors to drive engagement and repeat visits. They expect around 50% of visitors will use the app because they will promote discounted tickets for app users.

I met with the zoo owners and this is what they told me:

It should be downloadable from the standard app stores.

Offer both anonymous and logged in modes, supporting common social logins and maybe custom email/password authentication.

Visitors can use their location at enclosures to learn about the animals, and scan barcodes hidden around to learn about any one of the zoo’s non-human guests.

All users can watch videos relating to the exhibits, but logged in users get exclusive content.

Visitors can upload photos but we have to ensure the content is appropriate — remember, there are kids around.

Visitors will receive alerts when they are in the zoo, pushed by zookeepers for feeding time and ‘Meet the Animal’ lectures.

They would like disabled visitors to have access to text-to-speech for any placards located around the facility.

Translation for overseas visitors would be great (covering as many languages as possible since everyone in the world comes here).

Visitors can “like” an exhibit and receive alerts when significant events happen.

This need to be thoroughly tested and “just work” because they have limited IT support available and cannot manage app problems from 25,000 guests a day. And of course they expect 100% up-time.

It looks like we have our work cut out, so let’s brainstorm on how serverless can get this done. I put all the major items on Post-Its so we can keep track:

Why not just use the ‘old way’ to make the app?

If we didn’t have serverless, this would be very complicated. This client doesn’t have much IT help so it will be a difficult project with ongoing maintenance. We will need to work out how many servers are needed to support potentially 25–50k users on a daily basis. We will need iPhone and Android development teams with a testing strategy for handling all the most popular devices.

We also require OAuth setups with the main social providers and a user database somewhere, along with all the password management and reset processes. Then there’s video hosting, but we can’t use YouTube because some of the content is gated. To build all this out, we will have to consider how many developers are needed and the sort of maintenance overhead for this kind of infrastructure.

The goal of the serverless approach is to really minimize most of what’s in the last two paragraphs. From a practical standpoint, a large amount of your development budget and personnel can disappear in racking-and-stacking hardware, and managing authorization, databases and mobile deployments.

Part of the “serverless mindset”, as Ben Kehoe calls it, is redeploying all those resources into building valuable functionality that your customers can see, touch and care about. This is all about customers — our zoo visitors care less about our infrastructure and more about when the giraffes will be fed.

Shorty The Giraffe is counting on you! Credit: https://www.freepik.com/free-vector/giraffe-portrait-cartoon-style_1195871.htm

The broad requirements

There are few requirements that aren’t specifically serverless but in the spirit of using managed services and being frugal with our resources, we should address these up front:

We could build this as a web application using a single-page application framework like React or Vue. But the zoo owners really want an app, and it sounds like they will send push notifications for special offers at some point in the future (sounds like an extra requirement?).

The front-end work is out of scope for this exercise but we should look at cross-platform mobile development to avoid building the same app twice for iOS and Android. React Native could be good option, and so could Flutter. Either way, we want the front-end to be a manageable and easy to build.

Testing mobile apps is tricky and, due to the proliferation of Android versions and devices out there, can be cumbersome. The owners didn’t really say much about this but with minimal IT help, automating this process is clearly going to be helpful. AWS Device Farm provides an automated solution to this problem using a massive fleet of actual devices.

This is also a good time to find services or requirements that might not fit the budget of the client. For example, the 100% up-time requirement will be expensive to architect but if the zoo is prepared to accept 99.99% up-time (unavailable for less than 1 hour a year), this significantly changes what we need to build and makes a huge difference to cost. The trade-offs are really important to consider before we start building.

What services do we need?

The very first step in figuring this out is looking at services you might need, and you can deduce some of these from the requirements. I scribbled my immediate thoughts down (red for data-related items and blue for everything else):

For data-related items:

Video hosting requires only S3 for storage and we can deliver the content through CloudFront . In this case, CloudFront can also help us restrict some content for logged-in users using signed URLs or cookies.

for storage and we can deliver the content through . In this case, CloudFront can also help us restrict some content for logged-in users using signed URLs or cookies. The photo uploads can also be stored in S3 . Some image recognition will go a long way to helping us detect appropriate images — maybe Rekognition?

. Some image recognition will go a long way to helping us detect appropriate images — maybe Rekognition? There’s going to be a list of daily events and alerts from zookeepers — I think we can manage the schedule in DynamoDB . The alerts I’ll cover a little later.

. The alerts I’ll cover a little later. The authentication described is fairly ordinary and can be handled by Cognito. This also supports tracking of anonymous users so we can remember settings and preferences if the user later converts to a logged-in user.

For everything else:

For text-to-speech, we’ll use Amazon Polly to create the audio, which we then store in S3 for playback.

to create the audio, which we then store in S3 for playback. Language translation can be achieved with Amazon Translate , which currently supports 21 languages from English.

, which currently supports 21 languages from English. For exhibits alerts we could use SNS to allow visitors to subscribe to exhibits.

This phase is a broad sketch but it gives us an idea of which services we will wire up. Each one of these tools is a fully managed service so we just need to know how they work and how to connect them.

Handling the text, images and videos

For binary data like images and videos, S3 is always the obvious choice. In fact, by integrating some Lambda functions that run when new objects arrive, we can make S3 the workhorse behind much of this functionality.

The zoo app could have an S3 bucket with folders for each exhibit, structured like this:

Each sub-folder represents types of content in the system:

When exhibit descriptions are saved by a zoo administrator, this fires a Lambda function which calls AWS Translate to convert the text into other languages, and stores the results in language-specific folders (‘es’, ‘de’, ‘it’, etc.). This solves the translation problem because it only needs to happen once each time the content is updated (and not when end-users switch languages).

are saved by a zoo administrator, this fires a Lambda function which calls AWS Translate to convert the text into other languages, and stores the results in language-specific folders (‘es’, ‘de’, ‘it’, etc.). This solves the translation problem because it only needs to happen once each time the content is updated (and not when end-users switch languages). Description changes can also trigger a Lambda that sends the file to Polly — we can save the resulting speech in the audio folder and playback whenever a user requests. This can be done for multiple languages.

folder and playback whenever a user requests. This can be done for multiple languages. When videos are saved, this event triggers a Lambda which uses Elastic Transcoder or the Elemental MediaConvert service to reprocess video for different sizes and prepare for viewing on demand. This will help with performance and bandwidth costs. It only needs to happen once per uploaded video.

Finally, for user-generated photos, we will use a separate bucket that triggers a Lambda to analyze the photo in Rekognition. We can use the moderation labels in this service to find unsafe content, and we can detect if the photo is an animal. We can examine the response from Rekognition and decide what to do next — if it’s borderline or suspect, we will flag the image for a moderator before adding to the primary bucket’s images folder:

The zoo schedule

For upcoming events throughout the day, let’s use a DynamoDB table to store information about feedings, lectures and other zoo events. Visitors only care about the events for the current day while they are in the zoo: