What the Heck is Serverless

illustrations illustrations illustrations illustrations illustrations illustrations

What the Heck is Serverless

Published on Mar 23, 2020 by Dominik Kaukinen

post-thumb

Whatever your technical expertise this will be a nice introduction to serverless and the pros/cons.

Serverless is a bit of a buzz, and like all buzz words there are many half-truths surrounding it. It really is just having your code hosted and run on a platform where you don’t need to worry about the hosting hardware or software. There is actually a server, it’s just not managed by you or your developers. It also can be used to describe key infrastructure in your database that is managed by another provider (such as a database).

In the simplest case: developer writes code, the code get pushed to the cloud, it gets run by hardware and software managed by a cloud provider.

A quick note, you may or may not have heard the term ‘microservices’ this is not the same thing; serverless!=microservices. Also, don’t confuse this with the serverless framework, we are talking about the concept of serverless here.

Getting past the buzz what is actually good about it

I think serverless has three main benefits from the business perspective.

Lower lifetime development cost

The first is over the lifetime of an application it usually requires a smaller technical team to develop and maintain. Keep in mind if your team is new to serverless at the start it will require more resources and time due to the learning curve. If your team has invested time into automating code deploys and configuring the serverless environment, that is when development and maintenance costs begin to decrease.

It can scale well (usually)

You don’t need to worry about scaling as much. Most things you read about serverless will make it seem like your application will scale endlessly, but that isn’t exactly true. Serverless scaling has limits such as storage space and concurrent executions that you need to watch out for. Your application might have a bug or architecture problem with it that prevents it from auto-scaling your application effectively. It’s pretty good, but I’m just saying be careful.

Server expenses can be cheaper in many circumstances

The final benefit is your server costs can be cheaper, but it depends on the type of application you have. The cost is consumption based; i.e. you pay per 100ms of cpu time you use (usually). You also pay for bandwidth in and out of your system. Unfortunately, this makes it incredibly difficult to accurately estimate costs. The most accurate way I’ve found to estimate costs is to use historical usage data from users and model and average cost that way.

Up until now I’ve mostly talked about one feature of serverless applications; running your code. There are many other parts of your application that can go serverless: databases, machine learning systems, free text search and user account systems to name some of them. Each of these works a bit differently, but ultimately has a similar set of benefits.

So what’s the downside

Now is a good time to get into the some of the negatives. Most of these can be worked around, but will require a higher level of technical expertise than most teams have.

Not everything can go serverless (easily)

So, your code, api layer, database and static website hosting is all serverless. What if you need a smart text search? You can use Algolia, but they are very expensive particularly if you have a multi-tenant SAAS product. You could also use AWS’s Cloud Search, but it’s not really true serverless because your developers still have to manage scaling it (spoiler, it’s also very expensive). Admittedly Azure has a nice solution Cognitive Search, but their serverless offerings fall short in other areas. You will find similar problems when you want to have serverless hosting for larger machine learning models, or obscure services like PDF creation. These are solvable, but require more engineering talent than using the traditional server setup. Some of these may require using multiple cloud vendors, increasing your application complexity.

The learning curve can be steep

Its a new paradigm. In a vacuum where someone were taught both serverless and the more traditional alternative (containers or VM management) they might find serverless easier. But, it’s not the norm yet. Serverless isn’t mature enough where you can expect the average developer to have experience or have worked with it. This also means finding the right talent could be harder or more expensive.

So… should you do it

I don’t know, every case is different. If you can afford the growing pains of a newer technology for your software in full or part it might be worth trying out. It is likely to be the future of web applications, so at the very least you should be aware of it.

Personally I love serverless systems. The beauty is, if you want to try it out you can always do it for a new feature or small part of your application. Serverless can be as small or as big as you need it.