Traditional application deployment. Hello dear friends. In this lesson, we will talk about traditional application deployment. First and foremost, I'd like to define it: Application deployment, also known as software deployment, is the process of installing, configuring, updating, and enabling one application or suite of applications that make a software system available for use. You know, for every software development firm, there comes a time when their software will need to be changed or upgraded. It can come in the form of a total version change or fixing a bug found in the original version. In the early days of software development, applications used to serve a limited number of users. In some cases, application servers weren't even needed. Well, time has flown and applications began to serve a vast number of users. New needs were constantly emerging and updates were made to the software according to these needs. Therefore, application deployment became a fundamental job.

That's how our traditional software deployment infrastructure came about. The traditional deployment of the following of these steps from the initialization: Preparation of the operating system and physical environment such as network, disk, etc. Installation of tools that your application needs such as databases, application servers, streaming tools, etc. Installation of dependencies of your software such as libraries. Load and run your software on an application server. Once you initialize the environment and run your application on later deployments, you generally need to do the load and run phase. There are some benefits and drawbacks to traditional deployment. Probably the most important benefit of this aspect is that it is easy to do. The other benefit is that tracking an error or bug is less complicated. I want to show you a basic schema about methods of application deployment to help you figure it out better. The first shape represents the traditional method.

As you can see it is tightly bound to the operating system and physical server. The second represents the virtualization method. As you can see here, there's significantly less dependency between the application and the operating system. The third represents the containerization method. In this method there is no need for an operating system at all, you only need libraries within containers. As time passes and requirements grow, so has the search for an alternative to the traditional method since the drawbacks of the approach act as a barrier to progress. The drawbacks are as follows: Scaling, when the number of your application users increases, generally your application server and other tools need more power to carry out transactions. In a traditional method, the only trump in your hand is to increase RAM, or as a more radical solution, upgrade your server. After a while, even these will not be enough for you. Downtime: the other drawback is downtime.

When you do your deployments using the traditional method, the strategy is generally recreate, which means you need to stop the application server, move the old version, load the new one and start the server. As you see, it will take a while for the deployment and it will cause downtime. Not suitable for continuous development. This is an important drawback. Nowadays, everything is improving at a  lightning speed and you need to keep up with the development. Although there are some tools to make your job easier with the traditional method, it's still inadequate because of some dependencies, such as the operating system and physical server it's running on. All right, so that's an introduction to traditional application deployment. I hope to see you in the next lesson.