Sometimes the Server Matters

  • By Jamie Duncan
  • Mon 05 December 2016
  • Updated on Sat 10 December 2016

OMG I hate the word "serverless"

"Cloud" is bad enough. It can mean just about anything you want it to at the end of the day. I often joke that the fastest way to make a Director/Manager somewhere angry is to ask them

How do you define cloud?

Most people think they want to be there, even though they don’t really know what it is. Plenty of unscrupulous companies out there have made bank on this little idea like the internet’s version of a cab driver taking a tourist on a sight-seeing tour for a 10 block fare. But there’s not really any dange there. Eventually they either run out of money or they find a company who will actually help them modernize their IT solution stack successfully.

But "Serverless" really does bother me.

What is Serverless?

The term "Serverless", if not originated by, was certainly made popular by Amazon. Their Lambda service is their implementaiton of the idea. In their words

AWS Lambda lets you run code without provisioning or managing servers. You pay only for the compute time you consume - there is no charge when your code is not running. With Lambda, you can run code for virtually any type of application or backend service - all with zero administration.

Holy crap that’s amazing! Well. Maybe.

Often times when I’m talking to customers I define a developer’s perfect world as

  • A place to push their code to

  • A URL to look at what they’ve done

In a way, that’s exactly what Lambda does.

Taking microservices to the next level

The idea behind Lambda is that not only are you breaking your application into the smallest possible pieces (we hope), but now you are only paying for the time they are actually being executed. That sounds awesome. You can have a function sitting out in Lambda, and when some event happens, that code is triggered. Things like something being uploaded to an S3 bucket or another API call happening. All sorts of awesome Amazon-centric fun integration points.

It’s not serverless. It’s ephemeral.

These workloads run on servers. That means they are by definition not serverless. Abstracting away the management of a server doesn’t make it go away. But if you build them on demand, and destroy them once the work is done, then it does become Ephemeral Computing. That is still pretty awesome.

What’s wrong with that?

In theory nothing. At least some of the time. But there are times when the underlying architecture matters.

When does the server matter?

When response time matters

The world is currently obsessed with building out all of these widely-distributed, microservice-style applications. These have tons of latency built into them, compared to something that requires high performance. When 10 or 200 different services have to communicate with each other via HTTPS, it’s just slow in a lot of parts of the world.

Serverless architectures take this to the next level. Not only are you adding in an HTTPS round-trip to your application’s response time, but you are also not able to tune (or even understand) the underlying virtual machine your code is executing on.

For lots of people, that’s just too slow to be able to consider. People in the HPC world, financial and healthcare worlds, and really anything that is not a web application with a human as the end user.

When tuning matters

For most high-level languages (Python, Java, Ruby, etc.), kernel tuning parameters don’t make a huge difference most of the time. The languages are passed through enough layers of abstraction that results are normalized and standardized.

But for lower-level languages like C, C++ and a bunch of others, how the kernel is configured is really important. It can substantively alter the results your application returns.

With a serverless concept, you have no control or even idea how the kernel is configured.

When security matters

A lack of visibility is inherently insecure. Is SELinux enabled? What about SECCOMP? Do they matter for this workload?

The answer is, we don’t know. Out platform is abstracted away.

Summary

Like almost everything, the answer lies somewhere in the middle. It was a massive topic at re:invent 2016. For some workloads, it will be extremely useful. There are tons of parts of websites that are accessed less often, and don’t require super high-response times. Boom. Great opportunity for this type of technology.

But is the world going to be serverless in 3 years? Of course not. Sometimes the server matters. In fact, the server always matters. It’s just that sometimes you don’t need to manage the server itself.

So yes. You should be making this a part of your application plans. Just like public clouds, and private clouds, and traditional virtualization, and bare metal. But it’s not a game changer.