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.
