Using Serverless Architecture — Is not all or nothing.

is an especially hot topic that drives a lot of hype last year. The big “four” cloud hosting companies each provide its own solution: , , and . There are many that start comparing and discussing the benefit of using Serverless over traditional . Serverless Azure Function AWS Lambda Alibaba Cloud Function Compute Google Functions conferences 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 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 operational 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. Lower scaling costs — Instead of always reinventing the wheel, there are actually many ready make components with other service providers. For example, authentication service like , , payment service like and . These ready built components will save us so much time and development cost as compared to developing everything ourselves. Reduce development costs — Firebase Auth0 Stripe Braintree Possible Use Cases for existing Project Photo by on Helloquence 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. 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. Authentication / Sign Up — 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 , 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. Image Processing — S3 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 , you can trigger a to run and use to send out an email. I update a part of my own application where when a new is saved into , it pushes a particular notification to the user of the app to ask for permission to update. Event Driven Feature — S3 Lambda SNS APP_VERSION.zip S3 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. — A python framework that allows us to quickly create and deploy applications using AWS Lambda, API Gateway, and CloudWatch. Chalice by AWS — 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. Zappa — 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. Claudia.js — 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. Apex Conclusion In simplest term, serverless works best when it is to perform a . We do not always have to choose one kind of server architecture over another. Sometimes a hybrid architecture allows us to utilize single purpose stateless function 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 or my . Twitter blog