Why Kubernetes, OpenFaas etc are most likely NOT for you

When a new shiny piece of software starts gaining traction in the media, it can be hard to figure out whether you should investigate it or not, whether you should use it in your company.

Kubernetes for container orchestration, OpenFaas for serverless infrastructure… If you listen to the numerous blog articles out there, and then look at your infrastructure, you start wondering whether you’re an old dinosaur who needs to get up to speed with the latest tech.

Over the years, I created and worked at a few startups: cloud rendering for 3D/VFX studios, 3D visualization and tracking of satellites, cloud computing for numerical simulations in aerospace industry, automated satellite imagery analysis with deep learning… So far, if I had to sum up my experience in 1 key take-away, it would be: listen to the people on the field, not the media. How many CTOs* actually use this technology? What do they have to say about it? Get some feedback from the people whose *ss is actually on the line, and who is woken up at night when their company software infrastructure goes south.

Those opinions are infinitely more valuable than blog articles stuffed with overhyped keywords to draw web traffic and generate advertising revenue.

Let’s pick an example, and talk about serveless technology, such as Amazon Lambda and OpenFaas.
Today, when you’re a software developer, you need infrastructure to run your code, be it bare-metal servers, VMs, or docker containers. If you want your code to run right out of the box, serverless technology can be attractive.
So you pick Amazon Lambda or another equivalent (Google Cloud etc), and before you know it you’re vendor-locked with one cloud provider. From a CTO perspective, it’s not that great. You’re better off being not vendor-locked and able to switch cloud provider if you need to.
However, serverless advocates will say, and they’re right, that you can go the open-source way and use software such as OpenFaas.

The main selling point of serverless technology is that it abstracts away the underlying infrastructure that runs your code.
The problem is, we’re all too old to believe in magic. When a new piece of software abstracts away a piece of your stack, it has to introduce abstractions, concepts, and thus complexity. If the software is well-written, it will be “good complexity” (complexity that is necessary), but that’s still complexity. Concretely, it means software with a lot of configuration levers, software complex to install, tune, and maintain.
It can be interesting to have 1 or 2 people full-time configuring that software, if you have a few dozen software developers using the resulting service.
But is it the case of your company?

I could say the exact same thing for Kubernetes. Google initially developed this technology to run containers at scale (thousands of them). When you scale operations, you quickly encounter bottlenecks (race conditions, network emergent behaviors…) that you solve one by one by introducing abstractions and concepts, to solve them in a generic way. This means Kubernetes has many configuration options, is complex to use, because it solves a lot of problems in a generic way.
But are you running thousands of docker containers in your startup? Do you need to swallow all of Kubernetes complexity, to be able to solve problems you will likely never run into?

To sum it up, if you are the one woken up at night when something goes wrong, think carefully before joining the hype bandwagon. When evaluating new technology, do not read too many media articles! Find out who is using or not using it, and why! Do you need Kubernetes or can Docker compose do the job? Do you need serverless technology or can you adress your needs with a few well-written docker containers?
My opinion is that 90% of startups with less than 50 people should never touch software such as Kubernetes or serverless technology.

*Try to find mailing lists of peers from your industry. For example, for 3D/VFX studios, the place to be is http://www.studiosysadmins.com/

Originally published at fruty.io on March 8, 2018.