-: FAAS and Serverless.
When I talk about FAAS,
I'm talking about function as a service.
Now, function as a service is a really cool new technology,
and it is really one of these newer technologies
that we're using inside the cloud computing world.
A lot of traditionalists
don't like the idea of function as a service
because there are some risks involved with it
which we'll talk about as we go through this lesson,
but I do want you to be aware of this concept
because as an analyst,
I personally think function as a service
is a large part of the future,
and we're going to have to learn how to use these things
and how to be able to analyze them for security
as we move forward.
Now, when I talk about function as a service or FAAS,
what exactly is that?
Well, it's a cloud service model
that supports serverless software architecture
by provisioning runtime containers in which code is executed
in a particular programming language.
Now, that's a really long way of saying
we are going to be able to run things and make applications
without actually having our own servers.
Now, that sounds pretty cool, right?
Because, now, I don't know about you,
but I've been a system administrator for a long time,
about 20 years,
and the idea of having to run all my own servers
and be able to run my own patches and do the updates
and do all the testing and do all that stuff,
just to be able to run a simple integration program
like the one I talked about between Freshdesk and Udemy
to able to make tickets go back and forth,
sounds like a lot of work.
And so, function as a service
eliminates the need for me to do that.
Instead, I can write the code in something like Python
and then run it in this environment.
Now, when we talk about serverless,
you notice that keyword in this definition.
Serverless is a software architecture
that runs functions within virtualized runtime containers
in a cloud rather than on dedicated server instances.
So, when you deal with serverless,
everything in serverless is developed
as a function or a microservice.
We want to be able to give it an input and get an output.
And the service should do one thing and only one thing.
So, you can design it, build it,
and test it completely independently.
Now, who is using things like serverless
and function as a service?
Do you know any big examples
or big companies out there doing this now?
Well, one of the biggest ones out there is Netflix.
That's right, if you've watched any Netflix recently,
you've been actually using serverless.
Netflix delivers over 10 billion hours of video
to 125 million customers every quarter
and they do this using serverless.
They do this because they're able to serve
that large of an audience
by using a wide range of highly complex infrastructure
that relies on AWS, specifically its serverless capability
known as Lambda.
Now, all of this is done using this AWS Lambda,
which is a serverless environment.
Essentially, Amazon runs all of these underlying servers
and Netflix doesn't have to worry about them at all.
All Netflix needs to do is know
that when they give them code
that's written in Python or some of other language,
Lambda can run it and they don't care
about what that looks like underneath that.
Now, we're going to talk more about how this actually works,
but Netflix is using this AWS Lambda
to essentially build this rule-based
self-managing infrastructure
that replaces a lot of the old inefficient processes.
And it helps them reduce the rate of errors
and save them lots of time and lots of money.
One of the great things about doing serverless
is that it eliminates the need
to manage physical or virtual servers.
Instead, you just get the service you need,
which is something that can run some kind of a language.
For instance, mine runs Python.
Now, when you do this,
you're not paying for these servers all the time either.
You're only paying when they're executing.
So, my particular automation
only runs once every couple hours.
And when it does that, it runs for maybe 3 to 30 seconds.
When I get a bill, it's for that 3 to 32nd increment
four times a day or six times a day or 12 times a day,
or however often I do it.
And so, the bill for this for us
is less than a dollar a month.
It is super cheap to use these things.
Now, Netflix's bill is a lot more money, but again,
you're only paying for the time
that you're actually using processing.
And so, this is a really great way to do things
and it can save you a lot of money.
Now, what are some real big benefits here?
Well, for one, there's no patching 'cause there's no server.
Two, there's no administration.
You don't have to administer a server
because it doesn't exist.
And three, there's no file system monitoring because again,
there's no server, you're just running code.
Now, the underlying architecture here
is going to be managed by your cloud service provider.
So, if you're using AWS Lambda,
it's Jeff Bezos and his team at Amazon
who has to worry about the underlying architecture.
They pay for the network.
They pay for the servers.
They pay for the operating system.
They pay for the patching.
They pay for all the security,
and you just get to run your code.
That's the benefit of using something like serverless.
Now, what is your job, though,
as a cybersecurity professional?
Because if we don't have to patch and we don't have to scan
and we don't have to operate in admin, what are we going to do?
Well, that's a really good question.
Our job here as cybersecurity analysts
inside of this world of function as a service and serverless
is to ensure that the clients accessing the services
have not been compromised.
Now, I'm not talking here about your end user's workstation.
If you're Netflix, it's not your job to make sure
that my home computer is properly patched and updated
before I connect to your service.
Instead, I'm more concerned
with your developers' workstations and their accounts
because they're the ones
who are going to update the application code
that's creating these functions and services.
So, if I'm a programmer for Netflix,
then you as a cybersecurity analyst need to make sure
that my workstation is properly secured,
that my credentials are properly secured,
that I write my code in a very secure way.
So, a lot of our job as cybersecurity professionals
starts moving from the infrastructure side of things
into more of the code analysis side of things.
And that's why cybersecurity is such a broad field
because there's all these different areas
and that doesn't mean
that we're going to be serverless tomorrow,
that all infrastructure is going to go away because guess what?
Amazon still has the underlying servers.
And so, there is going to be some role for people
to work at Amazon and Google and Microsoft
to be able to run their programs
and make sure they're being done securely.
But when we talk about working for a company like Netflix,
their cybersecurity folks are much more focused
on looking at the code that their developers are making
to make sure it's secure,
to make sure their authentication systems are good,
their authorization systems are good, and things like that.
So, when it comes up to the idea of function as a service
and serverless, we really have to ask the question,
is it safe or is it risky?
Well, with serverless, it does have some considerable risks
that you have to consider.
There are use cases and best practices
when you're dealing with traditional infrastructure,
but serverless and function as a service
is still relatively new.
So, you're kind of in uncharted territory here
and being a bit of an adventure.
That in itself makes it a bit more risky
because we don't know the longterm implications of that.
We don't know all the best cases
and the best practices to use.
Now, another thing that's risky about this
is that you're fully dependent
on the underlying service provider.
So, I keep saying Amazon as an example,
but Amazon is responsible for the dependency,
the redundancy, and a lot of the security
that underpin your services.
And you're basically wishing all that away
and hoping they do a good job.
Now, that is one of the things
that is a little bit more risky because. Again,
they haven't been doing this for a long, long, long time.
They're good at what they do and they do the best they can
to make sure everything's secure,
but is it 100% secure and reliable?
Well, maybe, maybe not.
Is it better than what you could do yourself?
Well, maybe, maybe not, that depends.
And so, these are risk decisions
the CIO and the CSO are going to make,
and then you, as an analyst, are going to have to fall in line
and work through those decisions, right?
Because again, these are servers that you can't see,
you can't touch because you don't own them.
Amazon owns them.
Microsoft owns them.
Google owns them, right?
You only have access to the code
that you're running on top of them.
Now, if you do decide to start working with serverless,
I want you to remember that serverless
depends on orchestration.
It's all about automation and orchestration
and being able to spin up and spin down resources
very, very quickly.
Now, a lot of that is done for you
by the underlying services, but again,
your code might need to take that into account
as you're making those actions
because if you're going to be using application log
just to be able to process an action,
or read or write things to a database,
or read or write a log transaction,
or copy a file and deliver it to a user,
all of these are things that require automation
and connection between these different services
that you're dealing with inside of the serverless
or function as a service perspective.