In this blog post I always refer to AWS and its services like Lambda, S3 and ApiGateway. Everything explained here, also applies to other Cloud-Computing-Providers, as long as they provide some kind of FaaS (Function as a Service)
What is Serverless?
For as long as there is software, developers invent abstraction layer on abstraction layer for the infrastructure, to be able to concentrate on their daily job of writing code and generating business value.
So the first step in the evolution of the Cloud was, instead of managing your hard drives and upgrading your RAM manually for your machine in the Data Centre, you get your Infrastructure as a Service (IaaS), where you can do these tasks via an API and leave the concern of how to provision these capacities to your Cloud-Provider. Using IaaS you still have to be aware of the infrastructure and decide when and how to scale.
That’s where Platform as a Service (PaaS) comes into play. With PaaS you just give the Service-Provider your application and ask them to ensure it always has enough resources to handle the work load. But still, you have VMs and therefore servers on which your application runs.
Serverless brings this to the next step and makes sure, you do not have to think about servers any more and in the end you will not even know what the underlying infrastructure for your code is. This is done by implementing the concept of Function as a Service (FaaS). With FaaS you split your application into small functions and define a trigger for their execution. In AWS these functions are called Lambdas. Triggers can be an incomming REST-Request (API-Gateway), Messaging-/Event-Queues (SQS and SNS), the change or creation of a file (S3), or many many more. Also running your functions periodically, using a Cron-Expressions as a trigger, is possible.
The most important thing is, that the infrastructure will be provided only when the function is invoked. This means when your function is not triggered you don’t pay for the provisioning of any resources. You only pay, what you actually use. And as there is a pretty generous free capacity, most of your use cases will be even free.
What’s the Issue with Pet Projects?
I noticed for myself and also after talking to other developers, that you rarely have only one pet project. The reason for this might be, that you just wanted to try out a new programming language, a new technology or just work with a cool new service or API your friend told you about. We just try out this one thing and then lose interest in this project. So when there is something new to try out, we start from scratch. Because of this these projects never leave a basic stage and get boring really quickly. Who needs 100 ToDo-Apps any way 😉?
Another problem is the extensibility of our pet projects. As they might be written in a language we are not proficient in, we do not want to invest the time to learn how to implement a basic feature, we are able to do in another language blindfolded.
We are just really bad pet owners.
How can Serverless improve this Situation?
- Support for different programming languages and frameworks
Even if you don’t have multiple projects, Serverless makes it very easy to try out different languages and frameworks. At the moment of writing this blog post AWS Lambda supports following programming languages: Java, Go, PowerShell, Node.js, C#, Python and Ruby. On top you can count all the languages which can be transpiled to one of the named languages or compiled to the bytecode for their runtime. e.g. TypeScript -> Node.js or Kotlin -> Java.
You also don’t need to spare your favorite frameworks. I am pretty sure that either the developers of the framework (e.g. Micronaut) or AWS themselves provide the needed proxy which converts the incoming event from the trigger to something your framework can use. E.g. for Express you can use serverless-express, for GIN you can use
- Minimal Setup
The Cloud-Providers really don’t want you to think too much about anything infrastructure related. So forget about setting up web servers and configuring your VM to expose its ports to the internet. There are many services and libraries in the Serverless world which keep this stuff away from you. AWS has SAM, the Serverless Application Model. SAM provides a simple CLI, which can create, build and deploy your Lambda function together with its triggers. All you have to do is write your code, create a template.yml file and execute two CLI commands:
sam deploy. That’s it you have a deployed Lambda function ready to be used.
That’s a pretty neat and simple CI/CD workflow, isn’t it?
Below you can find a basic SAM Template which deploys a Lambda function for you and adds API-Gateway with the route
/helloas a trigger.
I created a small example project with Serverless Express and AWS SAM for you to see how minor the overhead and setup is in comparison to the result: https://github.com/sbeugen/serverless-blog-post
For more information find the developer guide for AWS SAM here.
- Less overhead for monitoring, logging, etc.
Cloud-Providers like AWS do not only give you FaaS, but a full ecosystem of services. You can use them to free yourself from having to set this all up. Everything your application logs will end up in CloudWatch, which makes it very easy to check your errors and even create alarms. This is not something you would usually simply add to your pet projects. In the Serverless world you just have it.
If this is not enough and you want to see the way each requests takes in your project, you can simply activate X-Ray.
- Scalability (up and down)
In business relevant projects one important capability is scaling your application and infrastructure up, as the workload increases. That’s usually not a requirement you have for your pet projects. But what can be scaled up, can also be scaled down. Even to zero!
As mentioned in the “What is Serverless” section above, using FaaS you only pay what you use. This applies to everything in the Serverless world. E.g. you need a database for your project. AWS has DynamoDB (NoSQL) and Aurora (SQL) which are considered to be Serverless. You can configure them to scale down to zero, if you have not made any requests against your database for some time. This means you are not paying for any resources in this timeframe. If you start doing requests, the database instance will spin back up and be accessible again. Of course this takes some time and is most probably not suitable for a business critical application. But for your pet project, which you might only show once a month to a friend, this is perfectly fine.
- Personal benefits
Serverless and Cloud-Computing in general are very hot topics for companies all over the world. If you want to stay up to date regarding modern technologies and what companies demand from applicants, it is definetely worth learning these things. I think you agree that showing complex serverless architecture (which is not that complicated to build) in your interview and explaining what all the bits and pieces do, is far more impressive, than telling something about your monolithic ToDo-App. Just the fact, that it’s built Serverless, makes the same application way more interesting.
And besides your professional career, it is simply more satisfying to have a small number of really advanced pet projects, on which you can regularly work on and see them grow.