Serverless architectures will be definitely the future. I’m sure of that. But they are a pain to manage.

Companies are still doing the transition from physical -> virtual -> service and not all of them have the opportunity to have green fields where they can go serverless or even service oriented, so the transformation is a long and painful process for many. But a few of them are doing real serverless architectures and it does work.

The issue is then how you manage and operate a serverless architecture ? Keep in mind that in the old days you have a server list and when there was a problem with a business app you knew instantly where to look for. It was that machine/instance and the debug would start with network, cpu, processes, disk, app, data, etc. So was also fairly easy to have RTO/RPO’s and SLA’s when someone was managing that for you.

Before you go serverless, you need to decouple apps into services and exposing them as API’s, so that you can then transform them into functions and orchestrate it to work together. It seems hard, but it’s doable and that’s where we should keep people on for proper scaling and automation.

In a fully serverless world you might need to work with 10 or more different providers for a full app with backend, business logic and frontend. Imagine that, in a not that far distant world, you can decouple your business into functions and then use the best operator/provider for them, in a precise moment in time, taking advantage of price, speed and scalability.

Fun, isn’t it ?…

But now imagine that you need to debug what’s wrong with that app and you see yourself in a world of multiple SLA’s, poking multiple support lines and having multiple dashboards to see what’s wrong with your app.  Obviously the answer here is to have one good orchestrator that can not only manage architectures, but also services and incidents…. or put all your eggs in the same basket and pray for the best.