Is going serverless worth it? Pitfalls and opportunities

The process is like a child playing with shape sorter, although sometimes you might need to do modifications either to the shape or to the hole that fits that shape. So, as a DevOps professional, it's important to do a personal evaluation of any technology. Without further ado, here are my thoughts on serverless.

What does serverless mean?

Serverless computing (or Function as a Service, sometimes also called Lambda Functions) has been around for a while now already. Time for surprise if you didn’t know already: serverless technologies actually run on a server! But what serverless actually means is that this server is abstracted away – it's provided as a service for you. A bit like a virtual machine abstracts away the hardware.

The most mature serverless technologies are in the public cloud. Google App Engine, Amazon Lambda and Azure Functions are very powerful tools. From the open source side, the most popular solution is Apache OpenWhisk.

How does serverless architecture work?

With serverless, you get a framework for building an application from the vendor. When you are building an application with that framework, the vendor takes care of running that application for you in a fully managed environment, hence the name serverless.

And here's why it's called serverless: your application won't be running if there's no one using it! This naturally leads to cost savings and a bit simplified ops, since you are not responsible anymore for actually running your code.

Since the cloud is often the best choice when it comes to saving resources, they only run your application on-demand. The following illustration explains what happens:

1. A developer uploads code to cloud
2. A user calls that service
3. The cloud spins up an instance of the code and provides the application to user
4. The user is done with the application
5. The cloud shuts the service down until the next user comes in

Should you go serverless? Some things to consider

Like every technology, serverless has a few caveats. I like to think that any technical problem is just an opportunity in disguise. Let's review a few problems that serverless has and how to turn those problems into opportunities.

Fact #1: Don’t bring your monoliths into serverless world!

This just doesn’t work and won’t make any sense. One golden thing about serverless is that it forces you to create cloud-native software. You need to have a mindset that this application might be suddenly shut down.

So don’t try to bring you stateful application into serverless unless you are ready to really move into cloud-native world. This change is not only technical but also it changes the way you develop software.

Fact #2: It's going to be slower

Serverless is not meant to be as performant as possible. When the first request comes in, code needs to be loaded into memory or virtual server that is expected to serve your request, which needs to boot up. This all might slow down your application.

The solution? Do not use serverless for applications that require fast latencies. If your response times are slower because of serverless, then serverless technologies are probably something you don't want to put to use.

Fact #3: Monitoring and logging is a problem

The nature of serverless is that your application instances are short lived. What if there was a problem with your application? Maybe you added proper logging, but still, since instances are so short lived, logs are long gone when you get a complaint from your user.

This presents yet another opportunity: invest in cloud-native logging. Ship your logs instantly to a platform like AWS CloudWatch or Google Stackdriver meant to do just that.

Fact #4: Serverless comes with vendor lock-in

Vendor lock-in is generally something you need to consider when you are building your business on a cloud platform. The more you invest in serverless technologies provided by the public cloud vendor, the more you create lock in for yourself.

There's no cure-all for vendor lock in. In a sense, you are always in some form of lock-in. Selecting a framework for your application or operating system already creates a lock-in in a sense.

The most important thing is that you know you are in lock-in and if you consider that to be a problem, mitigate it accordingly. In serverless, one option could be to utilize cloud-agnostic solutions such as Apache OpenWhisk.

Fact #5: You still need to take care of security

Security is not a black box that you can just buy off the shelf (I really wish it was!). This also applies to serverless.

If your serverless application is going to utilize cloud goodies like blob storage, be very careful when you are defining what privileges applications have to your resources. Also, make sure that you understand how your serverless deployments are made so that bad code really gets replaced by your fixes.

Also, don’t rely on the cloud vendor when it comes to security. No one should do that for you in my opinion.

Serverless: just another option to deliver value to customers

All in all, serverless is yet another tool. It’s not meant to replace anything.

It's not a replacement for containers. It's not a replacement for microservices. It's just another approach to how you would deliver awesome experience to your customers.

Complimenting existing cloud infrastructure with smart serverless technologies are a potentially winning bet when building your services for your clients. Or, if you are building a greenfield project, think about the big picture and figure out, does serverless fit into our vision?