Skip to main content

I discovered Serverless and I've fallen in love with the concept

Over the last few days I started to read about Serverless.

What is Serverless?

Serverless is a different way of building (Web) Applications.

Over the last few years, on emails from the AWS newsletter, I kept seeing Lambda mentioned a lot so I started to look into it.

What is Lambda?

AWS Lambda is a Function-as-a-Service (FaaS) compute service.

You write functions that would be triggered based on events, like an http call, or a file upload on S3 or anything that can somehow communicate within the cloud provider, in this case Amazon AWS.

The next thing that captured my attention was how it is priced: you pay only when it is running! For sure, instead of having a locked price on some vps instance or some other way of hosting, you pay only when the function runs and based on how much resources it had consumed (cpu, memory) for an amount of time.

The other important thing is that it scales as needed and you control the limits (you do not want to go broke if not making a profit from your App).

So Serverless is some AWS thing?

So within the lecture about Lambda, I've started to see mentioned Serverless as a framework. And next was that not only AWS does it, but Google Cloud and Microsoft Azure as well, each in it's own way, but following the same principles.

So I discovered that there is also a framework around the concept, named Serverless that helps developers concentrate over the logic and easing the infrastructure management.

Wait, I thought you've said that you do not have to manage any vps or other hosting solution?

Right, you do not. But your code, data and possible files need to go somewhere.

You can look at the Serverless framework as to a tool that helps you skip all the complicated settings you need to do and tweak in the "help I've lost my self" AWS, GCH or Azure panel.

Providing minimal details, it will automate the deployment and creation of necessary services and configuration and you'll enjoy your app running fast, even integrating it with some cool CI/CD service that you like.

So for what would I use it?

Short: for any possible event your application needs it.

A RestAPI, converting images when a user uploads one, sending a notification to all subscribed users of your website, etc.

The idea is you would use it for all you've done until now with your website and mobile app, and many things more that your current tools where limiting you.

What's next?

So my next task is to wrap up a simple web application skeleton and have some authentication with it.

The setup will be a minimal SPA hosted on S3 with Cloudfront that uses Amazon Cognito for authentication and implements a registration and login system for now.

This has lots of little steps to play around and will keep this in the journal how will go.

After that, will see what can we plan.

Comments

Popular posts from this blog

New Year's Resolutions 2018 edition

So there it ends another year and I'm deciding on my New Year's Resolutions 2018 list. More than 7 years since I've switched to web development and never sorted out to do something of my own, and not even accomplished some of my previous thought goals. I haven't given them to much importance, as my focus was always to become better on what can I can learn and improve in the work I do for my employer. All I did was playing with PHP , work on WordPress and Drupal websites, follow what ever the company's rules of doing things have been forced and so on. Although my passion is in web development, I realised that this previous years have not been actually been very productive for me. But now things are changing, as I've found the job that would allow me to focus learning and improving on JavaScript and related stuff. (I have to use pure JavaScript, no libraries or frameworks for implementations). And my New Year's Resolution 2018 list is: Build an MV...

Getting started with Mongoose, a beginner's perspective

Mongoose is an ODM that takes away the complexity of all the code you'd have to think and write and that you realise that could be abstracted and reused between all pieces of Entities your application will require. Two main features will help you from the beginning Handles the connection to the MongoDB instance using the official driver behind the scenes Allows to describe your Entities, or Documents how I should name them better, using Schema implementation that offers you the Model , as expected in the MVC pattern. The Schema is what you need to look into first, than Models . The Models will allow you to do all CRUD operations, supports pre built in Validation that can be extended with any custom rules, comes with built in Getters and Setters and allows any custom ones. Clever feature to keep in mind Also, Mongoose allows you to hook plugins . This is what DRY really means. Any small problem that can be solved and it's solution reused in Models is a prime...