Within any enterprise environment.
We have to look at the different
infrastructure concepts that go within our environment
that can include things as hardware software
networks, endpoint devices, and what most
people miss is usually people themselves.
So let's talk about hardware.
First,
hardware is any device or physical device that's
installed or involved within your enterprise environment.
This is often servers, switches, firewalls, you name it,
if it has a physical construct to it and it's inside your network,
it's considered a hardware specific device within your enterprise environment.
Then there is software software usually resides on the hardware
and that software could be independent of the specific hardware
or it could be dependent upon the hardware itself.
What I mean by that is if I've got
a firewall that has specific software involved in it,
then that is specific to the hardware itself.
I can also have software on a specific server or on another enterprise
device that while it is specifically designed to be on that hardware,
it is interoperable outside of that
hardware infrastructure where dependent upon the hardware
that's utilizing that software goes hand in hand ie firewall or each switch.
Whereas within a server I could have an application
that just checks and monitors
data that's going through it.
Then there's the network itself.
Networks are usually comprised of different
hardware and that hardware usually have a
software component that allows you to communicate from one point to another,
whether it's from your client to a server or from a server to
the network or from a client over the network to another client.
Way out in the middle of nowhere,
your network infrastructure usually comprises advanced
infrastructure and hardware devices that operate
between each other to create a seamless environment of communication.
Then we have endpoint devices,
endpoint devices or a device or a piece of hardware
that is utilized at the end of the network infrastructure.
This is usually clients like a Windows machine or a Mac or even a Lynis.
Uh But it's not usually something that we would consider to
be like a server or a firewall or a switch.
End
devices are specifically at the end of the road.
When it comes to your network IoT devices,
then there's people that actually work within the environment itself.
Those people are responsible for the different maintenance, the operation,
even the installation of new devices that
are interacting within your enterprise environment.
We can't forget about people.
They are the framework and the foundation of any corporate environment.
And people really determine how well or how
ill your enterprise environment is within your different
infrastructure within the different enterprise environments.
Most often we, as our mental picture goes through, we look at an enterprise
environment is being on prem or on premise. Meaning that the physical hardware
devoted to our enterprise environment is something that we could see and touch.
If I have a server go down, I could physically walk into the server room,
unplug it or mess around with it,
jack into it and then change the configuration
files and actually move the cables in a
purely virtual environment. I log into the system.
And while I don't have necessary application to change cables,
I can still change the configuration.
However, in modern technology,
we often have an on prem network that is also using virtualization as a subset.
This is for different purposes
within an on prem network. I usually have a higher data speed, a higher throughput,
more leverage, it's more secure.
And I may need that within the different data
sets that are operating within my enterprise environment.
However, a virtual network provides the advantages of scaling.
I can encompass more users rapidly.
Uh it's quicker for data sets across the world,
meaning that I may have somebody in Italy that needs to access the information.
And since it's virtual, that's easier to get a hold of
and say if the enterprise environment was on prev
so it provides that little bit of availability to it in
a
environment.
However, in modern technology, we do a hybrid network architecture,
this allows us to keep what's secure secure.
And I may have data that need fast, secure access to with robust speeds.
And then there might be data that I need uh availability to across the world or
Scalability where I need the capability to
expand my network architecture very quickly,
which is an advantage of a virtual network by combining the two,
I get the best of both worlds.
Within a serverless architecture.
We are literally tolling something serverless because there is no server.
This is something that we fairly reset in development that allows us
to literally expand our capabilities very quickly in a serverless environment.
I know I keep on saying serverless like you should automatically know what it is,
but it truly is an environment that has no server.
This provides us a lack of management which means I don't have to go through it.
Let's address it. I don't have to do
it every day and change the little
secrecy within an environment on a day to day basis.
It's also event-driven meaning that if an event occurs,
then we go through and if this happens, then this happens,
it auto scales. If I have the capability or if I need more
expandability or more capability to handle more users,
it can auto scale very quickly to encompass
more users simultaneously interacting with that serverless architecture
examples. This would include
Aws or Azure or even Google icloud within a virtual environment.
Virtualization is set up into three different important points isolation
is usually the primary point if I make something virtual,
I can isolate it for the rest of my network
that provides me a secure environment to do testing in,
maybe do some bug hunting,
maybe even some malware analysis by providing
an isolated network within a virtualization.
I can literally go through and fool around with it
without the perceived problem of accidentally screwing something up.
It's not uncommon,
especially a virtualized environment to play around with things.
We obviously don't want to go to a
production environment and start tweaking the settings.
And now we've got our network going all over the place.
Uh Sometimes machines don't like to be messed with.
And so if you change a setting and then you chase, they chase again,
the machine freezes up which just causes all
kinds of problems within our enterprise environment.
It wasn't that long ago when I worked for a different company where we went through
and management came out and said, oh, let's change this
and then it went down to the tech two level and they said, well,
let's change this to encompass this.
Well, that didn't work. Let's change this.
So five or six different iterations later with working with
tech two inside the the environment in a production environment,
the system just stopped operating, it just didn't like it.
And this is bad.
We do not want our production environment to stop operating or to
make it to where we can't actually do anything with it.
By utilizing an isolated virtualized environment,
we can mess around with those settings, see how they interact with software,
see how it's interacting with our other environments all in a virtualized setting
where if it stops working, no harm, no foul, we reboot it.
We start from scratch and once we've identified the solution,
then we roll that out for our production environment.
We can also do resource pooling inside of a virtualized environment.
What I mean by that is inside of a server environment. I have all kinds of resources.
I may have 128 gigabytes of ram and more than enough CPU
power to do anything and everything that I want to do.
And so by doing resource bully,
I can build out different virtualized environments all with a set of ra M,
maybe eight gigabytes of RA M
and set apart
literally 30 different machines to do 30 different processes and
all those resources.
I can also do snapshotting including in my example before,
when we talked about how I've got an environment that I can roll out fixes on.
I can literally take a snapshot of a production server or a production machine,
snap that into a virtualized setting and then work on that
virtualized setting in isolation in order to make it roll out,
it's not unnatural to see something in a virtualized setting and then
want to clone it so that we can fool around with it
or maybe I'm messing around with one isolated environment.
And I said, well, that's pretty good.
And I don't want to
with it, but maybe I want something else so I can continue to work on it.
But if that doesn't work, I want to keep this one,
I simply clone the machine and then I can have an exact copy of
that original virtualized machine to roll out
into a new virtualized machine that then I
messing around with. This is referred to as cloning.
There's two types of hypervisors.
When it comes to virtualized system, there's type one and then type two.
This is thing that you will need to memorize when you're going through your CI S exam.
It's real simple.
A type one virtualized or hypervisor system is a bare metal machine,
meaning it's operating at the core function
of your system.
If I were to take my laptop, wipe it from everything and then put Linux on it.
It is now a Linux machine
that is operating at a hypervisor level. One aspect
with a type two hypervisor. This lays on top of the existing operating system.
So this is what we probably see in something like VirtualBox or virtual
machines where I've got my windows environment that is my core operating system.
But then I'm laying on top of it, a VirtualBox program that has a Linux box on top of it.
In my example, with the last lecture that we talked about,
I was showing you a virtualized system on top of my windows system.
This is indicative of a type two hypervisor where
it lays on top of the operating system.
Finally, we have containerization.
Now containerization and virtualization often
use virtualization involves emulating hardware and
booting a full fledged operating
system within the environment containerization.
In contrast leverages the
most machines operating systems
allow for faster startup and more efficient resource utilization.
While there are some vast similarities between the two,
what you really need to know about containerization is that as a
faster spin apply than what you may see in a virtualized system.
It's very much isolated just like a virtualized system.
I'm portable just like a virtual system sort of, right?
So with a virtual system, if it's sitting on top of a hard drive,
on top of a desktop computer
that's really portable.
But on my laptop, if I have virtualization on, on a VirtualBox,
obviously it's portal.
But that's because my laptop is portable. That's not what we're referring to here.
With containerization, we're truly portable,
meaning that we can move the device or we can move the cURL as we see fit.
And then there's resource efficiency,
containerization is a lot more efficient than virtualization.
The problem of virtualization is I'm stealing from
the main operating system in a type two
where I'm taking it all in a type one, right?
In a type two, we're going to dedicate so much ram to it. We're going to dedicate
processors and it's stealing from that core machine
and that's normal for this type of system.
However, with containerization,
we have a lot more resource efficiency where it can overlap with one another.
And it just provides a more streamlined process. A
lot of times you'll see virtualization for things like I just explained
where I am a at home user and I'm using virtualization,
one to
34 different machines.
And I was spinning those different machines to interact with one another.
In containerization.
I'm using more containerization in an enterprise environment
where I'm literally containing a different server
or different complexities of an enterprise environment.
That's where containerization is utilized because I need that resource.
I should see,
I need that ability to quickly span containerization has a faster spinup time.
It's better for capabilities, aspects of it.
It still provides us that isolation.