By Abhinov Gulati, Ganemo

Serverless architecture has become a buzzword, with more and more people using it. But should they be? While there are some situations where serverless offers many benefits, there are also scenarios where it’s not the right technology.

To decide when serverless is appropriate, let’s start with what it means. We can use the analogy of food service.

1. Traditional servers = restaurant:  you have permanent space, waiters employed, and it’s always there whether you use it or not

2. Cloud-based server + load balancer = UberEATS: there’s existing infrastructure but you broker what you need. You call up, order a meal, assign a task to a specific food outlet and driver, and it’s delivered to you

3. Serverless = AirTasker: you want spaghetti, someone sees the request, they buy a bowl, some food, find an oven, cook it, serve it, then throw the bowl away

A cloud model + load balancer is in fact very similar to a serverless solution. Both architectures use servers, making it all the more confusing. The difference is that with “serverless”, you don’t have to manage the servers that run your code.

Let’s look at a good example of using serverless. Alpha7 is a company that delivers affordable business insights, based on Big Data, to SMBs. It uses Amazon Web Services’ Lambda platform for serverless computing, for two purposes. First, to push data to a database. Secondly, to send out triggers, such as starting data processing, or sending email notifications. Lambda puts each task in a queue, and a machine monitoring that queue will pick it up and begin its computation once it sees something there.

And now for a bad example. A job site we audited was using Lambda for user log-ins, but the code to authenticate users using third party services (e.g. GreenID), shouldn’t be inside a serverless method. It involves putting a lot more logic through Lambda and timeouts can occur while waiting for third party services. Lambda is intended for quick operations, while easily managing load.

When you shouldn’t use it

1. Complex logic

Putting entire application logic into a serverless architecture will become quite difficult to maintain. With serverless you’ve set up a lot of manual end points, in some cases you’ll have scripts to deploy the endpoint, but there’s a lot more fragmentation, it’s not self-contained. Each endpoint is independent of other end points, which means that there are a lot more components to maintain.

2. Long running task

3. Freedom to change vendor

When incorporating a server less component, such as Lambda into your technology stack, it will be increasingly difficult to change vendors, you may find yourself locked into a platform, including its costs and API’s.

When you should use it

1. Small, independent tasks of high volume

Serverless is ideal for this, such as pushing data to a database: one simple, finite task.

2. Broker notifications & queuing services

With serverless, a platform like Lambda can send out triggers such as starting computation processing or sending email notifications. Lambda can assign tasks to different machines, which don’t have to be directly connected. You don’t have to worry about what’s going where, or who’s doing what.

3. Reduce time by simplifying software

Serverless allows you to make your code simpler, and allow rapid release without worrying about a lot of system configuration

In a nutshell: the purpose of serverless is to achieve scale and allow developers to concentrate more on code, without having to worry about server configuration. It’s aimed at handling large volumes of traffic, but not carrying out complex tasks.

Abhinov Gulati is IT Director at technology and software solutions provider Ganemo Group