When function surpasses form, the operating system drops out of the equation.
Will we ever move away from the traditional concepts and definitions of disk, memory, network and CPU for operating systems? We should move, instead, toward the concept of workloads. Every computing service is a workloadâ€”a new mail server becomes a new mail service workload, a new database server becomes a new data storage and retrieval workload and a new virtual desktop becomes a new virtual user interface workload. What we need is a simple workload container pseudo-operating system that makes traditional operating systems (OSs) obsolete.
Last week, I challenged virtualization software vendors and operating system developers to cooperate with one another and to create operating system versions that ship hypervisor-optimized and ready to run as virtual machines. Since I have no fear of this actually happening, Iâ€™m embracing the idea that whatâ€™s really needed are workload containers in which weâ€™ll run our applications and servicesâ€”with no operating system to hinder or complicate matters.
Why would you need a traditional OS to run a java application, a mail service, a database or any workload? Since most users access services over the network and never see the host OS, why should it exist? And, why would any of those workloads require either Linux or Windows? VMware proved that an OS isnâ€™t necessary for a hypervisor host with their ESXi product, so OS-less guests arenâ€™t a big stretch from there.
And Iâ€™m not talking about using some lame marketing ploy by simply renaming everything to make it sound more virtual but actually changing the way those services function to fit into these workload containers.
Can you envision a time when youâ€™ll deploy a new workload to a set of users or on the web with a simple selection from a web-based pick list of services? Itâ€™s possible if you take away operating system specificity. Do users care about the operating system on which theyâ€™re working or where their files are stored? In most cases, they probably do not. Finally, function emerges as more important than form, thereby ushering in an age where vendor and platform specificity disappear into oblivion.
Deploying any workload becomes an act of â€œlever pullingâ€ by a first or second level support jock who responds to routine ticket requests after all of the provisioning and change control matters are resolved by other individuals.
For example, a newly formed group of users requires a new file server with shared storage space. You could engage a System Administrator to install an OS onto a physical machine, configure the file shares, setup the users and send out an email with an explanation of the new service and instructions on how to access it. You could engage a System Administrator to deploy a new virtual machine and perform the same steps that you would for a physical machine. Or, you could engage that first or second level support person to select â€œNew User Storage Serviceâ€ from a pick list, allocate the required amount of storage space and identify the group whoâ€™ll have access and, presto; a new user file storage workload is born.
Virtual Desktops no longer exist (not that they ever did) but have morphed into what I call Virtual User Interfaces (VUI). The VUI is really just a list of virtual applications to which a user subscribes and accesses by virtue of his identity. A user whose job only requires the use of email, a web browser, a word processor and an occasional spreadsheet doesnâ€™t need a fully licensed commercial OS.
Could it be this simple if we remove the OS factor? Yes, it could be.
Workloads will replace operating systems as virtualization and cloud computing pervades our data centers and our lives. Traditional operating systems are passÃ©, heavy, cumbersome and are ready for museums and trivia games. Workloads are the future. Workloads are how computing is done. Workloads make traditional operating systems obsolete. Virtualization makes it possible.
Fatal error: Call to undefined function aa_author_bios() in /opt/apache/dms/b2b/linux-mag.com/site/www/htdocs/wp-content/themes/linuxmag/single.php on line 62