WEBVTT

00:00.760 --> 00:03.490
Let's start with
how application delivery works

00:03.500 --> 00:05.260
in a traditional infrastructure model

00:05.260 --> 00:07.630
and how it evolved
with the emergence of

00:07.630 --> 00:11.430
technologies such as cloud computing
and Infrastructure as Code.

00:12.340 --> 00:15.710
Let's go back in time and look at
how infrastructure was provisioned

00:15.710 --> 00:17.360
in the traditional IT model.

00:18.440 --> 00:22.230
Let us consider an organization that
wants to roll out a new application.

00:22.930 --> 00:25.660
The business comes up with
the requirements for the application.

00:26.400 --> 00:29.190
The business analyst then gathers
the needs from the business,

00:29.200 --> 00:30.230
analyzes it,

00:30.230 --> 00:33.700
and converts it into a set of
high-level technical requirements.

00:34.300 --> 00:36.730
This is then passed on
to a solution architect.

00:37.750 --> 00:40.830
The solution architect then designs
the architecture to be followed

00:40.830 --> 00:42.530
for the deployment
of this application.

00:43.720 --> 00:46.530
This would typically include
the infrastructure considerations,

00:46.530 --> 00:50.030
such as the type, spec, and
count of servers that are needed,

00:50.270 --> 00:52.560
such as those for
front-end web servers,

00:52.560 --> 00:55.930
back-end servers, databases,
load balancers, et cetera.

00:56.990 --> 00:59.200
Following the traditional
infrastructure model,

00:59.590 --> 01:00.930
this would have to be deployed

01:00.930 --> 01:03.500
in the organization's
on-premise environment,

01:03.630 --> 01:06.830
which would mean making use
of the assets in the data center.

01:08.160 --> 01:11.360
If additional hardware is needed,
they would have to be ordered

01:11.360 --> 01:12.560
via the procurement team.

01:13.260 --> 01:15.330
This team will put in
a new hardware request

01:15.330 --> 01:16.500
with the vendors.

01:17.380 --> 01:21.430
It can then take anywhere between
a few days to weeks or even months

01:21.430 --> 01:24.400
for the hardware to be purchased
and delivered to the data center.

01:25.420 --> 01:27.110
Once received at
that the data center,

01:27.310 --> 01:29.360
the field engineers
would be in charge of

01:29.360 --> 01:31.200
rack and stack of the equipment.

01:31.960 --> 01:35.230
The system administrators
perform initial configurations

01:35.230 --> 01:39.060
and the network administrators make
the systems available on the network.

01:40.100 --> 01:42.660
The storage admins
assign storage to the servers,

01:42.660 --> 01:44.730
and the backup admins
configure backups.

01:46.060 --> 01:49.830
Finally, once the systems have been
set up as per the standards,

01:49.830 --> 01:52.460
they can then be handed over
to the application teams

01:52.460 --> 01:54.100
to deploy their applications.

01:54.690 --> 01:55.990
This deployment model,

01:56.000 --> 01:58.100
which is still quite
commonly used today,

01:58.420 --> 02:00.200
has quite a few disadvantages.

02:01.020 --> 02:04.060
The turnover time can range
between weeks to months,

02:04.060 --> 02:06.590
and that's just to get
the systems in a ready state

02:06.600 --> 02:08.300
to begin the application deployment.

02:09.400 --> 02:12.690
This includes the time it takes for
the system to be initially procured,

02:12.700 --> 02:14.700
and then handed over between teams.

02:15.920 --> 02:19.190
Also, scaling up or scaling down
the infrastructure on demand

02:19.200 --> 02:20.660
cannot be achieved quickly.

02:21.760 --> 02:24.530
The overall cost to deploy
and maintain this model

02:24.530 --> 02:25.800
is generally quite high.

02:26.810 --> 02:29.510
While some aspects of the
infrastructure provisioning process

02:29.510 --> 02:30.730
can be automated,

02:30.730 --> 02:32.960
several steps such as
the rack and stack,

02:32.960 --> 02:36.330
cabling, and other deployment
procedures are manual and slow.

02:37.580 --> 02:40.560
With so many teams working on
so many different tasks,

02:40.980 --> 02:42.960
chances of human error are high,

02:42.960 --> 02:45.460
and this results in
inconsistent environments.

02:46.470 --> 02:50.260
Another major disadvantage of using
this model is the underutilization

02:50.260 --> 02:51.800
of the compute resources.

02:52.730 --> 02:55.360
The infrastructure sizing activity
is generally carried out

02:55.360 --> 02:56.560
well in advance

02:56.560 --> 02:59.560
and the servers are sized
considering the peak utilization.

03:00.960 --> 03:03.830
The inability to scale up or down
easily means

03:03.830 --> 03:07.630
that most of these resources would
not be used during off-peak hours.

03:09.080 --> 03:11.960
In the past decade or so,
organizations have been moving

03:11.960 --> 03:15.890
to virtualization and cloud platforms
to take advantages of services

03:15.900 --> 03:17.890
provided by major cloud providers

03:17.900 --> 03:20.860
such as Amazon, AWS,
Microsoft Azure,

03:21.180 --> 03:23.100
Google Cloud Platform, et cetera.

03:24.240 --> 03:27.460
By moving to cloud, the time to
spin up the infrastructure

03:27.700 --> 03:29.690
and the time to
market for applications

03:29.700 --> 03:31.160
are significantly reduced.

03:32.050 --> 03:33.460
This is because with cloud,

03:33.640 --> 03:35.830
you do not have to
invest in or manage

03:35.830 --> 03:38.670
the actual hardware assets
that you normally would

03:38.670 --> 03:41.100
in case of
a traditional infrastructure model.

03:42.570 --> 03:46.060
The data center, the hardware assets,
and the services are managed by

03:46.060 --> 03:47.160
the cloud provider.

03:48.210 --> 03:50.860
A virtual machine can be
spun up in a cloud environment

03:50.860 --> 03:52.130
in a matter of minutes,

03:52.680 --> 03:55.460
and the time to market is
reduced from several months,

03:55.660 --> 03:57.860
as in the case of
a traditional infrastructure,

03:58.090 --> 03:59.830
to weeks in a cloud environment.

04:01.870 --> 04:04.530
Infrastructure costs are
reduced when compared with

04:04.530 --> 04:07.900
the additional data center
management and human resources costs.

04:09.270 --> 04:12.030
Cloud infrastructure
comes with support for APIs,

04:12.030 --> 04:13.260
and that opens up

04:13.260 --> 04:15.930
a whole new world of
opportunity for automation.

04:17.420 --> 04:21.040
Finally, the built-in auto-scaling
and elastic functionality of

04:21.040 --> 04:23.860
cloud infrastructure
reduces resource wastage.

04:25.200 --> 04:26.960
With virtualization and cloud,

04:26.960 --> 04:29.960
you could now provision
infrastructure with a few clicks.

04:30.760 --> 04:33.520
While this approach is
certainly faster and more efficient

04:33.520 --> 04:35.930
when compared to
the traditional deployment methods,

04:36.310 --> 04:38.730
using the management console
for resource provisioning

04:38.730 --> 04:40.660
is not always the ideal solution.

04:41.370 --> 04:44.030
It is okay to have this approach
when we are dealing with

04:44.030 --> 04:45.530
a limited number of resources,

04:45.910 --> 04:47.400
but in a large organization

04:47.560 --> 04:50.030
with elastic and
highly scalable cloud environment

04:50.030 --> 04:53.200
with immutable infrastructure,
this approach is not feasible.

04:54.610 --> 04:57.930
Once provisioned, the systems still
have to go through different teams

04:58.070 --> 05:01.330
with a lot of process overhead
that increases the delivery time.

05:01.960 --> 05:04.590
The chances of human error
are still at large,

05:04.600 --> 05:06.830
resulting in
inconsistent environments.

05:08.350 --> 05:11.360
Different organizations
started solving these challenges

05:11.360 --> 05:14.600
within themselves by developing
their own scripts and tools.

05:15.320 --> 05:19.160
While some use simple shell scripts,
others used programming languages

05:19.160 --> 05:22.030
such as Python, Ruby,
Perl, or PowerShell.

05:23.150 --> 05:25.430
Everyone was solving
the same problems,

05:25.760 --> 05:27.830
trying to automate
infrastructure provisioning

05:27.830 --> 05:29.460
to deploy environments faster,

05:29.800 --> 05:33.160
and in a consistent fashion by
leveraging the API functionalities

05:33.160 --> 05:35.060
of the various cloud environments.

05:36.530 --> 05:39.630
These evolved into a set of
tools that came to be known as

05:39.630 --> 05:41.160
Infrastructure as Code.

05:42.360 --> 05:43.380
In the next lecture,

05:43.380 --> 05:45.890
we will see what
Infrastructure as Code is

05:45.900 --> 05:47.060
in more detail.