Evolution of Computing to Serverless
Key Points
- Serverless means developers no longer manage or provision servers; the cloud provider abstracts that infrastructure so they can focus solely on code and business logic.
- Deployment models have progressed from bare‑metal (full OS installation and patching) to virtual machines (still requiring environment setup), then containers (packaging code and dependencies but adding scaling complexity), and finally to serverless, which minimizes stack implementation and maximizes business‑logic focus.
- Bare‑metal and virtual‑machine approaches demand extensive manual configuration and idle‑time management, while containers simplify deployment by encapsulating dependencies yet introduce challenges in orchestrating large‑scale workloads.
- In the serverless model, Functions as a Service (FaaS) provides a compute platform where individual functions—single units of code—are executed in response to events, eliminating the need to manage underlying servers.
- The event‑driven architecture of serverless platforms lets any trigger (e.g., a user clicking a button) invoke a function, enabling developers to build reactive applications using the cloud provider’s ecosystem of services.
Sections
- Evolution from Bare Metal to Serverless - Ashher Syed explains how serverless frees developers from managing physical and virtual infrastructure, tracing the shift from bare‑metal servers through virtual machines to fully managed cloud‑native deployment.
- Event‑Driven Serverless Function Overview - The speaker explains how serverless Function‑as‑a‑Service relies on event‑driven architecture, outlines its limits such as timeouts and latency, illustrates with an image‑resize use case, and highlights the pay‑per‑execution benefit.
- Fault‑Tolerant Event‑Driven Architecture - The speaker highlights that all services in an event‑driven architecture are fault‑tolerant, making the overall application highly available, and invites viewers to explore IBM Cloud with a free account.
Full Transcript
# Evolution of Computing to Serverless **Source:** [https://www.youtube.com/watch?v=vxJobGtqKVM](https://www.youtube.com/watch?v=vxJobGtqKVM) **Duration:** 00:06:41 ## Summary - Serverless means developers no longer manage or provision servers; the cloud provider abstracts that infrastructure so they can focus solely on code and business logic. - Deployment models have progressed from bare‑metal (full OS installation and patching) to virtual machines (still requiring environment setup), then containers (packaging code and dependencies but adding scaling complexity), and finally to serverless, which minimizes stack implementation and maximizes business‑logic focus. - Bare‑metal and virtual‑machine approaches demand extensive manual configuration and idle‑time management, while containers simplify deployment by encapsulating dependencies yet introduce challenges in orchestrating large‑scale workloads. - In the serverless model, Functions as a Service (FaaS) provides a compute platform where individual functions—single units of code—are executed in response to events, eliminating the need to manage underlying servers. - The event‑driven architecture of serverless platforms lets any trigger (e.g., a user clicking a button) invoke a function, enabling developers to build reactive applications using the cloud provider’s ecosystem of services. ## Sections - [00:00:00](https://www.youtube.com/watch?v=vxJobGtqKVM&t=0s) **Evolution from Bare Metal to Serverless** - Ashher Syed explains how serverless frees developers from managing physical and virtual infrastructure, tracing the shift from bare‑metal servers through virtual machines to fully managed cloud‑native deployment. - [00:03:07](https://www.youtube.com/watch?v=vxJobGtqKVM&t=187s) **Event‑Driven Serverless Function Overview** - The speaker explains how serverless Function‑as‑a‑Service relies on event‑driven architecture, outlines its limits such as timeouts and latency, illustrates with an image‑resize use case, and highlights the pay‑per‑execution benefit. - [00:06:16](https://www.youtube.com/watch?v=vxJobGtqKVM&t=376s) **Fault‑Tolerant Event‑Driven Architecture** - The speaker highlights that all services in an event‑driven architecture are fault‑tolerant, making the overall application highly available, and invites viewers to explore IBM Cloud with a free account. ## Full Transcript
Hi, I'm Ashher Syed with the IBM Cloud team.
Today, I'm going to discuss serverless, but first,
let's define what serverless actually means.
Does it mean that there are no servers involved?
The answer is no, obviously.
What it means is that you're not responsible for managing and provisioning of these servers,
it's sort of outsourced to the cloud provider whereas you are as a developer focused
on writing code or business logic.
And our deployment models have been evolving over the years, so let me walk you
through how we have gone to where we are on the serverless and the journey behind that.
So, on the Y axis you see increasing business focus on logic, that means you're concerned more
about writing code and less about the underlying infrastructure.
And on the X axis, you're seeing decreasing stack implementation.
What that means is you are in less control of what goes behind the scenes
when you deploy your code or write your code.
So, first we start off at bare metal.
Bare metal you were managing and configuring these servers and the environment
that you want to deploy your code on.
That means you are responsible for installing OS, all the patching and everything.
So, quite time consuming to figure out that environment.
Next, we move to virtual machines.
Resource optimized from the bare metal where you were handling idle times much better.
But at the same time, you're still responsible for setting up your environment; again,
installing O/S and patching and everything.
Down the road, we move to containers.
Actually, Docker popularized this idea.
Essentially what you're doing is you are packaging your deployment code, application code
and all of its dependencies into a single container which could run
on any underlying infrastructure.
It simplified a lot of things from the deployment point of view but at the same time,
some challenges with containers could be when you scale up your apps,
management of containers becomes a challenge.
At any given time, your application code is at least running on one server,
so you still have some idle time.
Then we move to serverless which is where we are now.
And in this, like I said earlier, in this model you are sort of abstracting from all
of the underlying infrastructure and you're focused mainly on writing business logic.
Let's look at how this serverless actually works.
All of the major cloud providers have this Functions as a Service.
This is essentially a compute platform for serverless where you run your functions --
functions are, just again, single unit of deployment of your code,
you could say it like a file processing as an example --
which is run by events which I called by events.
Events are anything, think of it as a click of button the user has, and it creates an event
which calls a function and then you run your code.
And in this serverless Function as a Service environment you have event driven architecture
which is, again, an ecosystem provided by cloud provider which has different services running
like database, IoT depending on how you want to build your app.
So, those, all of them are emitting those events and you build your app,
you look for those events and program that into your code.
And again, like any other platform, some of the drawbacks of serverless would be timeouts,
you know, these are stateless containers, [they] spin off for a little bit
of time and are deleted afterwards.
So, if your execution code does not finish in that time, your app could fail.
And then, you can also run into some latency issues depending
on how time sensitive you want your app.
So, let me illustrate that into an example here.
So, for example, a user comes here on a client side and uploads an image
and press a button to submit, it creates an event.
So, an event calls a function or invokes a function which does the resizing
of that image and it stores into storage.
So, this is just a very over simplified example of how Function as a Service works
and how you build your apps in that environment, serverless environment.
So, let's look at some of the benefits.
You pay for execution only.
What that means is there's no idle time.
So, like in previous cases where you were always maintaining a capacity or you're provisioning
for different scenarios that you always had something running.
Here, when your function is running, that's the only time you are paying for that
and its very cost efficient and functions usually run at 100 milliseconds of times.
So, auto scalables.
That's a responsibility taken by a cloud provider again.
When you architect your apps, you're not provisioning for any of that,
you are less concerned with the resources.
Faster time to market.
Again, since you're not responsible for any of the management and deployment of any
of the underlying infrastructure, you can build your apps faster,
solve customer problems and bring them to market.
Polyglot environment.
So, like others, I mean, Function as a Service allows you, you can write any language
and frameworks that you are comfortable with.
A lot of cloud providers have multiple languages that they support, so it could be very helpful
in cases where you are comfortable with one language, you want to write in that.
So, that's totally okay in the serverless environment.
Last but not the least is all of the serverless apps are highly available.
What that means is that cloud provider takes care of all the fault tolerance and the MZRs --
Multi Zone Regions -- that they build to make sure that your app is always up and running.
And all the services that you're using in event driven architecture are also fault tolerant,
so your app overall is always highly available.
Thank you for watching the video.
If you have any questions, please drop us a line below.
If you want to see more videos like this in the future, please like and subscribe.
And don't forget, you can always get started on the cloud at no cost
by signing up for a free IBM Cloud account.