Serverless is an especially hot topic that drives a lot of hype last year. The big “four” cloud hosting companies each provide its own solution: Azure Function, AWS Lambda, Alibaba Cloud Function Compute and Google Functions. There are many conferences that start comparing and discussing the benefit of using Serverless over traditional architecure.
By using serverless we can execute well-defined functions that are event triggered without the needs of managing and scaling any infrastructure.
Ever since I started adopting serverless architecture on some of my side projects, I find out that there are certainly many benefits that we can utilize from this.
We don’t have to go ALL or NOTHING on serverless.
Benefits
Lower operational costs — Instead of hiring someone to manage a server, we sort of “outsource” it to an expert. Developers can focus on writing code and use the predefined services that many other people are already using. Secondly, we only pay for the time taken to run the function instead of paying for a server that is up 24/7.
Lower scaling costs — Instead of scaling everything or throwing in more hardware, we can choose to scale the part that matters. Most of the time, a spike occurs at a certain part of the app and usually for a period of time. For example, during a sales period in an e-commerce site. If we have uses serverless architecture to do payment integration with Stripe, we only have to pay the extra compute capacity during the spike period.
Reduce development costs — Instead of always reinventing the wheel, there are actually many ready make components with other service providers. For example, authentication service like Firebase, Auth0, payment service like Stripe and Braintree. These ready built components will save us so much time and development cost as compared to developing everything ourselves.
Possible Use Cases for existing Project
Photo by Helloquence on Unsplash
We can take advantage of all this by migrating part of the application that particularly suits serverless. As mention above, I think that authentication and payment integration will be a good start.It is part of the application that just performs some event. There is very little business logic that required state.
Authentication / Sign Up — We don’t even have to migrate the whole authentication or signup process. If your team is looking to add other forms of authentication like SMS verification or improve password reset features I will definitely consider serverless.
Image Processing — Most application who has user account also handle some form of avatar image for each user. If you handle some form of photo editing / resizing and saving to a storage like S3, updating that part to serverless certainly make a lot of sense. This way, you can either reduce thread or extra worker that is running and only pay for the compute time used for the particular function.
Event Driven Feature — If your application generates some form of invoice at a particular time of the month and email the particular user, this is a good use case for serverless as well. When an invoice is saved to S3, you can trigger a Lambda to run and use SNS to send out an email. I update a part of my own application where when a new APP_VERSION.zip is saved into S3, it pushes a particular notification to the user of the app to ask for permission to update.
Frameworks to boost development speed
With the maturity of serverless architecture, many great engineers start creating frameworks to help make their job easier. The following are some of the libraries I compared when starting on the serverless architecture journey.
Chalice by AWS — A python framework that allows us to quickly create and deploy applications using AWS Lambda, API Gateway, and CloudWatch.
Zappa — Python framework that allows us to deploy any WSGI-compatible applications with AWS. Applications that build on Flask, Bottle, or Django can be easily configured with Zappa.
Claudia.js — Easily deploy any Node.js projects to AWS Lambda and API Gateway. Focused solely on Node.js application, automatically installs templates to convert parameters and results into objects that Javascript can consume easily.
Apex — Build mainly on Go, but support many other languages that are not natively supported by AWS Lambda through the use of a Node.js shim injected into the build. Currently supports Node.js, Golang, Python, Java, Rust and, Clojure.
Conclusion
In simplest term, serverless works best when it is to perform a single purpose stateless function. We do not always have to choose one kind of server architecture over another. Sometimes a hybrid architecture allows us to utilize different benefits.
I hope I did enough to convince you. If you are building a new feature or trying to improve an existing feature, put some thought into using serverless architecture. If it is something that fit the above scenarios, give serverless a go. You might unlock something and learn new things along the way.
Thanks for reading! If you like it, please hit 👏👏👏
I enjoy reading and writing about tech and products especially related to boosting the productivity of developers. You can say hello to me on my Twitter or my blog.