If you search for “serverless” you find that serverless is a new popular way to build modern applications. Is serverless really new?
Serverless refers to the notion that you don’t need to worry about servers – you don’t need to provision, deploy, maintain servers. Obviously there are servers but you don’t need to think or worry about them, the cloud or the platform where you run the code will take care of that for you. Another major benefit is that a serverless function (cloud functions or function as a service) will automatically scale when demand increases.
Interestingly, the idea of executing code in the cloud has existed for a long time as part of Backend as a Service (BaaS) or Mobile Backend as a Service (mBaas). Companies such as Parse (Founded in 2011. Acquired by Facebook and now lives as an open source project), StackMob (acquired by PayPal), Kinvey (acquired by Progress), Appery.io (my previous company) and many others.
In addition to providing a server-side environment where a developer can write and execute code, these companies provided additional services such as a database, integration with 3rd party API and services, push notifications (for mobile), analytics, file storage, integration with login providers and other capabilities. They also provided various client SDK to work with their backend services.
I think serverless is simply an approach to building modern applications. It’s not a particular feature, but an approach. As for naming, I personally prefer the name cloud functions or functions-as-a-service.
There three differences between serverless and the “old” BaaS server-side code execution part:
- Language support
- Pricing
- Scale
Language support
All serverless cloud providers are polyglot, in other words, they all support multiple languages (JavaScript, Python, Swift, C#, Java and others) to build cloud functions. BaaS providers mostly supported only JavaScript (or Node.js) for writing server-side code.
Pricing
With serverless you pay for a combination of execution time and memory used. You also pay only when your function is running.
With BaaS, you would pay for a number of API calls upfront and execution time. If you used them all – great. If you didn’t use them all – well, not much you can do, you already paid for them. And if you went over your limit, you would be charged overages.
Scale
How to scale your application/services was somewhat of a gray area. I think the basic idea was – if your app grows fast, and you need more compute resources, let us know and we will figure out something.
Serverless today auto scales your functions when demand increases. This is one of the core benefits of serverless today.
Serverless is simply an approach
I think serverless is simply an approach to building modern applications. A few years ago it was called BaaS, today it is called serverless.
Serverless architecture should consist of:
- Cloud functions (FaaS)
- Data store/database
- Notifications (mobile, desktop)
- Messaging (email, SMS)
- Integration with 3rd party/external APIs
- Any other something-as-a-services
What’s important is that all these services should scale, not just cloud functions. If your cloud function uses a database which doesn’t scale – well, that’s not going to work well.
Let me know what you think. Do you agree that serverless it more of an approach than a particular feature?
| Published on Java Code Geeks with permission by Max Katz , partner at our JCG program. See the original article here: Serverless – simply an approach to building modern applications? Opinions expressed by Java Code Geeks contributors are their own. |
