- In ten four, we're gonna look specifically,
at data center solution elements.
If we're gonna be talking about a data center,
well, we definitely have to talk about automation.
Automation is the application,
of technology programs, robotics,
or processes to achieve outcomes with minimal human input.
Now, the goal of IT automation is to improve QOS,
that's quality of service, increase agility,
and reduce or eliminate manual dependencies,
and human error.
Means we really wanna make our data center,
just work as perfectly and as effectively,
and as efficiently and possible.
Now, orchestration is the integration of disparate tools,
and platforms for an automated response.
So in this lesson of data center solution elements,
the big solution we're gonna look at,
is automation and orchestration.
Now, demand generated resource allocation,
is the automatic provisioning and deprovisioning,
of resources in our data center.
And when we think about demand generated resource
allocation, we really think about two components,
scalability and elasticity.
The scalability is the ability of a system,
to automatically accommodate larger loads,
by adding more resources, either making hardware stronger,
and you'll hear the term scale up,
or making additional nodes, and that will be scale out.
Elasticity is the ability to fit resources,
needed to cope with loads dynamically.
So when the load increases, we had more resources are added.
And when the demand decreases, resources are removed.
And the way I always remember between the two is,
I think about a rubber band, right?
An elastic band.
And if you put it between your thumb,
and your first finger and you stretch it out,
and then you bring your fingers back together,
it's gonna come back into its shape,
stretch it out, bring it back.
So it's that idea of dynamically, we're stretching it out,
adding more, coming back, taking it away.
So scalability, scaling up and out,
elasticity is dynamically fitting the resources,
needed to cope with loads dynamically.
So what are some solution elements that involves,
some automation and allow us to do scalability,
and or elasticity.
Infrastructure-as-code, serverless computing,
microservices, containerization,
which we already touched on.
And SDN, or software defined networking.
Infrastructure-as-code is using code,
to manage configurations and to automate provisioning.
Serverless computing just refers to the dynamic allocation,
of resources to execute a specific piece of code.
Microservices is breaking down a larger application,
into smaller, independently deployable components,
that will perform a specific business function or task.
Containerization, which we talked about in the last lesson,
is a technology that allows applications to be packaged,
and then run in isolated environments called containers.
And then we have software defined networking,
and that's using software to manage,
and to configure the network infrastructure.
So let's look a little deeper at each one of these.
Infrastructure-as-code, or IAC is used to define,
and provisioning networking components such as servers,
networks, and storage that can be version controlled,
tested and automated.
There's our automation, through machine readable files,
rather than physical hardware configurations.
So from a security perspective,
what do I wanna think about?
Well, first it's unauthorized access.
If the attacker could gain access to the IAC,
the infrastructure's code files or the configuration,
they could potentially modify the infrastructure,
leading to unauthorized access or data exfiltration.
So we wanna have good security controls,
over those configuration files.
Could end up with insecure code.
So flaws in a IAC code could,
create vulnerabilities in the infrastructure,
such as open ports or weak authentication methods.
So we always wanna really test that code,
and make sure that we don't have any flaws.
And then misconfiguration, misconfiguration in IOC,
could lead to unintended consequences such as,
exposing sensitive data or resources.
But if we have good strong configuration management,
and we use our baseline configurations,
and we test them all out,
well then we can use those same baselines, right,
in setting up the the script or the configuration files,
for infrastructure-as-code.
Next is serverless computing.
Serverless computing is an execution model,
in which a cloud provider dynamically allocates,
only compute resources and storage,
needed to execute a particular piece of code.
Now, serverless computing is known as event driven,
meaning the code is only gonna be invoked,
when a request is triggered.
So our security considerations, well, injection attacks,
that serverless functions can be vulnerable,
to an injection attack where the attacker injects
malicious code into the function's input or output data.
Hence why, input validation,
and output validation are so important.
Malware, that our serverless functions can be used,
to distribute malware such as disguising malicious code,
as a legitimate function.
And data privacy sensitive data can be exposed,
if it's not properly secured,
or if access controls are not properly implemented.
Microservices are a software development approach,
where a larger massive application is broken down,
into smaller independent services.
Now, each microservice is a self-contained component,
that can be deployed, updated, and scaled independently,
without affecting the rest of the application.
So, sounds great, right?
But as always,
there's gonna be some security configurations, right?
There is an increased attack surface.
Microservices architectures have a large number,
of interconnected components which can increase
the overall attack surface and make it harder,
to identify and mitigate vulnerabilities.
And we have service to service authentication,
and authorization.
In a microservices environment,
services need to authenticate and authorize to each other,
which can be challenging to manage and to secure.
So microservices really can be quite wonderful.
But just like everything else,
we really have to think about these security considerations.
Containerization, which we have already chatted about,
right, is a technology that allows applications,
to be packaged and run in isolated environments.
Now, containers do provide a way,
to isolate the applications and their dependencies,
from whatever the underlying infrastructure is,
which does make it much easier to deploy and manage,
and scale applications across different environments,
which is why, you know, Google uses containers.
But our security considerations, one is container breakouts.
The containers share a host operating systems kernel,
and if a container is compromised,
an attacker could potentially break out
of the container and access the host system.
Now this can happen,
if our container is not properly configured,
or if the attacker finds a vulnerability,
in the container runtime.
Then we have some container orchestration vulnerabilities.
Container orchestration tools,
are used to manage and scale our containers.
Now these tools can be vulnerable to exploits,
especially, once again, if they are not properly configured.
Next up is SDN or software-defined networking.
SDN technology enables network configuration,
using a software application, instead of changing
the configuration of physical equipment.
Now, SDN, interesting, going all the way back,
to what we talked about in our zero trust,
or ZT environment, is made possible by separating
that control plane from the data plane, right?
The control plane is moved to a centralized controller,
that actually manages those networking devices.
So if you need a refresher on the control plane,
and data plane, go all the way back to the lesson,
about zero trust.
Our security configurations, centralized control, right?
SDN does rely on a centralized controller,
to manage the network,
which makes it a single point of failure.
So if the controller's compromised,
the entire network could potentially be compromised
and controller vulnerabilities,
the controller software can be vulnerable,
to exploits such as buffer overflows, injection attacks,
which can be used to gain unauthorized access,
to the network.
So these are all solution elements,
that we've been talking about, you know, in this lesson.
I don't want you to walk away thinking, wow,
there's a lot of security considerations on all of these.
Well, there are, but that's not a reason,
to just discard them or not use them.
These are all some really cool solution elements,
that that definitely have their benefits, but you know,
like any other good thing, and we always have to take it,
with a grain of salt and say, okay, this is good,
but we need to look at these certain things.
And that's what those security considerations are.
All right, that's gonna bring us,
to a three second challenge.
You know what to do.
Five questions, three seconds each, here it goes.
Using code to manage configurations,
and automate provisioning.
1, 2, 3.
That's gonna be infrastructure-as-code, or IAC.
Number two, using software to manage,
and configure the network infrastructure.
1, 2, 3.
That's SDN, software defined networking.
Number three, dynamic allocation,
of resources to execute a specific piece of code.
1, 2, 3.
That's serverless computing.
Number four, breaking down a large application,
into smaller independently deployable components.
1, 2, 3.
That's microservices.
And lastly, a technology that allows applications,
to be packaged and run in isolated environments.
1, 2, 3.
That's gonna be containerization or using containers.
All right, let's do a security and action,
on on-demand resource generation.
Your organization is evaluating cloud computing
service providers.
The proposals seem to use the term elasticity,
and scalability interchangeably.
Then you wanna make sure that the business unit
decision makers really understand the difference.
So how are you gonna compare elasticity and scalability?
Go ahead and put me on pause, write some notes,
and then come on back.
Well, both solutions are designed,
to meet changing business needs.
Scalability is the ability of a system,
to automatically accommodate larger loads,
by adding resources, either making hardware stronger,
which was scale up, or adding nodes, scale out.
Now in contrast to scalability,
elasticity adapts to both workload increase,
as well as workload decrease by provisioning,
and de-provisioning resources in an autonomic manner.
So think of it as, a kinda a pay-as-you-go model.
So generally, this is how we're gonna define scalability,
and elasticity, but there's a caveat or a caution.
There are some providers who may use these terms,
a little bit differently.
So you wanna be aware of that out in the real world.
But here's why I want you to know these terms for your exam.
Being able to understand scalability and elasticity,
and again, going to talk to that business unit,
decision maker to make sure they understand the difference.
Absolutely, absolutely, critically important,
to be able to do that.
And you know what it is, it's security in action.
All right, there's your word cloud.
Make sure you know all of these things, right?
All the terms, you know what's going on with these,
how we use them, why we care about them.
You always wanna be able to speak to,
any of these terms that you see confidently.
If you can't, go back in through the lesson.
There was a lot of detail in this lesson.
And when you're ready, head on over to the next lesson.
I'll be waiting for you right there.