A History of Server Application Deployment 2: Virtual Deployment

Let's continue to look at the deployology and history of server application deployment. After the first part of this article dealt with the appearance of the first servers and the necessary technologies for this, we will find out why virtualization was invented and why they tried to improve something that seemed to be working quite well already. In short, laziness and greed are certainly to blame, but let's find out the details and dive into the details.

Let's start the history of virtualization from the distant times when RAM virtualization was first implemented, and that was 1959. The year when the revolution took place in Cuba, the first Barbie was released and the first automatic interplanetary station Luna-1 flew. We will finish this article by talking about serverless computing, the prospects of virtualization in general, and its disadvantages.

And then we'll move on to talking about containers. But that's another story, or rather the next part.

1959: Virtualization of RAM

Early computing machines lacked just about everything except size and mass. But above all, it lacked RAM. In those years, it was made using expensive magnetic core technology, each of which was made by hand. The lack of RAM became critical for tasks that required processing large amounts of data. For example, tasks in scientific computing, aerodynamics and nuclear physics could be particularly sensitive to RAM limitations.

Large programs could not fit in RAM, so it was necessary to break them into fragments and store them on external media, for example, magnetic drums. Competent division of large programs into small fragments and memory management with limited resources was akin to art and required great efforts from the programmer. If a program fragment that was to be executed was outside the main memory, the programmer inserted commands to read this fragment into the main memory from an external medium. Such program fragments were called overlays, and working with them was an essential part of programming.

Overcoming the complexities of working with overlays and mitigating the limitations of available RAM made it possible to combine all available memory: RAM and memory on external media into a single virtual address space in which memory blocks are automatically moved between the main RAM and external devices. This solution was proposed by Fritz-Rudolf Güntsch in his thesis in 1956 and called "Virtual Memory". If a program tries to use a virtual address that has not been entered into RAM, the program is suspended, some part of RAM is freed by writing to external media, and the necessary part of virtual memory is written to the vacated space from the external media. The concept of virtual memory was first realized in the Atlas computer prototype demonstrated by Ferranti in 1959. Virtual memory was able to eliminate the problems of working with overlays, and programmers could worry less about whether their program would fit in RAM. The operating system and hardware took control of moving data and programs around in virtual memory.

RAM virtualization provided not only a way to expand address space, but also opened the door to data isolation, which was especially important for time-sharing systems.

1961: Time-sharing systems

In the early 1960s, research institutes often had only one computer, while the number of scientists who needed to perform calculations was considerable. When a scientist needed a calculation, he or she would create a program with input data and give it to the computer operator. The operator would enter the program and run it, and when the processing was complete, he would pass the result to the scientist. But this approach was not efficient - the computer machine was idle while the program and input data were being entered.

One possible way to solve this problem was to divide the time users spent working with the computer. This meant that while the first operator was processing a program, the second operator could enter the next program and data, thus reducing machine downtime. The idea of such time sharing was first proposed by John Backus and he called it "Time-Sharing System" - Time-Sharing System.

The principle of time sharing was successfully demonstrated in the PLATO II interactive learning system developed by Donald Blitzer and running on the ILLIAC computer, which was introduced in April 1961.

The first time-sharing operating system was the Compatible Time-Sharing System (CTSS), created in November 1961 at the Massachusetts Institute of Technology Computing Center (Comp Center) and operated on a modified IBM 709 machine.

And the first commercially successful time-sharing system was the Dartmouth Time Sharing System, an operating system developed at Dartmouth College in 1964 to give students access to a computing machine, and it ran on a GE-225 mainframe.

At that time, existing batch job processing systems and control languages were easier to implement than time-sharing, which was a much more complex task. Storing the state of each user required RAM and a significant number of clock cycles to switch users, which was not easy for the weak machines of the 1960s.

Time-sharing systems evolved and continued to work until the late 1970s, when computing machines became mass-produced and affordable enough that it was possible to provide each specialist in need with a separate computer and abandon the use of mainframes.

Originally developed to provide multiple access to the resources of a single computing machine and no longer needed in its purest form in the early 1980s, time-sharing technology has evolved and found application in virtualization and multitasking systems. Time-sharing has become one of the mechanisms used in hypervisors to divide physical resources between multiple virtual systems.

1965: Computer emulation

In the early 60s, IBM had two mass-produced mainframe lines: the older 1400-series and the more productive new 7000-series, which were incompatible with each other. This was a problem for customers who found the 1400-series machines cramped, but their software had to be completely rewritten when they switched to the new 7000s. While a competitor in the form of the Honeywell 200 could work with code from the more common IBM 1401. IBM decided to create the most compatible solutions from now on, but this approach required laying the architecture for growth, taking into account future generations of mainframes.  The first line, realizing the new approach to compatibility, was to become System/360. Progressive technical solutions, which were necessary for a significant competitive advantage, made System/360 mainframes incompatible with neither the 1400 nor the 7000 series.

To solve the problem of incompatibility, a member of the IBM System/360 development team, engineer Larry Moss, developed the concept of computer system emulation in 1963.  For this he was nicknamed "the father of emulation". In 1965, the first emulator was developed to run IBM 7070 code on System/360 computers, followed by an emulator to run IBM 1401 code.

The experience gained in creating emulators was another step towards full virtualization. We can say that emulation is a virtual recreation of some of the functions and characteristics of a system that are missing to ensure the correct functioning of a program that was not originally designed to run on that system. At the same time, emulation provides partial isolation of the running program to prevent the program from understanding that it is working in an alien environment. And also to protect the operation of the system from interference of the program, for which the "native" environment is emulated, in sensitive areas. Thus, it can be argued that emulation is partial virtualization, a kind of training before full virtualization.

1966: Virtual machines

The time-sharing approach was not the only approach that was considered for providing multi-user access to a single computing machine. The possibility of running multiple copies of an operating system on a single machine was also considered. The first attempt to create such copies of operating systems was made by IBM on the M44/44X research system built on a modified IBM 7044 (M44) platform. The project was originally planned to explore memory virtualization techniques, including paging - page-based memory swapping. However, when the project's virtual memory goals were achieved, the research continued toward creating multiple partially virtualized copies of the IBM 7044 (44X) system on a single physical machine, which were referred to as "Virtual Machines." The results obtained were far from full virtualization, but showed the possibility of its realization.

Full virtualization was realized in 1966 on a modified IBM S/360-40 research computer as part of Project CP-40. This project was designed to create a computer with multiple access, which was required by the Massachusetts Institute of Technology (MIT) under a grant from the defense agency ARPA. The CP-40 project was to create a time-sharing system, similar to CTSS, that provided multiple user access. However, the researchers took the path of improving on the work of Project 44X and deviated from the task to create systems with full virtualization. The achievement of the project was the launch of 14 virtual copies of the S/360 machine running simultaneously on a single computer. Despite the project's significant virtualization successes, the original goals of the project were not met and the project was scrapped. The researchers made it possible for a single user to run multiple virtual machines when it was necessary to have multiple users running on a single machine. MIT showed no interest in CP-40 and refused to purchase IBM S/360 machines, which was a blow to the company. However, the results of the CP-40 project demonstrated the effectiveness of full virtualization, the feasibility of achieving it on existing hardware, and the advantages of virtualization over time-sharing systems.

Realizing the prospects of virtualization, IBM management continued to develop the ideas obtained in the CP-40 project in a new project - CP-67. In the course of work on which the term "hypervisor" appeared, denoting a program for creating and running virtual machines. The result of the project in 1967 was the CP-67 hypervisor running on the System/360 Model 67 serial computer.

IBM's introduction of virtual machines may have been a bit ahead of its time, but it laid the groundwork for the company's subsequent developments in multi-user and multi-tasking systems, as well as the foundation for the development of virtual and containerized deployment of server applications. IBM continued to expand support for running virtual machines in its operating systems: CP/CMS (1968), VM/CMP (1968), VM/370 (1972), VM/SP (1980), VM/ESA (1990), z/VM (2000).

1985: Emulation on personal computers

In the early 1980s, the mainframe era was nearing its end. The advent of productive and inexpensive personal computers made the use of individual computers a reasonable choice for most tasks, instead of organizing terminal access to expensive mainframes. Personal computers became widely purchased not only by businesses but also by enthusiasts for personal use.

The growing demand for personal computers led to an increasing number of manufacturers introducing their own architectures and equipping their computers with different, often incompatible operating systems. With such a variety of systems, there was a shortage of software, and its availability became a major competitive advantage. To solve the problem of lack of "software", the concept of emulation, which was successfully used on mainframes, was recalled.

The first computer system emulator designed for use with a personal computer was the Microsoft Z80 Softcard. This hardware and software emulator allowed applications for the then popular CP/M operating system to run on Apple II computers. Its original purpose was to allow Microsoft products to run on the Apple II to expand the customer base.

The first "real" software emulator for a personal computer was the Commodore Amiga Transformer in 1985. It allowed a standard Amiga computer to emulate a standard IBM PC.

Next, a number of software emulators were released to run software originally designed to run on other platforms. For example: PC-Ditto (1986, IBM PC emulation on Atari), Rabbit (1988, NES emulation on Amiga), Aladdin (1988, Mac emulation on Atari ST), A-Max (1988, Mac emulation on Atari), SoftPC (1988, DOS emulation on Apple), SoftPC (1989, DOS and Windows emulation on Unix), DOSEMU (1992, DOS emulation on Linux), Shapeshifter (1993, Mac emulation on Amiga).

In 2003 Fabrice Bellard released the open source QEMU emulator. QEMU emulates operating systems, architectures, and peripherals. It is capable of loading guest operating systems including Linux, Solaris, Windows, DOS, and BSD. QEMU supports emulation of various instruction sets: x86, MIPS, ARM v7 and v8, PowerPC, RISC-V, SPARC, ETRAX CRIS, and MicroBlaze. With the advent of hardware virtualization and the KVM and Xen hypervisors discussed below, QEMU has become widely used for virtualization as well.

Software emulation had low efficiency, high overhead, and limited access to some hardware resources. However, it encouraged developers to remember the ideas implemented on large machines and guided them down the path of using virtualization.

1992: Modern hypervisors of the second type

The limitations of emulation have led developers to virtualization as a more efficient solution for running applications designed for a different platform.

Virtual DOS Machine

So in 1992, IBM, with its extensive experience in mainframe virtualization, introduced the OS/2 Virtual DOS Machine (VDM) to strengthen the competitiveness of its OS/2 2.0 operating system. VDM pioneered virtualization on personal computers, supported the x86 8086 virtual mode, and was capable of virtualizing DOS, Windows, and CP/M-86 operating systems. Virtualization in VDM was partial, making greater use of the compatibility built into the original OS/2 operating system, as well as partial emulation to ensure compatibility and functionality.

Virtual PC

In 1997, Connectix, a subsidiary of Apple, released Virtual PC, an application that took full advantage of virtualization. Virtual PC allowed Windows applications to run on a Mac, solving the problem of a shortage of Mac software. In 2001, a Windows version of Virtual PC was released. And in August 2003, Connectix ceased to exist, having previously sold its Virtual PC developments and its unreleased corporate product, Virtual Server, to Microsoft. Connectix's virtualization-related development staff also moved to Microsoft.

VMware solutions

In 1998, VMware was established as a company specializing in the development of virtualization solutions. In 1999, the company released its first product, VMware 1.0, which was distributed free of charge for Windows and Linux operating systems. In 1999, starting with version 3.0, the product was renamed VMware Workstation and was no longer distributed for free. Workstation made it possible to run several different virtual operating systems simultaneously, such as MS-DOS, Windows, Red Hat, SuSE, and FreeBSD. Workstation was most popular among developers and testers, providing a convenient environment for creating and testing software in different operating systems without the need to have physical machines for each of them.

In 2007, VMware created VMware Fusion software hypervisor for macOS systems.  And in 2008, based on the VMware Workstation virtualization kernel, VMware Workstation Player hypervisor was developed, which was distributed for free for Windows and Linux, but had reduced functionality compared to VMware Workstation. Notable was VMware's claim that Player could provide more performance, better graphics and tighter integration when running Windows XP applications than Microsoft's Windows XP Mode running on Windows 7.

Microsoft solutions

In 2004, based on the base acquired from Connectix, Microsoft created a solution for working with virtual machines in Windows - Microsoft Virtual Server. Later, in 2006, a light version of the product was presented - Microsoft Virtual PC, available in versions for Windows and Mac OS. By and large, Microsoft Virtual Server differed from Microsoft Virtual PC in that it did not support multimedia functions, but provided the ability to work with .vhd disks up to 2 TB in size and supported multi-threading of the processor. Windows versions were free to download, which was intended to help strengthen the Windows ecosystem in competition with VMware and Xen. In 2009, Windows Virtual PC was released, a counterpart to Microsoft Virtual PC, supporting more recent Microsoft operating systems such as Windows 7 and Vista.

With the advent of Virtual PC / Virtual Server and VMware Workstation, virtualization ceased to be exotic and became available to everyone. These products were type 2 hypervisors, allowing virtual machines to be run and managed, but dependent on the computer operating system on top of which they were installed and through which they accessed the hardware. Type II hypervisors have relatively high overhead, but they are convenient for testing, developing, and running applications across platforms.

Also worth noting are software hypervisors of the second type such as: Parallels Desktop for Mac (2006), Oracle VirtualBox (2007), QEMU (since 2007 version), bhyve (2014).

1999: A modern hypervisor of the first type

Advances in virtualization on modern personal computers, as well as successful virtualization experiences on large-scale computing systems of the past, have contributed to a renewed interest in the use of virtual machines in the corporate sector and on servers.

VMware solutions

In 1998, VMware was granted patent US6397242B1 for a virtualization method, specifically for a method of starting and managing virtual machines. Based on the patented technology, in 1999 VMware created an internal product, VMware Scalable Server (later renamed VMware Workgroup Server), that allowed multiple virtual machines to run simultaneously on a single host. This product was a type 1 hypervisor, with a kernel running directly on the hardware and its own device drivers and scheduler that allowed it to function independently of the operating system.  The lack of operating system dependency made the Type I hypervisor more stable and predictable, and reduced overhead compared to a Type II hypervisor. These advantages, along with the ability to remotely manage application deployment to hosts that Type 1 hypervisors provided, made application deployment based on them a solution suitable for enterprise use in a production environment.

On the basis of Workgroup Server developments, a commercial product focused on corporate virtualization application - VMware ESX Server (renamed VMware ESXi after version 4.1) - was created in 2001. ESX Server provided high efficiency of interaction with "hardware", could dynamically redistribute computing resources, had remote Web management, Perl scripting environment for managing virtual machines, had backup and rollback tools. ESX Server greatly simplified the deployment of server applications and made this procedure convenient, allowing you to remotely deploy almost everything you need.

ESX Server in 2009 became part of a larger solution, VMware Infrastructure, which included a suite of tools for managing and deploying virtual machines. This package was later renamed VMware vSphere, and expanded its functionality to include resource management, high availability and network virtualization tools. VMware vSphere has become the foundation for many enterprise virtual infrastructures and remains one of the leading virtualization solutions.

Xen

In 2003, the Xen hypervisor for the x86 architecture was released at the University of Cambridge under the leadership of Ian Pratt. The Xen hypervisor differed from ESX Server in its ability to use paravirtualization, with a smaller volume and more modest functionality. Paravirtualization allowed guest operating systems to use some of the Xen kernel resources directly, which significantly reduced overhead, but required modifications to the operating system. However, paravirtualization was unacceptable in some cases and starting with Xen 3.0, the option to choose between full virtualization and paravirtualization was added. The small size and low resource requirements made it possible to create Secure Xen ARM, a version of Xen for the ARM architecture.

Xen, which started as an open source research project, was gaining popularity and it was decided to create a commercial product based on it, for which purpose XenSource Inc. was created in 2004. In August 2006, the Xen 3.0-based XenEnterprise 1.0 enterprise product was released with a graphical interface, live migration and hardware virtualization support.  In 2007, XenSource Inc. was absorbed by Citrix Systems, Inc. and XenEnterprise was renamed Citrix XenServer. In 2013, Citrix opened up the XenServer source code and the Xen project was taken over by the Linux Foundation. Xen and products based on it became a lightweight alternative to products from VMware, keeping virtualization solutions competitive. In 2011, support for Xen as a management operating system - dom0 and guest system - domU was added to the main Linux 3.0 kernel.

KVM

In October 2006, Qumranet, Inc., an Israeli company that develops and supports a desktop virtualization platform, created a solution that allows the Linux kernel to be used as the first type of hypervisor. This solution was developed under the leadership of Avi Kitivi and was called Kernel-based Virtual Machine (KVM). KVM used a modified QEMU to emulate some hardware resources, as well as Intel VT or AMD-V processor hardware virtualization, which will be discussed later. In 2007, starting with version 2.6.20, KVM was integrated into the main branch of the Linux kernel, and the source code for all KVM components was open-sourced. KVM features include support for hot-swappable virtual CPUs, dynamic memory management, and live migration.

KVM has provided a free solution on which systems up to the enterprise level can be implemented, competing with proprietary VMware ESXi and Xen in the virtualization field, becoming one of the most popular tools for virtual deployment of server applications. KVM, in addition to the x86 architecture for which it was originally designed, has been adapted on IBM ESA/390, PowerPC, IA-64, ARM and provides support for a wide variety of guest systems. There are many GUI utilities for managing the KVM hypervisor, such as Virtual Machine Manager, Proxmox Virtual Environment, AQEMU, GKVM, QtEmu, ConVirt, oVirt, Kimchi, and Archipel. Some of them can also manage Xen and QEMU virtual machines.

Hyper-V

In June 2008, Microsoft released the Windows Server 2008 operating system, having had experience with Type 2 hypervisors. It included a Hyper-V component, which together with the operating system formed a hybrid of a type 1 hypervisor and an operating system. These solutions were later referred to as Hybrid Type-1+ hypervisors (Hybrid, Type-1+).  Hybrid hypervisors operate like a typical Type-1 hypervisor, except that they run a specialized operating system on top of the hypervisor, which is used to provide access to physical hardware to guest operating systems and manage them. This combination provided the ease of use of a Type 2 hypervisor with low overhead comparable to a Type 1 hypervisor. However, Windows Server 2008 was relatively resource intensive (compared to the same ESX or Xen), making it less efficient for scenarios with intermittent user activity on the host system.

To reduce the load from the "heavy" Windows Server 2008 operating system, Hyper-V Server 2008 was released in October 2008. It was based on the minimalistic Windows Server 2008 Server Core operating system, where services and roles were limited, except for Hyper-V functionality and those required for initial system configuration. Administration and configuration of the host system was done via remote connection and command line, but guest systems could also be configured using Microsoft management consoles on another Windows computer or using System Center Virtual Machine Manager.

Hyper-V Server and Hyper-V significantly expanded the virtualization capabilities of the Windows ecosystem, enabling efficient deployment of server applications in production environments. Subsequently, Microsoft has been actively developing Hyper-V technology, releasing new versions with improved performance, enhanced management capabilities, support for a wider range of operating systems, including Linux, and adding new virtualization features. Integration with Azure cloud services and security enhancements have also been introduced.

Also worth noting is Oracle's contribution with VM Server (2010), which strengthened the position of virtualized deployment of server applications for the SPARC architecture.

What was originally intended to run applications on other operating systems has evolved with the advent of the global network and servers into something more - virtual deployment of server applications. This has shown its strengths in practice:

• Efficient hardware utilization and high flexibility

Virtual deployment has simplified the process of reconfiguring capacity for another task and accelerated it by making it remote. It is possible to run multiple virtual servers on a single server and efficiently scale capacity, significantly increasing the flexibility of the computing system.

• High availability and easy hardware replacement

Virtual deployment has simplified the process of creating backups and restoring virtual machine state from them, resulting in higher data availability, easier scaling, faster migration and hardware replacement processes, reducing downtime.

• Manage infrastructure and reduce staff workload

Managing a fleet of virtual machines has become easier with the introduction of special software for centralized management of virtual servers. This has reduced the burden on staff and increased the manageability of the infrastructure.

• New approaches to software development

For software developers, virtual deployment has made it easier to tie the product to specific hardware, provided effective tools for testing in a virtual environment, simplified scaling, increased fault tolerance, and facilitated portability of applications between different environments.

The advent of Type 1 hypervisors has significantly changed the way server applications are deployed by improving server manageability, allowing large infrastructures to be managed efficiently and with less strain on staff. Type 1 hypervisors have become a key enabler of cloud infrastructures.

2005: Declarative Configuration Managers

The advent of imperative configuration managers, which I described in the traditional deployment article, made administration much easier. However, the imperative approach had significant limitations because in order to bring the system to the desired state, you had to know the initial state of the system and specify a sequence of actions to bring the system to the desired state. And if the fleet of machines is large, it is necessary to study each machine and build an individual script, and this is very time-consuming and can lead to errors, heterogeneity or inconsistency of configurations. The solution was to create configuration managers that supported a declarative approach to configuration, which consisted in specifying the desired end result, rather than specific steps to achieve it, as in the imperative approach.

The first product to incorporate elements of support for a declarative approach to configuration was CFEngine 2. It was written by Luc Canies under the supervision of Mark Burgess.

Luc Canies, who also had experience developing the ISConf 3 configuration manager, was not satisfied with CFEngine 2 and set out to create his own configuration manager that would be free from the limitations of CFEngine 2, such as: complex syntax, lack of extensive declarative support, difficulty in scaling, limited functionality for dynamic and complex environments. Kanyes' development resulted in the open source configuration management tool Puppet in 2005. Puppet was a powerful and flexible cross-platform solution based on graphs and models, had a relatively easy to understand DSL language, and later received a DSL based on Ruby syntax. Puppet quickly began to gain popularity among system administrators, making their server management tasks much easier, giving them the opportunity to use a declarative approach to configuration, as well as the ability to use the "recipes" of other Puppet community members. Perhaps it was Puppet that pioneered the Infrastructure-as-Code approach - an approach to managing and describing data center infrastructure through configuration files rather than through manual editing of server configurations or online interaction.

In June 2008, Red Hat released its imperative approach configuration manager, Spacewalk, which was designed to manage the configuration of machines on RHEL, and later added support for other Linux distributions. Spacewalk was suitable for installing packages, upgrading, changing settings, and other simple configuration tasks.

In October 2008, Mark Burgess responded to Puppet with his open source product, CFEngine 3, which was a complete reworking of CFEngine 2, eliminating the problems of CFEngine 2, including the complexity of the language syntax. In CFEngine 3 the theory of "promises" was introduced, which, if briefly, implied: declarative description of the desired state of the system - "promises", autonomy in fulfillment of "promises", continuous monitoring of the current state and correction of deviations from "promises". But as it seems to me, many specialists did not want to give CFEngine 3 a chance, because they had negative experience with CFEngine 2. To realize the CFEngine 3 project, Mark Burgess, together with Oslo University College and Oslo Science Park, created the company CFEngine AS. In April 2009, CFEngine AS released its first commercial product based on CFEngine 3 code, CFEngine Enterprise.

In January 2009, Adam Jacob created the Chef configuration management system at Opscode, a consulting company that, among other things, provided comprehensive server and application deployment solutions based on Puppet. The company decided to create its own more flexible product, not wanting to fight the limitations of Puppet when solving its problems. Opscode had an alternative product that allowed working with metadata, had pure Ruby as a language for describing configurations and tasks, had the ability to automate the creation and management of virtual machines in the cloud. Puppet in the person of Chef got a serious competitor, which significantly increased competition and progress in the industry.

In 2010, configuration managers such as Rex, Juju, and Cdist were released.

Cdist was written by Nico Schottelius and Steven Armstrong in Python at the Zurich State Research University. It uses the Bourne Shell for scripting and requires no dependencies on target nodes other than SSH and a Bourne-compatible shell, making it suitable for initial bootstrapping other more complex configuration management systems.

Rex was created by Jan Gehring, Ferenc Erki in Perl and has become a modern and lightweight configuration manager using Perl and its DSL for scripting. Rex integrates well with automated build system, in continuous integration environments.

Juju from Canonical, the developers of Ubuntu OS, was developed in Python and Go. In addition to being a configuration manager, Juju can also perform orchestration and is integrated with major cloud service providers. Configuration is described in YAML and Python, other languages can be used as well. Juju developers have created a framework that will allow ordinary Python or Bash code to be made idempotent and linked to the Juju controller.

In 2011, Puppet Inc. built on Open Source Puppet to create Puppet Enterprise, a closed source enterprise product.

In 2011, the developers of the ZeroMQ fast messaging package created SaltStack (Salt), a Python-based configuration management system with high reliability, excellent scalability, and modularity. Salt has a web interface for executing commands on nodes, monitoring tasks, and tracking node status. Salt configuration files can use YAML templates, Python scripts, or native PyDSL. Interaction with Salt nodes is via SSH or locally installed agents, and nodes can query the master for data. Salt's advantages have made it one of the most sought-after solutions in modern IT environments today.

Also in 2011, Normation's open source configuration management utility Rudder appeared. In Rudder, the developers focused on visualizing the state of nodes and aspects of their configuration. For example, whether ports are open, what state the firewall is in, whether iptables are configured, whether security agents or other components are installed. For example, this approach can be useful for an information security department, as the state of the infrastructure will be in front of their eyes, and if any of the rules turn red, that's a reason to look at the server.

In 2012, Ansible released a configuration management system of the same name, developed by Michael Dehan. Ansible runs over SSH without an agent, with only Python required on the managed node. Configuration in Ansible is described in YAML format, which has lowered the threshold for entry. Ansible is easy to configure and run. Ansible did not have a web interface and was accessed through the CLI. Ansible modules could be written in almost any language. Subsequently, Ansible gained the ability to build and manage infrastructure in cloud environments, becoming one of the most popular configuration management solutions.

In June 2014, a proprietary enterprise solution, Ansible Tower, was released based on Ansible, which added to the regular Ansible: a web interface, a notification system for job completion or failure, role-based access control (RBAC) and the ability to verify who performed which tasks, and support for REST APIs.

In 2017, Red Hat, which absorbed Ansible in 2015, launched the AWX project based on Ansible Tower developments, the code of which was open and was to be modified by the community. And on the basis of AWX code it was planned to release stable versions of Ansible Tower with long-term support. As the opening of the Tower code was delayed, the Ansible community founded two independent projects - Polemarch (2017) and Semaphore (2016), which developed their open source analogs of Ansible Tower.

In 2019, Red Hat introduced the proprietary Ansible Automation Platform, which was an integrated solution that included Ansible, Ansible Tower and Ansible Network Automation, along with additional tools and functionality to manage, orchestrate and automate IT processes. Automation Platform gained new tools for cross-team collaboration, management, analytics and scaling.

In September 2021, Red Hat announced Ansible Automation Platform 2, which separated modules, plugins, roles, and other components from the Ansible runtime and put them into Ansible Content Collections. in Platform 2, Ansible Tower was split into an automation controller and automation execution environments. Content tools have also been added.

Configuration managers - significantly simplified server management and eliminated routine tasks, reducing the likelihood of configuration errors and increasing control. It is very difficult to imagine modern IT without configuration managers, especially when one specialist now has dozens, if not hundreds of times more machines. But configuration managers now acquire other qualities and allow you to create and manage infrastructure in the cloud. The most popular configuration managers today, such as Puppet, Chef, Salt, Ansible, allow you to deploy infrastructure in the cloud using the Infrastructure-as-Code (Iac) approach.

2005: "Hardware" virtualization

The first experience in implementing hardware support for virtualization on personal computers was the technology introduced by Intel in 1985 in the i80386 processor. This technology, called V86 (or VM86), provided the ability to run i8086 virtual machines in protected mode, but with some peculiarities. V86 virtualization was implemented solely to ensure compatibility with older i8086 processor software, not for virtual deployment, which was not yet in demand at the time. However, it may have been the experience with V86 that allowed Intel to be more responsive to hypervisor needs for hardware virtualization support in the future.

In the early 2000s, despite the obvious advantages of virtual deployment, advances in virtualization and the already existing V86 hardware virtualization technology, server hardware was not adapted for virtualization. For example, the most common x86 architecture was designed for use in personal computers, not servers, and no one thought about virtualization on it.  Developing a hypervisor for the x86 architecture was a difficult task that required overcoming technical and privilege level limitations. For example, some guest operating system instructions could be executed directly on the hardware, while other x86 instructions, particularly privilege-sensitive ones, required interception and processing by the hypervisor. Let's call such interceptor-intensive instructions "inconvenient" for virtualization.

One method of intercepting "nuisance" instructions is to analyze all instructions executed by the guest operating system. For example, ESX Server originally used an approach called dynamic binary translation, where "nuisance" instructions are intercepted and redirected to the hypervisor for processing. However, this on-the-fly instruction analysis requires significant computational resources, reducing the efficiency of virtualization.

Another way around the limitations of the x86 architecture is called paravirtualization and was used by the Xen hypervisor. In paravirtualization, the guest operating system was modified so that "inconvenient" instructions were replaced by direct calls to the hypervisor. This approach required adaptation of drivers and some applications for server devices. The disadvantage of this solution was that not all manufacturers were in a hurry to adapt their drivers for virtualization, which limited the choice of hardware.

To simplify hypervisor development and improve virtualization efficiency, Intel introduced support for VT-x hardware virtualization technology into the architecture of the Pentium 4 processor models 662 and 672 released in 2005. But this, was not a hardware hypervisor as the name might suggest. VT-x created an additional privilege mode, root, on which the hypervisor ran, while the operating system ran in a non-root privilege mode, nonroot, which had x86 protection levels inside. Guest OSes running at the nonroot level did not notice any difference compared to running on a processor without VT-x. When "nuisance" instructions are called on processors with VT-x, the process running in non-root mode is stopped, control is passed to the hypervisor to perform actions to emulate the "nuisance" instructions, and then the hypervisor returns control to non-root mode.

In 2006 AMD implemented in some of the Athlon 64 processor models its VT-x analog, which was called AMD-v. Later on, manufacturers added other means of hypervisor control of devices, RAM, and later most of the processes in the system, providing the ability for virtual machines to access real devices.

The introduction of hardware support for virtualization has made it easier to build hypervisors and bring the performance of virtual machines up to a level comparable to that of non-virtualized machines.

2006: Virtual Machines in the Public Cloud

As mentioned earlier, in the article on traditional deployment methods, the idea of a global computing network - the prototype of the modern Internet and cloud solutions - originated in the late 1950s in the works of Dr. Licklider and led to the creation of the first computing network - ARPANET. However, the developments of that time remained largely at the level of abstract concepts, without specifying specific mechanisms of system functioning.

The first known document mentioning the term "cloud computing" in the modern sense is considered to be a presentation created in 1996 by George Favaloro working for Compaq. This presentation showed the idea that in the future local corporate computing power, databases and software could be moved to services available over the Internet.

The development of the Internet in the mid-2000s accelerated progress in virtualization as the need for such solutions increased. On the one hand, there was demand for virtual machines to host websites and applications from companies that did not want to manage physical server hardware and incur the associated costs. And on the other hand, there was a supply from data centers that were able to allocate resources more flexibly and efficiently with the advent of virtual deployment, freeing up computing capacity for rent. As a result, an industry for leasing virtual resources has emerged, and further development of this industry has led to the creation of cloud computing infrastructure provisioning services.

In the Compute Cloud, the user does not have direct access to "hardware", but on demand gets remote access to a virtual computing environment in which they can create, operate, scale virtual machines and the necessary infrastructure without worrying about the hardware.

The beginning of cloud computing was started by Amazon, which launched the Elastic Compute Cloud (EC2) service in 2006. EC2 was originally created to optimize the development process of new products of the company. The company's management noticed that engineers were spending too much time installing software on servers, regularly performing the same type of actions.

To solve this problem, a service was developed that allowed to remotely select a suitable virtual server configuration based on the Xen hypervisor, install the operating system from images, deploy the necessary software and create custom virtual machine images for future reuse. The service has proven itself within the company and was opened to the general public under the model of payment for actual resources consumed.

Amazon's EC2 service has been a breakthrough in server application deployment, ushering in cloud computing and lowering the entry threshold for startups. To deploy a server application with EC2 no longer requires buying and configuring hardware, having in-house IT staff to maintain servers, an EC2 customer is free of hardware risks (well almost). With the EC2 service, customers can easily scale computing power up and down as needed by paying for actual resource consumption (Pay-as-you-go).

The popularity of EC2 led to the emergence of the first competitors. In 2008, services from GoGrid and Mosso, the latter a subsidiary of Rackspace, entered the arena. Both services provided graphical interfaces for managing cloud servers, and for inexperienced users they were more accessible than EC2, which had no graphical user interface.

GoGrid provided an easy-to-use dashboard to configure and deploy load-balanced cloud servers in just a few minutes. Using its API, the service enabled all server management operations available through the web interface.

Mosso, in turn, offered virtual servers with pre-installed operating systems and software, similar to web hosting services. Mosso did not provide root access to the servers, but provided easy monitoring of server status and the ability to quickly scale its computing power. Deploying a server in Mosso required only a few mouse clicks.

In 2010, Rackspace together with NASA launched the OpenStack project, the goal of which was to create a set of software products for the development of cloud infrastructure. As part of the project, Rackspace developed tools for creating services that provide cloud infrastructure. In 2012, Rackspace transferred the rights to the code and trademark of OpenStack to the non-profit organization OpenStack Foundation, which today is called Open Infrastructure Foundation. Today, the Open Infrastructure Foundation has more than 560 members, including such companies as AT&T, Canonical, HP, IBM, Intel, Rackspace, Red Hat, SUSE and many others.

OpenStack is free of charge and its source code is open source. This project makes it possible to deploy a complex cloud infrastructure that includes a variety of components such as virtual servers, routers, load balancers, and storage devices. Cloud infrastructure services based on OpenStack are widespread and popular today. This project has become a key platform for building scalable and flexible cloud services.

To meet the growing demand for cloud computing, services similar to EC2 began to emerge, such as Microsoft Azure Virtual Machines (2010), DigitalOcean (2011), Alibaba Cloud Elastic Compute Service (2011), Google Compute Engine (2012), IBM SoftLayer (2013), Vultr (2014), Hewlett Packard Enterprise Helion (2015), Oracle Cloud Infrastructure (2016).

With the advent of cloud servers, the days when every office had its own server and even small companies had a system administrator on staff began to end. And the developers of server software began to forget how the server looks like in person. Cloud servers made it possible to avoid the complexities associated with the purchase and maintenance of server equipment, giving customers the opportunity to fully focus on their core business.

2010: Serverless Computing

The advent of cloud computing has made it possible to rent virtual servers, abstracting away the physical infrastructure. However, even a virtual server requires pre-configuration, software installation and periodic updates, scaling of computing power, and server status monitoring and management. Performing these tasks is often routine and consumes a significant amount of staff time. At the same time, there is a risk that important details may be overlooked during the tasks, such as missing a critical update, the absence of which would significantly degrade security.

Serverless computing has become a solution that relieves the client of the worries associated with maintaining the performance of virtual servers. They allowed to abstract from the "hardware" on which the client's code is executed, from the software and the tasks of scaling computing power. All of this in serverless computing is handled by the provider's automated systems, allowing the client to focus on the realization of his ideas in the code.

One of the implementations of serverless computing is the Function-as-a-Service (FaaS) service. As part of such a service, the provider provides the client with a platform that allows launching small isolated functions that perform specified operations in response to a call or an event. The provider automatically scales the capacity required to run functions and ensures their parallel execution, which can be used in the implementation of microservice architecture of applications. The provider can set limits on the functions to be executed, for example, such as the maximum execution time of a function and a limit on the ability to save state.

The first pay-as-you-use code execution platform was Zimki. However, ahead of its time, it was not appreciated by Canon, which owned it, and the project was not developed.

The next to try to implement FaaS was the startup PiCloud. In 2010, they offered customers the ability to run Python code in their environment. PiCloud claimed that their solution "eliminates the need for servers" and allows developers, scientists, and engineers to easily build and customize applications directly in the cloud. Despite the ambitious claims, PiCloud, developed with the support of venture capital firm Lightspeed Ventures, unfortunately did not survive to this day.

The first commercially successful FaaS implementation did not appear until 2014 - it was Lambda from Amazon Web Services (AWS). It was AWS that introduced the term "Function as a Service" (FaaS) and set standards for such services as pay-as-you-use, instant scaling, integration with cloud services, and event-driven architecture.

Lambda was designed for deploying small software components that run with low latency (milliseconds) when events occur. It provided a high degree of computational parallelization and could run components in the required number. Initially, Lambda supported JavaScript with Node.js and had integration with AWS services: S3, DynamoDB and Amazon Kinesis.

The popularity of AWS Lambda grew rapidly and other major cloud providers began developing their own FaaS services, peaking the emergence of these services in 2016-2017.

The first to compete with Lambda in February 2016 was Google Cloud Platform with its FaaS solution, Google Cloud Functions, which allowed you to run event-driven code written in Node.js, Java, Python or Go.

Oracle Cloud Infrastructure in October 2016 introduced Oracle Cloud Functions, a platform based on the open source Fn project. Fn allowed you to build your own cloud and on-premises environments to run serverless applications. Cloud Functions supported code in Python, Go, Java, Ruby and Node.js.

Azure Functions, Microsoft's FaaS implementation of Azure Functions, went public in November 2016, and the Alibaba Cloud Function Compute service was launched in December.

Another solution that allowed you to implement FaaS on your on-premises or cloud infrastructure was the OpenFaaS open source project founded by Alex Ellis in January 2017.

Further FaaS launches include IBM Cloud Functions (March 2017), Twilio Functions (May 2017), iron.io (May 2017), Cloudflare Workers (October 2017), and Netlify Functions (October 2018).

The advantages of serverless computing include: savings on virtual server maintenance and reduced management complexity by not having to manage the infrastructure, deployment and orchestration of their applications; excellent scalability; development flexibility through the use of different languages and technologies; and compatibility with other technologies.

But serverless computing has disadvantages, such as: delayed execution of a function when it is not in memory; difficult portability of functions in case of integration with other vendor services; disadvantages of a fully managed platform, such as unforeseen behavior of a function during peak loads, slow troubleshooting of security issues, or security policies that do not match customer needs.

Still, for many tasks, the advantages of Function-as-a-Service services outweigh the disadvantages, and such services are becoming increasingly popular, showing almost double year-on-year growth in usage for several years in a row. However, the peak of the serverless computing hype has passed, with growth of around 25% expected this year (2023). Demand is pushing the development of the serverless computing ecosystem. New tools for development, testing, and feature management are emerging. Third-party developers are creating libraries and frameworks to facilitate serverless functions. Most modern serverless computing solutions are now implemented using containerized deployment, the history of which I will discuss in the next article in the series.

Serverless computing can be seen as the final point of virtualization development, in which the server infrastructure is completely hidden from the developer. In this model, developers focus solely on writing code for functions that perform specific tasks.

Perspectives on virtual deployment and its drawbacks

Virtual deployment offers a number of advantages and can be effective over traditional deployment in many cases. Virtual deployment can provide flexibility, resiliency, scalability and efficient resource utilization. It can also simplify software testing and development, facilitate application portability, and provide a means for centralized administration.

While progressive, virtual deployment is not perfect and has weaknesses compared to traditional deployment:

• Overhead

A virtualization system requires additional resources (CPU, memory, disk space) for its operation. Virtualization overhead can range from 2% to 15%, which can be critical for some tasks. However, given the more efficient resource utilization and flexibility of virtual deployment, the benefits of virtualization outweigh this disadvantage.

• Higher latency

Virtual machines operate at the hypervisor level, which creates an additional layer of resource management abstraction, resulting in some processing delays. But in practice, this may be critical only for a very narrow class of tasks, such as in real-time systems.

• Increased complexity of administration

Virtual deployment requires staff administering virtual servers to understand virtualization architecture and virtual machine configuration, resource management skills, and virtualization-specific tasks.  However, virtual deployment also provides convenient centralized administration tools that automate many tasks, such as installing and configuring virtual machines, monitoring and managing resources, backing up and restoring data, and managing network infrastructure.

• Paid solutions

Some virtual deployment solutions can be paid for.

Once we understand the limitations of virtual deployment we can move on to the history of container deployment, which will tell how IT innovators have tried to get around the drawbacks and build on the advantages of virtualization.