KubeAcademy by VMware
Problems with Compute Virtualization and How They Were Solved
Next Lesson

While compute virtualization brought efficiencies to application development, when it came to application deployment and maintenance, the same efficiencies did not apply. In this lesson, we talk about how the invention of network and storage virtualization helped solve problems with just compute virtualization. We also look at how this impacted the converging the roles of network, storage and database administrators.

Boskey Savla

Senior Technical Marketing Architect at VMWare

Boskey Savla is Technical Marketing Manager @VMware focusing on Cloud Native Applications, she has 15 years of experience in systems and operations.

View Profile

Now in the last module, we looked at how compute virtualization helped optimize the process of code that was being written and then deployed. Now, we looked at how compute virtualization helped bring efficiencies in terms of how developers started coding on their laptops or desktops versus how IT teams were utilizing things like virtual machines as a unit of compute and deploying applications via virtual machines.

There were still things that could have been optimized further, for example, to scale an application, you could scale virtual machines but then in terms of finding storage, in terms of configuring network, all these steps were still manual or even if they were automated, this still meant that somebody had to file a ticket, talk to that different team, provision enough resources and then scale out that application. Same for maintenance and same for upgrading, cycling through bugs, et cetera. A lot of this, again changed when we applied the principles of virtualization to storage and networking.

So rather than having storage and network as completely different entities outside of virtualization, with compute and storage virtualization, we brought the concept of virtualization to these different resources that an application needs. And by doing so, we actually reduced the complexity and the overall efficiency in again, pushing an application from being developed to being deployed. Now for the first time, if you look at storage and compute virtualization, because we were utilizing compute resources, we were able to derive compute resources via software defined architectures, it was now possible to programmatically derive these resources based on application needs.

Another thing that happened with the virtualization of compute and storage and network is that the teams that were handling different processes and different segments like the network team, the storage team, the compute team, they all had to come together in order to work and deploy an application. This also paved ways for career changes where a person who was maybe managing just Linux systems started managing platform like a virtual platform, a software defined platform. The teams that were only managing storage or networking started expanding their roles into looking at a bigger picture and expanding roles and capabilities to not just provision of specific resource but operate an entire platform.

From an evolution perspective, I think this entire storage Network Virtualization helped our process of bringing applications, deploying applications pretty immensely. And if you look at our four pillars that we have been talking about, because now we are converging the constructs of compute network and storage into a single entity, that the silos between different teams were broken as a result of this. The maintenance window that needed to be carved out was also reduced because no longer there is a need to talk to a different team to carve out storage, to carve out network, because all the network and virtualization and storage elements are virtually defined. You can program these interfaces, you can take an API call to the storage provider and provision automatically virtual resources.

Similarly, the complexity to scale also reduce because again, we're able to extract resources programmatically rather than having to file tickets to different teams. And overall, the platform evolved from just optimizing hardware to optimizing every resource needed to deploy an application, to operate an application. This evolution or this process was further optimized with the practices of DevOps, right? So rather than defining or calling different API's for different software, network providers, et cetera. DevOps created a neutral platform, a neutral language through which you could define different processes, automate different systems and bring further efficiencies to this entire process of code being written to being pushed into production.

Now, from a career perspective, again, teams evolved, right? The teams that were managing the platform or the teams that we're deploying or writing applications, some of them had to think about or rethink about how this application is going to be pushed into production. And what is it that I need from this application when it's deployed. Developers started thinking of the end state of that application and define that end state through DevOps practices. The same time operation team started automating a lot of these provisioning steps through things like Chef, Puppet, Ansible. All of these things helped contribute to make things a lot more efficient from a provisioning, maintaining and then developing or maintain the entire lifecycle of an application.

From four pillars perspective, if you look at our interactions between siloed teams, it again reduce a lot further because now, not only the operations teams were talking to each other but the development teams were talking to the operation teams in order to carve out the final state and define what automation needs to be in place for that application to be deployed automatically.

So the practices of DevOps really brought together these operations and development teams together. It helped lower the maintenance windows of maintaining or patching applications a lot further because automation was brought in. With help of automation, you could define an end state and then something like Chef, Puppet, Ansible, et cetera or the configuration management tools would go ahead and carve out the appropriate resources.

So the overall process of deploying and developing an application, pushing that into a production ready system, maintaining it, scaling it was optimized a lot with the combination of virtualizing not just compute, storage and network, but again, bringing in DevOps practices, bringing in configuration management tools to optimize this entire process.

Now, if you look at it, this is where most of us are today. Maybe each person is in a different spectrum but somewhere between three virtualization and DevOps practices, every industry or every organization has a varying set of capabilities and the way they define and write their application. However, if you look at the time still taken, there is still room for improvement, right?

If in today's world where something like amazon.com exist, which is updating its inventory by every second you cannot expect just a DevOps practice, just virtualization is going to help solve for that, right? You need systems where dev teams can actually test, validate two A/B testings, route traffic dynamically, provision and scale systems automatically, descale automatically and things like that. So the overall process that we have today works but there is room for optimization and for certain applications, definitely, you need a platform that can help this process even further.

Give Feedback

Help us improve by sharing your thoughts.

Share