JUN

Serverless For Startups | A Conversation With Slobodan

Reading Time: 3 minutes

Table Of Contents

Last week, our CTO and Resident AWS Serverless Hero here at Vacation Tracker, Slobodan had an interesting conversation with James Beswick, who is the Principal Developer Advocate for the AWS Serverless Team.

What exactly was their conversation about? Why going serverless is better — especially at startups.

Most of us are non-technical common people with no prior knowledge of how these things work whatsoever. As such, you might find yourself wondering, what exactly does going serverless mean?

However complex this concept may seem to you, it can be easily explained in simple words. Let us break down everything Slobodan and James discussed, along with some useful information about using serverless systems in startups you might find interesting.

What does “serverless” mean, anyway?

A serverless architecture lets developers create and run applications without managing servers.

In simpler words, serverless architecture is an approach to software design that allows developers to build and run services without having to manage the underlying infrastructure. The developers usually write and deploy code, while a cloud provider allows servers to run their applications, databases, and storage systems at any scale.

Going Serverless at Vacation Tracker

Working at a bootstrapped startup such as Vacation Tracker meant that Slobodan had to deal with a limited budget while deciding on infrastructure for their product.

However, after a lot of trial and error, as of today Vacation Tracker runs (almost completely) 100% serverless. But what lessons did they learn along the way? And more importantly, how did they get there?

The Vacation Tracker story

The idea behind creating a leave tracking system called Vacation Tracker came into fruition in 2016 when Slobodan’s team at Cloud Horizon (his other company) was unable to find a solution to their own leave management problems.

A failed internal hackathon and a long search for a seemingly “perfect” leave tracking app that wasn’t too complex and was easy to use led to the creation of their own the following year in 2017. The app started off as a small prototype that Slobodan created, which basically connects someone to a function. The function here was primarily to give users the ability to request leaves through a Slackbot.

At the time, even without a backend and with just a single landing page, Slobodan and his team began to see people signing up. “All this was for a product that didn’t exist at the moment,” he says.

With 2017 being such a good year for Cloud Horizon, the idea behind the app was put on the back burner. However, demand for the product stayed consistent and people began asking for it. Finally, in 2018, Slobodan’s team began working on the app known today as Vacation Tracker.

The architecture v0.1

Slobodan says that he opted to go serverless (albeit not 100%) from the very first version of Vacation Tracker. This was primarily because of the following reasons:

He had a small team without much DevOps experience
Going serverless meant everything was auto-scalable
It was secure enough at the time
Building a prototype didn’t take long
And most importantly, it was cheap!

As Vacation Tracker grew to over 100 paying teams, Slobodan quickly realized that they needed to improve their architecture because they had designed a product that people wanted to use. As a result, the team began building a 100% complex serverless application using Infrastructure-as-a-code.

Finding a good architecture

The team moved all operations to an IAAC cloud formation soon after they crossed around 150 Lambda functions. They also added TypeScript, and finally replaced MongoDB with DynamoDB.

As a result, they benefitted from independent deployments, the infrastructure was still scalable, and they had almost a 100% uptime out-of-the-box. However, on the flip side, they noticed that they were only storing states, not events. Furthermore, they had issues onboarding new developers, who didn’t particularly like YAML. They also noticed that they were wasting more time on less important things.

Take two

Once Vacation Tracker reached 600 paying teams, Slobodan found that Command Query Responsibility Segregation (CQRS) worked really well for Vacation Tracker.

It’s basically an event-driven system where everything is stored as an event inside the system. And this was crucial for a leave management system like theirs where most records are stored as events, such as Ana (a user) creating a location and moving John and Mike there.

What’s happening currently?

As of today, Vacation Tracker has around 193 Lambda functions in production within its software. As a result, they have a fully managed GraphQL, lesser code, they have better control, Monorepo, and all the benefits from the previous architecture. Everything is written in TypeScript and stored inside one big repository that shares different data. Slobodan says they host it on AWS. At the moment, the application infrastructure costs them $0 (excluding the cost of the tools that they use, such as MailChimp).

Vacation Tracker also has a few groups of services, each with a few AWS Lambda functions and other AWS services.

To learn more about the challenges Slobodan and his team faced in going 100% serverless at Vacation Tracker, skip to the 26:27 mark on this Youtube video, or watch the whole thing to watch everything we discussed in this article!