I hope my previous blog gave you got a good start at learning about Serverless architecture. As promised, here is some more information on this topic to enrich your understanding of this implementation pattern. That’s right, in my opinion it is an implementation pattern. Because if you dig deeper, it’s not like there aren’t going to be any servers or backend systems. There will still be functions deployed as microservices, but isolated to a level that it’s easy for it to be scaled quickly.
There are essentially four features that help convert your traditional functions and services to serverless. These are:
Zero administration – One of the primary goals of the serverless-based microservices model is to provide the freedom to developers to deploy the code without provisioning anything beforehand, or managing anything afterward. No more dependency on the infrastructure/Ops teams. No concept of an instance, OS running on that instance, or any instance management overheads.
Auto scaling – Secondly, serverless-by-design lets your service providers manage the scaling challenges. There’s no need to fire alerts or write scripts to scale up and down. This allows for handling peaks and turfs in traffic and also the occasional lulls on the weekends, without any manual intervention. Tech serenity, if you ask me!
Pay per use – The concept of Function as a service provides the ability to compute and manage services based on usage, rather than pre-provisioned capacity. No more paying for idle time. The results could be significant, in some cases up to 90% cost savings over a cloud virtual machine. That’s real business value right there.
Increased velocity – Driven by the quick-to-market needs of today’s business models, this whole concept of being serverless gives developers the proverbial ‘wings’ and enables them to deliver functions on the fly. This is great for the Agile model of proving a functional concept and then designing it further.
Scalable – support your business spikes and lows more efficiently
Lower human resources – Once its set and configured, theoretically the system does not need human intervention. You do need to monitor the logs and take actions when the system performs out of the set limits
Focus on user experience – this is key for business. As discussed throughout this blog, the whole concept gives business the ability to be agile in a true sense, allows them to try out new things, and fail
Well, not exactly. As with any other new technology, it does come with its own challenges. Some of the obvious ones include:
Absolutely, as long as you make it so.
As the architects would tell you, the details are in the design! As with any enterprise service, you need to design with security as a primary requirement of your application. You need to account for the fact that users will be interacting with this service directly, sometimes using their credentials. So, it is important to clearly understand how to limit what resources they have access to, what they can and cannot read and write.
It is highly likely that your service would be interfacing with 3rd party services, and it is imperative to consider the access to that service. For example, with Firebase (a real-time streaming database), you write custom security rules that are executed by the database engine to determine which users can read or write from different parts of the database. If you are writing your own micro-services, then you need to ensure that your services check the authenticity of the security token passed and verify the rights of the user.
I hope this blog helped you get a deeper understanding of serverless services. I’ll continue with our series in the next installment, covering a toolkit that helps reduce the burden of starting with this great platform. It has an obvious name of ‘Serverless Framework Toolkit.’ Until then, adios!
Serverless Architectures Series (Part 1: What Is SA?) by Arun Chhatpar