As a result, we have a very powerful computer that needs to have an operating system installed on it, which would allow us to utilize all of our hardware resources. In general, the type of operating system is not that important here because essentially it will act as a layer between our hardware resources and the special software that would enable the operation of virtual machines. However, personally, I would choose to install Linux :)
Let's call this software - a virtualization system. There are quite a few of such systems, but in my opinion, the most well-known ones are VMWare, Hyper-V, and KVM. If you're interested, you can learn more
about them (there is a big world of extremely interesting technologies on how virtualization works with hardware resources), but I will focus on the fact that these systems can do the most important thing for us - create virtual machines, using the hardware resources of the server on which they are running. And not just create them, but do so in a way that virtual machines do not know about each other and cannot "intrude" into each other's resources, even though they will actually be executed on the same CPUs and share the same RAM. This is the main "pillar" on which all clouds are based. In reality, of course, everything is more complicated, and there will be a lot more things running on in the server's operating system, but we will focus on the most important aspects.
In Azure, with its scale, a combination of virtualization systems is most likely used. It would be strange if Microsoft itself did not use Hyper-V, but it would also be strange to ignore the benefits of KVM :)
So, virtualization systems are capable of creating, modifying, and destroying virtual machines. But who and how will tell them when and which virtual machine to create and on which server? This is where the main components of the cloud come into the game: compute, network, and storage orchestrators. Why specifically these? Because they are the three most important components of the IaaS layer. (Even GPUs here look like a small option :)
- The Compute orchestrator manages virtual machines on which literally everything runs in the cloud.
- The Network orchestrator manages routers that provide physical network connectivity between servers, racks, data centers, etc. This orchestrator also manages load balancing and traffic routing issues.
- The Storage orchestrator manages storage arrays, allocating resources for virtual machines and higher-level services (such as Azure Storage).
An orchestrator is already something like "cloud" services within a "cloud" service. It must have an internal endpoint, some authentication system, and a REST API so that it can be asked to execute a particular command. But where will the orchestrator store the current configuration of the resources? Of course, it could be stored in some blob inside the storage array, but I would choose a very reliable database that can scale at the level of the entire cloud. Let's assume it is an internal installation of Cosmos DB
But now we have another question. Where does all this work? This is where the term Dogfooding
comes in. The idea is that inside your system, you should use components of the system itself. In other words, if we allow our users to work with virtual machines, why not use the same virtual machines for our own needs? Therefore, let's assume that all internal services (orchestrators and metadata storage) work on regular virtual machines created by the virtualization system that they are designed to manage.
Thus, our scheme now is slightly complicated: