Serverless, MVP of Your Project

The fastest way for your product to go into the market with less cost.

This article was written as an individual review assignment for PPL CSUI 2021

In my personal opinion, one of the most interesting parts of building a new project is deciding what architecture that we will use. there are so many concepts of architecture that are already used by many dev teams in this world, such as client-server architecture, monolith architecture, microservice architecture and I’m sure there is plenty more architecture that I do not mention. But, we need to consider many aspects and factors when deciding which architecture is the fittest for your project's requirements. the factors are but are not limited to, deadlines, cost, traffic, team resource, and many more factors that we need to consider.

When we need our products to be fast as possible to go into the market, then we need the MVP(Most Viable Product) as fast as possible. using microservices as the architecture will not be a good approach because it’s very hard to make a working distributed system at a tight deadline. Monolith maybe will be a good approach, but what if I can offer you another approach that will be easier and cheaper than adopting monolith? also remember it will be a pain to scale a monolith project. Let me introduce you to the underdog, Serverless architecture.

Serverless, don’t misunderstand it as not using a server at all, instead, Serverless is a concept that lets the cloud provider(AWS, GCP, Azure, etc) execute our piece of code and dynamically allocating the resource. the reason why it’s much cheaper than deploying our monolith into a traditional server is, we will be only charged when the resource is used, and if not, the resource will be in an idle state and not cost you at all.

When you are using Serverless, then you will hear an acronym which is FaaS (Functions as a Service). Serverless is also referred to as FaaS because when you’re using serverless, your backend will be just a bunch of function that deployed on a different server :). If you were familiar with Heroku, then you will know that when we are using a free dyno of Heroku if in certain minute our servers don't receive any request, that the server will be in an idle state, then when the server accepting a new request, the server needs to cold start, and we know what will happen, the time taken for the cold start is very long, but when we are using FaaS, the cold start will be much faster because instead reloading a big project, the cold start will only reload a function, and will take a shorter time for ready receiving requests.

In short explanation, Serverless Architecture or FaaS is to build and run our application without managing the servers at all and just focus on the business. because our goals are to make our products go into the market as fast as possible, then we need the right service for our serverless architecture. as we know, the standard requirement for the backend in many projects was able to authenticate users and storing, serving some metadata. for that we will be using BaaS, there are many BaaS that we can use, and the short description of BaaS is, BaaS is a service that providing the standard requirement for our project so we don’t need to create our backend from scratch again :). Also because Serverless Architecture is an architecture that lets us just focus on the business and forget the pain of managing the server, in my personal opinion, BaaS is also can be considered the way to implement this architecture.

In my projects, because of the requirement and also the tight deadline that we have, we decide to adopt Serverless Architecture so we can focus on building the client-side, which is the side our client cares about and want to know the progress every sprint. We are using Firebase as our BaaS and when we need something that not provided by firebase by default, then we can using the cloud function which is the implementation of the FaaS.

Benefits from using this architecture were already affected my team because we can more focus on building the client-side so we can create beautiful apps for our clients :)

when using Serverless Architecture, we know that Serverless Architecture is very easy and fast to build (when we know the concept) and very cheap, and also auto-scale, but don’t you think this is just too good to be true? well, it depends on your project requirement. because we know that serverless architecture is very good to be used for MVP, and when your app getting bigger and bigger, serverless architecture might give you much cost than microservice, so you need to be sure is your project is a good fit for this architecture. in my PPL project, there is one key reason why we decide to adopt serverless architecture. we know that our client will not always be using the app, and the app will just be used at a certain time, and most of the time the traffic will be very small or maybe no traffic at all, but in certain time the traffic will be high. because of this, we think serverless is a very good approach because our client will not need to pay for the servers when the app is having very small approaching null traffic, and just billed when the traffic is high. it’s will be a different story when our assumptions are wrong and the app is always having high traffic. if this happens then migration to monolith or microservice is recommended. The point is because our project requirement is similar to when startup creating MVP for their product and getting advice from their users, so that’s why we adopt this architecture.

Lesson learn : be wise when deciding your project architecture for the sake of your client happiness :)

well, that’s all for this article, hope this article might be helpful for you who still doing research for your project architecture. thanks :)

Reference