DEV Community

Max Katz
Max Katz

Posted on • Originally published at maxkatz.org on

Serverless – simply an approach to building modern applications?

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:

  1. Language support
  2. Pricing
  3. 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?

Latest comments (1)

Collapse
 
bd_perez profile image
Bruno Pérez

Hello Max,

Thank you for your post. I appreciate the concept of serverless as an approach or a philosophy.

I am the co-founder of CASE, a Backend as a Service (BaaS) platform that is self-hosted. This means, as the term suggests, that you need to host it somewhere, so it is not serverless.

However, what CASE and other self-hosted BaaS providers share with the serverless approach is the desire to simplify backends.

For many front-end developers, backend development appears "harder" than front-end, and it probably is in some respects. This is not necessarily in terms of the complexity of the logic (as modern front-ends also include substantial logic) but more so in terms of the overall logistics: infrastructure, database, web server setup, DNS, APIs, task runners, system operations, backups, etc. It can be overwhelming!

I am enthusiastic about making backend and server-side functions more accessible and easier to comprehend, which seems to be the current trend.