Welcome back to this module. And the last module we looked at, how technologies like network virtualization, along with storage virtualization and configuration management tools like Chef, Puppet etcetera, helped us in terms of optimizing the process of developing applications and pushing them to a production ready environment. Now in today's world, businesses have to move at a scale that is really fast, really dynamic and technology is at the center of every business. Every business needs technology to interface with their customers and the way they develop this technology or the way they build their platform, that interfaces with their end users or the consumers or our customers really can make or break a business today. And as a result of this, these platforms, these interfaces, these applications have to be dynamic in nature. It's no longer okay for business to have a platform that needs a maintenance window of over eight hours in order to push a simple update.

That's just not how businesses today are running. Imagine if amazon.com had to update its inventory, it cannot wait to carve out a maintenance window. And then somebody updates it inventory. Somebody updates a database in the backend so that the new inventory is in place, new products to their inventory. And so the systems that maintain these kinds of platforms have to be dynamic in nature. They have to have the room where certain services still continue to exist, even if something else is getting updated.

And as a result of that, we have to push our process, even further than that. We have to push our systems to be fast and to be dynamic in nature for these businesses to operate. Now from an obstruction perspective, if you look at what we spoke in earlier modules, we have obstructed away a lot of infrastructure components like compute, network, storage, etcetera, in order to optimize the platforms in order to bring automation capabilities to these platforms so that they can be managed much more efficiently.

But again I think that is as much as we can go in terms of extracting resources, there's nothing really left in infrastructure to optimize, to give us those efficiencies. And hence now is a time where we look into maybe the operating system that is managing each virtual machine to see if we can bring further efficiencies to the system. Now, if look at the way, a particular kernel or domain or trading system for example, the way Linux operates today, right? If you look at each processes or each application, an application that is running on a Linux kernel would have a process ID tied to it.

And that process in turn would manage, or would utilize the underlying resources, whether it's compute, network, storage etcetera. So each process is bound. Each application is bound to a set of processes. What if we bring abstraction at the process level. Where in a single process can have a single application that utilizes all the required resources and are parallel to another process so that the way virtualization is going to abstract the infrastructure in order to give CPU cycles to multiple operating systems within an operating system, why can't the process do the same?

And this is essentially, isolating this process and giving each process enough resources so that they can, run parallely on a single operating system is the basis of containers. Now let's take a look what happens when we bring containers into this realm, right? Let's say we have containers created. And instead of utilizing virtual machines as a unit of transferring an application code or application binaries, they're utilizing containers as a way to transact different stages of application life cycle. Now you'll see that when it comes to utilizing containers, there's really not much of a difference if you're just trading containers with virtual machines.

From a process perspective, this is what it looked like with virtualization and watching machines, being a unit of the binary that holds an application. You were utilizing virtual machines to transfer application code, and now you're utilizing a container to transfer the same application code. The overall process hasn't changed a lot. And if you look at development teams, they're still deploying and developing their applications on their local laptops, using containers, they're still transferring containers to different teams IT or organizations or DevOps teams are still utilizing containers as a way to deploy applications.

But then how about scaling things? How about maintaining state? How about building systems where there's dynamic routing, things like that? Containers again, it needs a set of IP addresses. It's still has the same networking requirements. It still has the same storage requirements, etcetera. So from a process optimization perspective, just switching containers is not going to help us a ton. It might have helped us in terms of how smaller the footprint becomes of the application bits that is being transferred over. But apart from that, just replacing your existing applications with container is not going to overall have a huge impact on the process of what we are trying to make more efficient, which is application being developed and deployed.

Now to get further optimization, we need something or an orchestration system that can help us manage these containers, right. Just deploying containers is not going to help. We need systems in place that can help us manage, deploy them automatically, scale them and route traffic to them, etcetera. And that is where Kubernetes comes into play right? Kubernetes is going to help us not just deploying applications using containers, but then it is also going to help us maintain state, do a lot of the things that we want a platform that is dynamic to do.