The idea of functions as a service is not new to the industry. We, being IT professionals, have seen lots of transformations in programming paradigms.

In its inception, software applications were deployed on dedicated hardware servers. Home grown servers was the buzz word of the time.

Let’s recap what happened along the way..

Initially, there we had no idea of how much server capacity(RAM, Harddisk, processor etc) was needed.

The hardware servers were really expensive for companies. They were treated like pets. When they became unhealthy, companies woul try to make them healthy again or replace them.

Here comes the idea of app servers. (If I have one application, why do I need a whole complete hardware server ?)

I should be able to deploy lots of apps onto one server.
This had one side effect. Shared resources (Your bug takes down my app).

Using app servers, updating to a certain technology required ages. One time in my career, I was like “I would like to move to java 8” but instead of a Yes, what I got as response was “You can’t until all of the apps move to java 8”.

On the other hand, the deployment process is really cubersome. Essentially, we are moving code from one server to another (From one instance of an app server sitting on one piece of hardware to a completely different instance of
seemingly the same app server on yet another piece of hardware).

This creates an extra layer of issues.
The infamous “Worked in dev but not in test”

or

“Works on my box”.

You keep staring at the environments. The environments are the same, why is it working here and not working there?
Optimistically, after weeks you find out the issue was because of the server patches in both the servers were applied in different order from each other. It’s like slipping on a banana peel. Then you think to yourself, what have I been doing with my career ? Is it too late for me to get into some other line of work ?

We realized that shared servers were becoming a liability. I don’t wanna be on the same server as somebody else.

We started treating them like cattle.. if one gets sick get a new one. Just like a cattle farm, they don’t give them names; they give them numbers.
If 15 gets ill, we don’t necessarily want to spend the time and energy to make 15 better. Put 15 down and get a new 15. Scary.

Software needs consistency. A script will do the same thing. Every. Single. Time.

IAAS was introduced by the tech giants (Google cloud, AWS etc).

IAAS made it really fast. Instead of waiting for the security teams to apply all the required patches, just get a server using your credit card. That too, on premises. Just the same thing as before, but faster.

Virtualization was at the core of this. Yet another abstraction over that physical layer.

A hypervisor managing the VMs. Coarse grained components.

You get a lot of control in a VM. A side effect is you need to manager everything. “With great power comes great responsibility”

Fundamentally, it is the underlying layer of when we say “The Cloud”. That is still what’s there.

On top of that abstraction, we started using “Containers”.

I have noticed this in the industry, not picking on someone, but… A new technology comes out and you talk to someone and it’s like “We need to use that technology”.
And you say “Great! Why? ” and they repeat the name to you.
“We need to use Docker”
“Okay, great. Why?”
“Well, because Docker”
Well, I think we need to go a little deeper than that..

What do we mean by Docker ?
It’s essentially a box. The best analogy is the shipping container.

If you think about what shipping used to be. It was a very manually intensive process. You needed lots and lots of able bodied people to carry things on and off a ship.
Now, the beauty of that is everything could just be hand moved. But it was not a very efficient process.

Along comes the shipping container. Now we have this commoditized box. They are all the same size. You put whatever you want in the box. And then we pick the box up with a crane,
we take it off the ship, and put it literally on the back of a truck and away it goes. Works out really really well.

You put whatever you want in it.

So, we put whatever we want in the box. Includes everything the app needs to run. Your code, your libraries, settings etc.
Now Everything is in that box. I am completely isolated from any environmental differences.

So, let’s be honest. You go and say “How often does your staging app server actually match production ?”
“Well, hopefully but not always”

And so instead of being in this model of “I am going to copy the code from one environment to another”. From one instance of an app server to another.

HERE IS EVERYTHING I NEED.
That’s the abstraction I want you to move.

Conceptually, it’s similar to Virtual Machines. It is just the matter of where are we doing the virtualization.
Containers virtualize at the OS level, not the hardware level.

Using containers i.e. Docker, the flip side is, you need to tell Docker everything you need. You need to have an image.

What do you mean by an “image”?

So you have an “image” and you just moved it around in different environments. Dev, Staging, Preprod etc
Is this a picture ? Well, kind of.
You can thing about it as a template or as a recipe for “How do we build that thing (the Container)”

You are responsible for what goes in the box. With great power comes great responsibility.
Software professionals are always in the search of new things. What’s new ? What’s hot ? What’s the buzz word ?
Stay current. Currency matters. You need to update.
All the CXO level folks are much familiar with a few cases where high level people lost their jobs.
So, now we are starting to see this emphasis on we really do need to care about this currency thing and be updated.
Even though it mean I might not get something new for a while but that’s okay. I just don’t to be the next largest hack ever.

Now, in today’s world, you cannot talk about containers without mentioning Kubernetes.
K8s – A way to deploy, scale and manager containers.
Comes from lessons learned at Google.
A lot of features that we would expect to be there, are.
Self-healing, Scaling, Service Discovery, Load Balancing. Automating rollouts rollbacks. All that cool stuff.

So you use KubeCtl. People call it by different names: kube control, kube CTL, kube cuddle, kube cuttle…
whatever you call it,
K8 – basically, a command line interface.

which means you sit there and you tell Kubernetes “This is what I would like, please make it happen”.

So you have platforms available supporting K8. PAAS. They have the runtime you need.
You just focus on your code.

Essentially, instead of moving the code; don’t move the code, move the runtime. Nothing has changed. It’s not a new thing, on a new piece of hardware.
Sometimes we just update the routing table in the platform and we’re done.

Eliminates an entire class of issues which ultimately gives us consistency.
Feature parity is achieved. Environments have consistency.
Time to prod has also decreased.

A good question here is, where does my runtime comes from ?
The answer is, BuildPacks.

You push an app, the platform figures out what kind of app it is, Java? .Net? etc.
Gets the buildpack. Deploys your app into that buildpack. Uploads it. Router says okay I got room on this server. Pushed to an available cell.
The beauty here is that you don’t have to know everything that goes into it.

Buildpack has everything you need to run that kind of app. Right there inside that droplet.

From the perspective of customers, they don’t care what version of OS or Java you are using ?
It’s just a dial tone for them. Not relevant.
They just care about the features they want.
That’s the value we as software professionals should focus on.

Platforms allow us to spend more of our time delivering value. The goal is free yourself from all that underlying OS and plumbing kind of issues etc.
Life moves fast. IaaS to SaaS to CaaS to PaaS…

Now, we have Serverless or FaaS (Function as a Service)
It gives you developer efficiency. Ideally, a function 10, 15 lines of code. How long does it take you to get your head wrapped around 5, 10, 15 lines of code ?
Contrast that with some of the legacy apps you probably might have worked on.

Functions push us up the abstraction curve and allows us to focus on the implementation not infrastructure.
Do you know what OS your code runs on ?
Do you know which version? which patch level ?
Do you care ?
Should you care ?
Where do you want to spend your time? Where do your customers want you spending your time ?
Really think about it, what is the “value line” for you ?
The beauty of a serverless environment is resource efficiency.
Function hasn’t been called recently in some period of time? Get rid of the container.
A request comes in? instance springs into existence to handle that request.

Conclusion

The best scenario where serverless fits well is when you go onto a website and update your phone number. After a few minutes, you get an email that goes something like “If you updated your phone, that’s fine. If you didn’t contact customer support”. Now, as a customer, you don’t care about the response time of the email as soon as you get the email within a few minutes. Latency is not your concern here.

Serlverless and FAAS are tools. Just like any other tools, they are NOT appropriate for all your problems.
You may want to take into consideration the latency a function takes. Or the cold start of a function.
Irrespective of you using java or .net for a latency intensive application, you are gonna face latency issues if you are using serverless.