Why I considered going Serverless.

Why I considered going Serverless.

I did not stop my study on making my professional website as light as possible. Today, I dropped the server and I went Serverless.

In my 7 years of experience, I've been making websites and web applications. Trying to focus on my web page's fluidity, weightlessness, SEO, and other important User Experience improvement tasks. 

But then suddenly I need more RAM to process a huge chunk of Data, then while deploying the code, I got DDoS'd, and then my SSL expired. Then here comes the Project Manager, asking to update the UI for a promotion that will run for one week starting tomorrow and it's urgent.

Current state of inner peace...

It's an over the top scenario, but then again, dealing with them one by one is still not an easy matter.

Then AWS did it again. With Serverless, "You turn 200 lines of code into 4". You'll be able to concentrate on your application rather than on the whole monolith. It Scales automatically and it's Provider Agnostic. What I love the most on going serverless is if one function fails, it's the only one that fails. The application still runs while I fix the broken snippet. Modular in a whole new level.


Okay, first: My Scenario

For my professional website JCBAGTAS.COM, my main goal is to just create a single web page that has a form that sends me an email when a client is interested for a project.
The first thing I did was to create a Laravel application, hosted it in AWS Lightsail and off it went.

But It's $5/month. It's too pricey for me.

And the award goes too...

Seriously tho, my expected traffic to that website is way too low for me to be letting a good t2.nano power to go to waste.

So I researched about the AWS Lambda, AWS API Gateway, and AWS Cloudfront services.

PROS:

Turns out that I can host my web files on AWS S3, everything from CSS, JS, Images and Media and then just make and API call using Javascript to execute my Contact feature.

AWS S3

In AWS Lambda, I can call functions 1 million times per month for free. And then just get charge $0.0000002 per exceeding requests. Knowing my website, I would  just get around the 3 contact requests per month (at most). Really far away back from the 1 million free limit.

AWS Lambda

In AWS API Gateway I found out that I only be charged $0.0000035 per requests. Using our condition of 3 contact requests per month, that will be just $0.0000105 per month. Still acceptable for a poor guy like me.

AWS API Gateway

While in AWS Cloudfront in ap-southeast-1, I will just be charged $0.0000000000077 per request. Given our 3 contact request a month scenario, that will be just $0.0000000000231 per month.

AWS Cloudfront

I couldn't help myself but to be at awe, from $5.00 a month to the projected $0.0000105000231 a month. (wtf?)

CONS:

Of course all of these good stuff are not without their inconvenience.

First will be the waiting time of Cloudfront:

1. Deployment of a cloudfront distribution takes sometimes at least 1 hour to propagate. Of course this should be done after passing all QA tests and UI/UX reviews.
2. Because if you were to miss something or got something wrong in the UI after deploying, that one small change will be subject to "Invalidation". Invalidations will be charged per mil (per 1000) after the free 1000 invalidations per month. So one or two mistakes are acceptable.
3. To prevent this inconvenience, developers must never forget about staging and QA.

Server Configurations are not what they used to be:

1. Setting up object Expiration is not done using one file anymore. You'll have to change the metadata of each file in S3 to set their expiration. Don't worry, because S3 allows us to recursively modify the metadata from the directory. 
2. Redirects are now used using Buckets and not a simple 2 lines of codes in HTACCESS.
   

A different approach on Server Side code deployment
Deployment of Lambda functions are done via AWS CLI or via Browser. No FTP here or GIT.

So if you or your client aims to make a static website that is constantly being heavily modified every now and then, this kind of approach will not suit you.

CONCLUSION:

Some good scenario to use serverless websites are:

UI:

1. Brochure websites - Where in all contents are released to you for development after all the UI/UX design has been finalized.
2. Static Professional websites - Such as JCBAGTAS.COM where in my only aim is to showcase a brief glimpse on my expertise and works.
3. Promotional websites - Where the promo details are already finalized before publishing and will only require little to no form actions at all. 

BACKEND:

- All of which are being accessed from a UI of your choice.

1. Mobile Backends
2. Micro Services
3. Data Processing
4. Event Processing
5. IoT Scenarios
6. Messaging Scenarios (chat apps / chatbots)

I'll try to make another post to show the steps I took for my website to go serverless, for now hopefully this insight will help inspire other adventurers like me.