Let's start with how application delivery works
in a traditional infrastructure model
and how it evolved with the emergence of
technologies such as cloud computing and Infrastructure as Code.
Let's go back in time and look at how infrastructure was provisioned
in the traditional IT model.
Let us consider an organization that wants to roll out a new application.
The business comes up with the requirements for the application.
The business analyst then gathers the needs from the business,
analyzes it,
and converts it into a set of high-level technical requirements.
This is then passed on to a solution architect.
The solution architect then designs the architecture to be followed
for the deployment of this application.
This would typically include the infrastructure considerations,
such as the type, spec, and count of servers that are needed,
such as those for front-end web servers,
back-end servers, databases, load balancers, et cetera.
Following the traditional infrastructure model,
this would have to be deployed
in the organization's on-premise environment,
which would mean making use of the assets in the data center.
If additional hardware is needed, they would have to be ordered
via the procurement team.
This team will put in a new hardware request
with the vendors.
It can then take anywhere between a few days to weeks or even months
for the hardware to be purchased and delivered to the data center.
Once received at that the data center,
the field engineers would be in charge of
rack and stack of the equipment.
The system administrators perform initial configurations
and the network administrators make the systems available on the network.
The storage admins assign storage to the servers,
and the backup admins configure backups.
Finally, once the systems have been set up as per the standards,
they can then be handed over to the application teams
to deploy their applications.
This deployment model,
which is still quite commonly used today,
has quite a few disadvantages.
The turnover time can range between weeks to months,
and that's just to get the systems in a ready state
to begin the application deployment.
This includes the time it takes for the system to be initially procured,
and then handed over between teams.
Also, scaling up or scaling down the infrastructure on demand
cannot be achieved quickly.
The overall cost to deploy and maintain this model
is generally quite high.
While some aspects of the infrastructure provisioning process
can be automated,
several steps such as the rack and stack,
cabling, and other deployment procedures are manual and slow.
With so many teams working on so many different tasks,
chances of human error are high,
and this results in inconsistent environments.
Another major disadvantage of using this model is the underutilization
of the compute resources.
The infrastructure sizing activity is generally carried out
well in advance
and the servers are sized considering the peak utilization.
The inability to scale up or down easily means
that most of these resources would not be used during off-peak hours.
In the past decade or so, organizations have been moving
to virtualization and cloud platforms to take advantages of services
provided by major cloud providers
such as Amazon, AWS, Microsoft Azure,
Google Cloud Platform, et cetera.
By moving to cloud, the time to spin up the infrastructure
and the time to market for applications
are significantly reduced.
This is because with cloud,
you do not have to invest in or manage
the actual hardware assets that you normally would
in case of a traditional infrastructure model.
The data center, the hardware assets, and the services are managed by
the cloud provider.
A virtual machine can be spun up in a cloud environment
in a matter of minutes,
and the time to market is reduced from several months,
as in the case of a traditional infrastructure,
to weeks in a cloud environment.
Infrastructure costs are reduced when compared with
the additional data center management and human resources costs.
Cloud infrastructure comes with support for APIs,
and that opens up
a whole new world of opportunity for automation.
Finally, the built-in auto-scaling and elastic functionality of
cloud infrastructure reduces resource wastage.
With virtualization and cloud,
you could now provision infrastructure with a few clicks.
While this approach is certainly faster and more efficient
when compared to the traditional deployment methods,
using the management console for resource provisioning
is not always the ideal solution.
It is okay to have this approach when we are dealing with
a limited number of resources,
but in a large organization
with elastic and highly scalable cloud environment
with immutable infrastructure, this approach is not feasible.
Once provisioned, the systems still have to go through different teams
with a lot of process overhead that increases the delivery time.
The chances of human error are still at large,
resulting in inconsistent environments.
Different organizations started solving these challenges
within themselves by developing their own scripts and tools.
While some use simple shell scripts, others used programming languages
such as Python, Ruby, Perl, or PowerShell.
Everyone was solving the same problems,
trying to automate infrastructure provisioning
to deploy environments faster,
and in a consistent fashion by leveraging the API functionalities
of the various cloud environments.
These evolved into a set of tools that came to be known as
Infrastructure as Code.
In the next lecture,
we will see what Infrastructure as Code is
in more detail.