Module 2 → Lesson 9 → Part 7 of 8
Клиент, сервер, дата-центр и «облако»
Lesson contents
What you'll learn
Мы дошли до сервера. А что это вообще такое?
В предыдущих частях пакет прошел довольно длинный путь: устройство Emma → локальная сеть → роутер → провайдер → другие сети → дата-центр → сервер.
Но слово «сервер» мы до сих пор использовали почти как конечную точку маршрута.
Теперь разберемся, что именно там находится.
Клиент и сервер — это прежде всего роли
Представим, что Emma открывает приложение криптобиржи.
Приложение отправляет запрос:
«Покажи мой баланс».
Удаленная система отвечает:
«Вот данные».
В этой ситуации приложение Emma выступает клиентом, а система, которая предоставляет данные, — сервером.
Упрощенно: клиент отправляет запрос серверу, а сервер возвращает клиенту ответ.
Сервер — не обязательно огромный компьютер
Когда мы слышим «сервер», легко представить большую черную металлическую коробку с множеством мигающих лампочек.
Такое оборудование действительно существует.
Но технически сервер — это прежде всего роль.
Например, обычный ноутбук может запустить программу, которая принимает сетевые соединения.
В этот момент он выполняет серверную функцию.
Один компьютер может выполнять несколько ролей
На одной системе одновременно могут работать: web server, database, API, monitoring, file service.
А иногда наоборот: один большой сервис распределен между сотнями или тысячами компьютеров.
Поэтому:
сервис ≠ обязательно один сервер
и:
сервер ≠ обязательно отдельный физический компьютер только для одной задачи.
Что тогда такое физический сервер
У него есть вполне обычные физические компоненты: процессор; оперативная память; накопители; сетевые интерфейсы; питание.
Просто обычно такие системы рассчитаны на: длительную работу; высокую нагрузку; удаленное управление; резервирование; размещение в специализированной инфраструктуре.
Где стоят серверы
Очень часто — в дата-центрах.
Внутри можно увидеть: стойки, серверы, коммутаторы, маршрутизаторы, системы хранения.
Но дата-центр — это не только комната с компьютерами.
Серверу недостаточно просто поставить розетку
Для надежной работы нужны: электропитание; резервное питание; охлаждение; сетевые подключения; физическая защита; мониторинг; системы пожарной безопасности.
Потому что сервер, который великолепно настроен, но перегрелся или остался без электричества, довольно быстро перестает производить впечатление надежной цифровой инфраструктуры.
Почему серверов обычно несколько
Представим сервис, которым пользуются миллионы людей.
Если вся система работает на одном сервере, его отказ может остановить весь сервис.
Поэтому реальные системы часто используют балансировщик нагрузки, который распределяет запросы между несколькими серверами.
Что такое load balancer
Он помогает: распределять нагрузку; выводить из работы неисправные серверы; добавлять новые серверы при росте нагрузки.
Но важно:
много серверов еще не означает децентрализацию.
Все они могут принадлежать одной компании и управляться из одного административного центра.
От одного физического сервера к виртуальным машинам
Когда-то было естественно использовать модель: 1 физический сервер = 1 операционная система = 1 основная задача.
Но ресурсы такого компьютера могли использоваться неэффективно.
Поэтому широко применяется виртуализация.
Например, на одном физическом сервере могут работать одновременно виртуальные машины A, B и C.
Каждая виртуальная машина может вести себя почти как отдельный компьютер.
Что такое виртуальная машина
Например, на одном физическом сервере могут работать: VM 1 с Linux, VM 2 с Linux, VM 3 с Windows.
Для пользователя они могут выглядеть как три совершенно отдельных сервера.
Хотя физически находятся на одном оборудовании.
Значит, IP-адрес не показывает нам физический компьютер?
Не обязательно.
Удаленный пользователь видит сетевой сервис.
А за ним могут находиться: одна физическая машина; виртуальная машина; группа серверов; балансировщик; целый кластер.
То есть один сетевой адрес совсем не обязательно означает одну физическую коробку.
А контейнеры?
В современной инфраструктуре часто используются еще и контейнеры.
Очень упрощенно: на сервере или виртуальной машине могут работать контейнеры A, B и C.
Контейнер обычно легче полноценной виртуальной машины.
VM и контейнер — не одно и то же
Упрощенно: Virtual Machine имеет собственную гостевую операционную систему.
Container обычно разделяет ядро операционной системы хоста, но изолирует приложение и его окружение.
Для начального курса этого достаточно.
Мы сейчас не собираемся превращать Emma в администратора Kubernetes.
И вот теперь появляется «облако»
Пользователь нажимает «Create Server» и через минуту получает: 4 CPU, 8 GB RAM, 100 GB storage, Public IP.
Он не видел: физический сервер; стойку; кабель; помещение; систему питания.
Для него вычислительные ресурсы предоставлены как сервис.
Это одна из основных идей cloud computing.
Например, можно получить: виртуальный сервер; базу данных; файловое хранилище; сетевой балансировщик; резервное копирование.
Не покупая для каждой задачи собственное физическое оборудование.
Но облако все равно физическое
Фраза «данные хранятся в облаке» не означает, что они перестали существовать на физических носителях.
Где-то все равно есть путь: дата-центр → физическое оборудование → накопители и серверы → виртуальные ресурсы → приложение.
«Облако» скрывает значительную часть инфраструктурной сложности от пользователя.
Но железо никуда не исчезает.
«Облако — это просто чужой компьютер»?
Эта фраза иногда используется как шутка.
В ней есть часть истины: оборудование действительно принадлежит кому-то.
Но современное облако обычно намного сложнее одного чужого компьютера.
Это могут быть: тысячи серверов; автоматическое распределение ресурсов; сетевые сервисы; базы данных; системы резервирования; несколько дата-центров.
Поэтому точнее:
облако — это модель предоставления управляемой вычислительной инфраструктуры как сервиса.
Region — регион облака
Крупные облачные платформы обычно размещают инфраструктуру в разных географических районах.
Можно встретить понятие region.
Например: Europe region, US region, Asia region.
Выбор региона может влиять на: задержку; отказоустойчивость; стоимость; требования к размещению данных.
Availability Zone
Внутри региона инфраструктура также может быть разделена на отдельные зоны.
Концептуально: регион состоит из зон A, B и C.
Приложение можно распределить между несколькими зонами.
- 1Data center — физическая площадка с оборудованием.
- 2Physical server — реальный компьютер с процессором, памятью и накопителями.
- 3Virtualization — разделение ресурсов физического сервера на изолированные среды.
- 4VM — виртуальная машина со своей операционной системой поверх физического оборудования.
- 5Containers / Applications — изолированные среды запуска приложений внутри VM или сервера.
- 6Cloud service — вычислительные ресурсы, предоставленные пользователю как управляемый сервис.
- 7User — видит только конечный сервис, не видит физическую инфраструктуру за ним. Это концептуальный пример: реальная cloud-архитектура может отличаться.
Но несколько зон не делают приложение бессмертным
Можно разместить серверы в Zone A и Zone B и все равно потерять сервис из-за: ошибки приложения; неверной настройки; проблем с базой данных; удаления данных; компрометации аккаунта администратора.
Отказоустойчивость — это архитектура целиком.
Не просто галочка:
«У нас cloud».
Что такое отказоустойчивость
Например: Server A отказал, а Server B и Server C продолжают работать.
Если пользователи продолжают работать, архитектура выдержала отказ Server A.
Но резервирование тоже бывает разным
Наличие трех серверов не очень помогает, если все они: находятся в одном здании; зависят от одного питания; подключены через один критический канал; используют одну поврежденную базу данных.
Поэтому при проектировании важно спрашивать:
Какие зависимости все еще являются общими?
Это знакомая нам единая точка отказа
В предыдущем модуле мы уже встречали идею Single Point of Failure, SPOF.
Если один компонент способен остановить всю систему, он является критической зависимостью.
Например, веб-серверов может быть три, но если единственная база данных недоступна, сервис все равно может остановиться.
- 1Load balancer распределяет запросы пользователей между Server A, Server B и Server C — все три работают.
- 2Server B становится недоступен — запросы продолжают идти к Server A и Server C, сервис остается доступным.
- 3Но все три сервера обращаются к одной и той же базе данных.
- 4Если эта единственная база данных становится недоступна, сервис все равно может остановиться — резервирование серверов не устранило эту общую точку отказа.
Много серверов ≠ децентрализация
Это особенно важно перед криптовалютами.
Представим сервис: 1000 servers, 50 data centers, 20 countries.
Но все они принадлежат одной организации, которая: задает правила; контролирует данные; может изменить систему; управляет доступом.
Технически инфраструктура очень распределенная.
Организационно она может оставаться:
централизованной.
И наоборот
Bitcoin-сеть состоит из множества независимых узлов.
Но конкретный пользователь может обращаться к ней через один сервис: Wallet → one RPC provider → Blockchain network.
Тогда базовая сеть распределенная.
А путь конкретного пользователя содержит централизованную зависимость.
Мы уже встречали этот принцип:
нужно анализировать всю архитектуру, а не одну характеристику.
- 1Centralized service — компания с тысячей серверов в нескольких дата-центрах: инфраструктура распределена, управление централизовано.
- 2Distributed network — независимые узлы A, B и C без единого администратора.
- 3Путь конкретного пользователя — Wallet → один RPC provider → Distributed network.
- 4Главный вывод — даже распределенная базовая сеть может использоваться через централизованную точку доступа. Это важный мост к последующим криптовалютным урокам.
Что может находиться за сайтом криптобиржи
Emma открывает сайт.
Она видит exchange interface.
За ним может находиться гораздо более сложная система: web frontend → API → authentication service → trading system → database → wallet infrastructure.
И каждый компонент может работать: на отдельном сервере; в виртуальной машине; в контейнере; в нескольких дата-центрах.
Пользователь всего этого обычно не видит.
Поэтому «сайт работает» еще не означает «работает вся система»
Может открываться главная страница, но не работать API.
Может работать API, но быть недоступной база данных.
Может работать интерфейс, но временно остановиться вывод средств.
Современный интернет-сервис обычно состоит из множества компонентов.
А где здесь безопасность?
Облачная инфраструктура не отменяет обычных рисков.
Нужно защищать: административные аккаунты; сетевые правила; серверы; приложения; данные; резервные копии; ключи доступа.
Кроме того, часть инфраструктуры теперь управляется облачным провайдером.
Модель разделенной ответственности
Очень упрощенно: провайдер может отвечать за физический дата-центр, оборудование и часть базовой облачной инфраструктуры.
Клиент по-прежнему может отвечать за: свои аккаунты; настройки доступа; приложения; данные; сетевые правила.
«Это облако, значит безопасность настроит провайдер» — плохая стратегия
Например, пользователь создал облачный сервер.
На нем запустил базу данных.
И разрешил доступ от 0.0.0.0/0 к database port.
Облачный провайдер может прекрасно защищать свое физическое оборудование.
Но правило доступа создал сам пользователь.
То есть:
безопасное облако не исправляет автоматически небезопасную конфигурацию клиента.
Кто тогда является клиентом?
Интересно, что роли могут меняться.
Emma использует приложение: Emma app → Exchange API.
Здесь приложение Emma — клиент.
Но сама криптобиржа может обращаться: Exchange → Cloud database.
Здесь уже система биржи выступает клиентом другого сервиса.
Поэтому:
client и server — это роли в конкретном взаимодействии, а не постоянные титулы компьютеров.
Главное, что нужно запомнить
- Клиент запрашивает сетевую функцию или данные, сервер их предоставляет.
- «Клиент» и «сервер» — прежде всего роли в конкретном взаимодействии.
- Сервером может быть как физический компьютер, так и программа в виртуальной среде.
- Один физический сервер способен обслуживать несколько виртуальных систем.
- Дата-центр предоставляет физическую инфраструктуру для серверного и сетевого оборудования.
- Виртуальная машина ведет себя как отдельная вычислительная система поверх физического оборудования.
- Контейнер изолирует приложение и его окружение, обычно без отдельной полноценной гостевой ОС.
- Облачные вычисления предоставляют инфраструктурные и программные ресурсы как удаленно управляемые сервисы.
- Облако не отменяет физические серверы — оно скрывает значительную часть инфраструктуры от пользователя.
- Region и Availability Zone помогают распределять ресурсы географически и инфраструктурно.
- Наличие нескольких серверов или дата-центров не означает автоматическую отказоустойчивость.
- Много серверов не означает децентрализацию: организационный контроль и техническое распределение — разные характеристики.
- Распределенная blockchain-сеть тоже может использоваться через централизованный сервис.
- В облаке безопасность обычно является разделенной ответственностью провайдера и клиента.
Что дальше
Теперь мы знаем, из каких основных частей складывается Интернет: локальная сеть; адреса; пакеты; маршрутизаторы; TCP и UDP; порты; клиенты; серверы; дата-центры; облако.
Осталось собрать все это в одну картину.
Что происходит между моментом:
Emma нажала кнопку
и моментом:
данные появились на другом компьютере?
А заодно проверим несколько популярных заблуждений:
Интернет и Web — одно и то же?
Wi-Fi означает, что Интернет работает?
Cloud означает отсутствие физических серверов?
VPN делает пользователя невидимым?
Продолжаем — в финальной части Урока 9 — «Итоги: как данные путешествуют по Интернету».
- Клиент запрашивает сетевую функцию или данные, сервер их предоставляет.
- «Клиент» и «сервер» — прежде всего роли в конкретном взаимодействии.
- Сервером может быть как физический компьютер, так и программа в виртуальной среде.
- Один физический сервер способен обслуживать несколько виртуальных систем.
- Дата-центр предоставляет физическую инфраструктуру для серверного и сетевого оборудования.
- Виртуальная машина ведет себя как отдельная вычислительная система поверх физического оборудования.
- Контейнер изолирует приложение и его окружение, обычно без отдельной полноценной гостевой ОС.
- Облачные вычисления предоставляют инфраструктурные и программные ресурсы как удаленно управляемые сервисы.
- Облако не отменяет физические серверы — оно скрывает значительную часть инфраструктуры от пользователя.
- Region и Availability Zone помогают распределять ресурсы географически и инфраструктурно.
- Наличие нескольких серверов или дата-центров не означает автоматическую отказоустойчивость.
- Много серверов не означает децентрализацию: организационный контроль и техническое распределение — разные характеристики.
- Распределенная blockchain-сеть тоже может использоваться через централизованный сервис.
- В облаке безопасность обычно является разделенной ответственностью провайдера и клиента.
We've reached the server. But what actually is it?
In the previous parts, the packet traveled a fairly long path: Emma's device → local network → router → provider → other networks → data center → server.
But we've used the word "server" so far almost as just the endpoint of the route.
Now let's figure out what's actually there.
Client and server are, first of all, roles
Let's imagine Emma opens a crypto exchange app.
The app sends a request:
"Show my balance."
The remote system responds:
"Here's the data."
In this situation, Emma's app acts as the client, and the system that provides the data acts as the server.
Simplified: the client sends a request to the server, and the server returns a response to the client.
A server is not necessarily a huge computer
When we hear "server," it's easy to picture a large black metal box with lots of blinking lights.
Such hardware really does exist.
But technically, a server is first of all a role.
For example, an ordinary laptop can run a program that accepts network connections.
At that moment, it is performing a server function.
One computer can perform several roles
On a single system, the following can run at the same time: web server, database, API, monitoring, file service.
And sometimes the opposite happens: one large service is distributed across hundreds or thousands of computers.
Therefore:
a service ≠ necessarily one server
and:
a server ≠ necessarily a separate physical computer for just one task.
So what is a physical server
It has fairly ordinary physical components: a processor; RAM; storage drives; network interfaces; power supply.
It's just that such systems are usually designed for: long-term operation; high load; remote management; redundancy; placement in specialized infrastructure.
Where servers are located
Very often — in data centers.
Inside, you can see: racks, servers, switches, routers, storage systems.
But a data center is not just a room with computers.
It's not enough to just give a server a power outlet
For reliable operation, you need: electrical power; backup power; cooling; network connections; physical security; monitoring; fire safety systems.
Because a server that is beautifully configured but overheats or loses power fairly quickly stops making an impression of reliable digital infrastructure.
Why there are usually several servers
Let's imagine a service used by millions of people.
If the entire system runs on one server, its failure can stop the whole service.
That's why real systems often use a load balancer, which distributes requests among several servers.
What a load balancer is
It helps: distribute load; take faulty servers out of operation; add new servers as load grows.
But it's important that:
many servers still doesn't mean decentralization.
They can all belong to one company and be managed from a single administrative center.
From one physical server to virtual machines
There was once a natural model: 1 physical server = 1 operating system = 1 primary task.
But such a computer's resources could be used inefficiently.
That's why virtualization is widely used.
For example, virtual machines A, B, and C can run simultaneously on one physical server.
Each virtual machine can behave almost like a separate computer.
What a virtual machine is
For example, the following can run on one physical server: VM 1 with Linux, VM 2 with Linux, VM 3 with Windows.
To the user, they may look like three completely separate servers.
Even though they are physically located on the same hardware.
So does an IP address not show us the physical computer?
Not necessarily.
A remote user sees a network service.
And behind it may be: a single physical machine; a virtual machine; a group of servers; a load balancer; an entire cluster.
That is, one network address does not necessarily mean one physical box at all.
What about containers?
Modern infrastructure also often uses containers.
Very simplified: containers A, B, and C can run on a server or virtual machine.
A container is usually lighter than a full virtual machine.
A VM and a container are not the same thing
Simplified: a Virtual Machine has its own guest operating system.
A Container usually shares the host operating system's kernel, but isolates the application and its environment.
For an introductory course, that's enough.
We're not about to turn Emma into a Kubernetes administrator.
And now "the cloud" appears
A user clicks "Create Server" and a minute later gets: 4 CPU, 8 GB RAM, 100 GB storage, Public IP.
He didn't see: the physical server; the rack; the cable; the room; the power system.
For him, computing resources were provided as a service.
This is one of the core ideas of cloud computing.
For example, you can get: a virtual server; a database; file storage; a network load balancer; backup.
Without buying dedicated physical hardware for each task.
But the cloud is still physical
The phrase "data is stored in the cloud" doesn't mean it has stopped existing on physical media.
Somewhere, there is still a path: data center → physical hardware → drives and servers → virtual resources → application.
"The cloud" hides a significant part of infrastructure complexity from the user.
But the hardware doesn't disappear anywhere.
"The cloud is just someone else's computer"?
This phrase is sometimes used as a joke.
There's a grain of truth in it: the hardware really does belong to someone.
But a modern cloud is usually far more complex than one other person's computer.
It can consist of: thousands of servers; automatic resource allocation; network services; databases; redundancy systems; multiple data centers.
So more precisely:
the cloud is a model for delivering managed computing infrastructure as a service.
Region — the cloud region
Large cloud platforms usually place their infrastructure in different geographic areas.
You may come across the concept of a region.
For example: Europe region, US region, Asia region.
Choice of region can affect: latency; fault tolerance; cost; data residency requirements.
Availability Zone
Within a region, infrastructure can also be divided into separate zones.
Conceptually: a region consists of zones A, B, and C.
An application can be distributed across several zones.
- 1Data center — a physical site with equipment.
- 2Physical server — a real computer with a processor, memory, and storage drives.
- 3Virtualization — dividing a physical server's resources into isolated environments.
- 4VM — a virtual machine with its own operating system on top of physical hardware.
- 5Containers / Applications — isolated application runtime environments inside a VM or server.
- 6Cloud service — computing resources delivered to the user as a managed service.
- 7User — sees only the end service, not the physical infrastructure behind it. This is a conceptual example: real cloud architecture may differ.
But several zones don't make an application immortal
You can place servers in Zone A and Zone B and still lose the service due to: an application error; incorrect configuration; database problems; data deletion; compromise of an administrator account.
Fault tolerance is the whole architecture.
Not just a checkbox that says:
"We have cloud."
What fault tolerance is
For example: Server A failed, while Server B and Server C keep working.
If users can keep working, the architecture withstood the failure of Server A.
But redundancy also comes in different kinds
Having three servers doesn't help much if all of them: are located in the same building; depend on the same power supply; are connected through the same critical channel; use the same corrupted database.
That's why, when designing, it's important to ask:
What dependencies are still shared?
This is the single point of failure we already know
In the previous module, we already encountered the idea of Single Point of Failure, SPOF.
If one component is able to stop the entire system, it is a critical dependency.
For example, there may be three web servers, but if the single database is unavailable, the service can still stop.
- 1The load balancer distributes user requests among Server A, Server B, and Server C — all three are working.
- 2Server B becomes unavailable — requests keep going to Server A and Server C, the service remains available.
- 3But all three servers access the same single database.
- 4If that single database becomes unavailable, the service can still stop — server redundancy did not eliminate this shared point of failure.
Many servers ≠ decentralization
This is especially important ahead of cryptocurrencies.
Let's imagine a service: 1000 servers, 50 data centers, 20 countries.
But they all belong to one organization, which: sets the rules; controls the data; can change the system; manages access.
Technically, the infrastructure is very distributed.
Organizationally, it can remain:
centralized.
And the other way around
The Bitcoin network consists of many independent nodes.
But a specific user may access it through one service: Wallet → one RPC provider → Blockchain network.
Then the underlying network is distributed.
But the specific user's path contains a centralized dependency.
We've already encountered this principle:
you need to analyze the entire architecture, not one characteristic.
- 1Centralized service — a company with a thousand servers across several data centers: infrastructure is distributed, management is centralized.
- 2Distributed network — independent nodes A, B, and C with no single administrator.
- 3A specific user's path — Wallet → one RPC provider → Distributed network.
- 4The main takeaway — even a distributed underlying network can be accessed through a centralized access point. This is an important bridge to the upcoming cryptocurrency lessons.
What might be behind a crypto exchange's website
Emma opens the website.
She sees the exchange interface.
Behind it there may be a much more complex system: web frontend → API → authentication service → trading system → database → wallet infrastructure.
And each component can run: on a separate server; in a virtual machine; in a container; across several data centers.
The user usually doesn't see any of this.
So "the site works" doesn't yet mean "the whole system works"
The homepage may load, but the API may not work.
The API may work, but the database may be unavailable.
The interface may work, but withdrawals may be temporarily stopped.
A modern internet service usually consists of many components.
So where does security come in here?
Cloud infrastructure doesn't eliminate the usual risks.
You need to protect: administrative accounts; network rules; servers; applications; data; backups; access keys.
In addition, part of the infrastructure is now managed by the cloud provider.
The shared responsibility model
Very simplified: the provider may be responsible for the physical data center, the hardware, and part of the underlying cloud infrastructure.
The customer may still be responsible for: their accounts; access settings; applications; data; network rules.
"It's the cloud, so the provider will handle security" — a bad strategy
For example, a user created a cloud server.
On it, they ran a database.
And allowed access from 0.0.0.0/0 to the database port.
The cloud provider may protect its physical hardware perfectly well.
But the user created the access rule themselves.
That is:
a secure cloud does not automatically fix an insecure client configuration.
So who is the client, then?
Interestingly, roles can change.
Emma uses an app: Emma app → Exchange API.
Here, Emma's app is the client.
But the exchange itself may make a call: Exchange → Cloud database.
Here, the exchange's system acts as the client of another service.
Therefore:
client and server are roles in a specific interaction, not permanent titles for computers.
The main thing to remember
- The client requests a network function or data, the server provides it.
- "Client" and "server" are, first of all, roles in a specific interaction.
- A server can be either a physical computer or a program in a virtual environment.
- One physical server is able to serve several virtual systems.
- A data center provides the physical infrastructure for server and network equipment.
- A virtual machine behaves like a separate computing system on top of physical hardware.
- A container isolates an application and its environment, usually without a separate full guest OS.
- Cloud computing delivers infrastructure and software resources as remotely managed services.
- The cloud doesn't eliminate physical servers — it hides a significant part of the infrastructure from the user.
- Region and Availability Zone help distribute resources geographically and infrastructurally.
- Having several servers or data centers doesn't automatically mean fault tolerance.
- Many servers don't mean decentralization: organizational control and technical distribution are different characteristics.
- A distributed blockchain network can also be accessed through a centralized service.
- In the cloud, security is usually a shared responsibility of the provider and the customer.
What's next
Now we know the main parts the Internet is made of: local network; addresses; packets; routers; TCP and UDP; ports; clients; servers; data centers; cloud.
All that's left is to put it all together into one picture.
What happens between the moment:
Emma clicked the button
and the moment:
the data appeared on another computer?
And along the way, let's check a few popular misconceptions:
Are the Internet and the Web the same thing?
Does Wi-Fi mean the Internet is working?
Does cloud mean there are no physical servers?
Does a VPN make a user invisible?
Let's continue — in the final part of Lesson 9 — "Summary: how data travels across the Internet."
- A client requests a network function or data, a server provides it.
- "Client" and "server" are, above all, roles in a specific interaction.
- A server can be either a physical computer or a program running in a virtual environment.
- One physical server can serve several virtual systems.
- A data center provides the physical infrastructure for server and network equipment.
- A virtual machine behaves like a separate computing system on top of physical hardware.
- A container isolates an application and its environment, usually without its own full guest OS.
- Cloud computing delivers infrastructure and software resources as remotely managed services.
- The cloud doesn't eliminate physical servers — it hides a significant part of the infrastructure from the user.
- A region and an Availability Zone help distribute resources geographically and infrastructurally.
- Having several servers or data centers doesn't automatically mean fault tolerance.
- Many servers don't mean decentralization: organizational control and technical distribution are different characteristics.
- A distributed blockchain network can still be accessed through a centralized service.
- In the cloud, security is usually a responsibility shared between the provider and the client.
Φτάσαμε στον server. Τι είναι όμως αυτό ακριβώς;
Στα προηγούμενα μέρη το πακέτο διένυσε μια αρκετά μεγάλη διαδρομή: η συσκευή της Emma → τοπικό δίκτυο → router → πάροχος → άλλα δίκτυα → data center → server.
Όμως τη λέξη «server» τη χρησιμοποιούσαμε μέχρι τώρα σχεδόν σαν τελικό σημείο της διαδρομής.
Τώρα ας δούμε τι ακριβώς βρίσκεται εκεί.
Client και server είναι πρωτίστως ρόλοι
Ας φανταστούμε ότι η Emma ανοίγει την εφαρμογή ενός κρυπτοχρηματιστηρίου.
Η εφαρμογή στέλνει ένα αίτημα:
«Δείξε μου το υπόλοιπό μου».
Το απομακρυσμένο σύστημα απαντά:
«Ορίστε τα δεδομένα».
Σε αυτή την περίπτωση η εφαρμογή της Emma λειτουργεί ως client, ενώ το σύστημα που παρέχει τα δεδομένα — ως server.
Απλοποιημένα: ο client στέλνει αίτημα στον server, και ο server επιστρέφει στον client απάντηση.
Ο server δεν είναι απαραίτητα ένας τεράστιος υπολογιστής
Όταν ακούμε «server», είναι εύκολο να φανταστούμε ένα μεγάλο μαύρο μεταλλικό κουτί με πολλά αναβοσβήνοντα φωτάκια.
Τέτοιος εξοπλισμός πράγματι υπάρχει.
Όμως τεχνικά ο server είναι πρωτίστως ένας ρόλος.
Για παράδειγμα, ένα συνηθισμένο laptop μπορεί να τρέξει ένα πρόγραμμα που δέχεται συνδέσεις δικτύου.
Εκείνη τη στιγμή εκτελεί λειτουργία server.
Ένας υπολογιστής μπορεί να εκτελεί πολλούς ρόλους
Σε ένα σύστημα μπορούν να λειτουργούν ταυτόχρονα: web server, database, API, monitoring, file service.
Και μερικές φορές αντίστροφα: μία μεγάλη υπηρεσία είναι κατανεμημένη σε εκατοντάδες ή χιλιάδες υπολογιστές.
Γι' αυτό:
υπηρεσία ≠ απαραίτητα ένας server
και:
server ≠ απαραίτητα ξεχωριστός φυσικός υπολογιστής μόνο για ένα καθήκον.
Τι είναι λοιπόν ο φυσικός server
Διαθέτει εντελώς συνηθισμένα φυσικά στοιχεία: επεξεργαστή· μνήμη RAM· αποθηκευτικά μέσα· διεπαφές δικτύου· τροφοδοσία.
Απλώς συνήθως τέτοια συστήματα είναι σχεδιασμένα για: μακροχρόνια λειτουργία· υψηλό φορτίο· απομακρυσμένη διαχείριση· εφεδρικότητα· τοποθέτηση σε εξειδικευμένη υποδομή.
Πού βρίσκονται οι servers
Πολύ συχνά — σε data centers.
Στο εσωτερικό μπορεί κανείς να δει: ραφιέρες, servers, switches, routers, συστήματα αποθήκευσης.
Όμως το data center δεν είναι απλώς ένα δωμάτιο με υπολογιστές.
Δεν αρκεί απλώς να βάλουμε μια πρίζα στον server
Για αξιόπιστη λειτουργία χρειάζονται: ηλεκτρική τροφοδοσία· εφεδρική τροφοδοσία· ψύξη· συνδέσεις δικτύου· φυσική προστασία· παρακολούθηση (monitoring)· συστήματα πυρασφάλειας.
Επειδή ένας server που είναι εξαιρετικά ρυθμισμένος αλλά υπερθερμάνθηκε ή έμεινε χωρίς ρεύμα, αρκετά γρήγορα παύει να δίνει την εντύπωση αξιόπιστης ψηφιακής υποδομής.
Γιατί συνήθως υπάρχουν πολλοί servers
Ας φανταστούμε μια υπηρεσία που χρησιμοποιούν εκατομμύρια άνθρωποι.
Αν ολόκληρο το σύστημα λειτουργεί σε έναν server, η βλάβη του μπορεί να σταματήσει ολόκληρη την υπηρεσία.
Γι' αυτό τα πραγματικά συστήματα συχνά χρησιμοποιούν έναν balancer φορτίου, ο οποίος κατανέμει τα αιτήματα ανάμεσα σε πολλούς servers.
Τι είναι ο load balancer
Βοηθά να: κατανέμεται το φορτίο· αποσύρονται από τη λειτουργία οι χαλασμένοι servers· προστίθενται νέοι servers όταν αυξάνεται το φορτίο.
Όμως είναι σημαντικό:
πολλοί servers δεν σημαίνουν ακόμα αποκέντρωση.
Όλοι τους μπορεί να ανήκουν σε μία εταιρεία και να διαχειρίζονται από ένα ενιαίο διοικητικό κέντρο.
Από έναν φυσικό server στις εικονικές μηχανές
Κάποτε ήταν φυσικό να χρησιμοποιείται το μοντέλο: 1 φυσικός server = 1 λειτουργικό σύστημα = 1 κύριο καθήκον.
Όμως οι πόροι ενός τέτοιου υπολογιστή μπορεί να χρησιμοποιούνταν αναποτελεσματικά.
Γι' αυτό εφαρμόζεται ευρέως η virtualization.
Για παράδειγμα, σε έναν φυσικό server μπορούν να λειτουργούν ταυτόχρονα οι εικονικές μηχανές A, B και C.
Κάθε εικονική μηχανή μπορεί να συμπεριφέρεται σχεδόν σαν ξεχωριστός υπολογιστής.
Τι είναι η εικονική μηχανή
Για παράδειγμα, σε έναν φυσικό server μπορούν να λειτουργούν: VM 1 με Linux, VM 2 με Linux, VM 3 με Windows.
Για τον χρήστη μπορεί να φαίνονται σαν τρεις εντελώς ξεχωριστοί servers.
Παρόλο που φυσικά βρίσκονται στον ίδιο εξοπλισμό.
Άρα η διεύθυνση IP δεν μας δείχνει τον φυσικό υπολογιστή;
Όχι απαραίτητα.
Ο απομακρυσμένος χρήστης βλέπει μια υπηρεσία δικτύου.
Και πίσω της μπορεί να βρίσκεται: ένα φυσικό μηχάνημα· μια εικονική μηχανή· μια ομάδα servers· ένας balancer· ολόκληρο ένα cluster.
Δηλαδή μια διεύθυνση δικτύου δεν σημαίνει καθόλου απαραίτητα ένα φυσικό κουτί.
Και τα containers;
Στη σύγχρονη υποδομή χρησιμοποιούνται συχνά και τα containers.
Πολύ απλοποιημένα: σε έναν server ή σε μια εικονική μηχανή μπορούν να λειτουργούν containers A, B και C.
Το container είναι συνήθως πιο ελαφρύ από μια πλήρη εικονική μηχανή.
VM και container δεν είναι το ίδιο πράγμα
Απλοποιημένα: το Virtual Machine έχει το δικό του guest λειτουργικό σύστημα.
Το Container συνήθως μοιράζεται τον πυρήνα του λειτουργικού συστήματος του host, αλλά απομονώνει την εφαρμογή και το περιβάλλον της.
Για ένα εισαγωγικό μάθημα αυτό είναι αρκετό.
Δεν πρόκειται τώρα να μετατρέψουμε την Emma σε διαχειρίστρια Kubernetes.
Και εδώ εμφανίζεται το «σύννεφο»
Ο χρήστης πατά «Create Server» και σε ένα λεπτό αποκτά: 4 CPU, 8 GB RAM, 100 GB storage, Public IP.
Δεν είδε: τον φυσικό server· τη ραφιέρα· το καλώδιο· τον χώρο· το σύστημα τροφοδοσίας.
Για αυτόν οι υπολογιστικοί πόροι παρέχονται ως υπηρεσία.
Αυτή είναι μία από τις βασικές ιδέες του cloud computing.
Για παράδειγμα, μπορεί κανείς να αποκτήσει: εικονικό server· βάση δεδομένων· χώρο αποθήκευσης αρχείων· balancer δικτύου· εφεδρικά αντίγραφα.
Χωρίς να αγοράζει για κάθε καθήκον δικό του φυσικό εξοπλισμό.
Όμως το cloud παραμένει φυσικό
Η φράση «τα δεδομένα αποθηκεύονται στο cloud» δεν σημαίνει ότι έπαψαν να υπάρχουν σε φυσικά μέσα.
Κάπου υπάρχει πάντα η διαδρομή: data center → φυσικός εξοπλισμός → αποθηκευτικά μέσα και servers → εικονικοί πόροι → εφαρμογή.
Το «cloud» κρύβει σημαντικό μέρος της πολυπλοκότητας της υποδομής από τον χρήστη.
Όμως το hardware δεν εξαφανίζεται πουθενά.
«Το cloud είναι απλώς ο υπολογιστής κάποιου άλλου»;
Αυτή η φράση χρησιμοποιείται μερικές φορές ως αστείο.
Έχει ένα κομμάτι αλήθειας: ο εξοπλισμός πράγματι ανήκει σε κάποιον.
Όμως το σύγχρονο cloud είναι συνήθως πολύ πιο περίπλοκο από έναν ξένο υπολογιστή.
Μπορεί να πρόκειται για: χιλιάδες servers· αυτόματη κατανομή πόρων· υπηρεσίες δικτύου· βάσεις δεδομένων· συστήματα εφεδρικότητας· πολλαπλά data centers.
Γι' αυτό πιο ακριβές είναι:
το cloud είναι ένα μοντέλο παροχής διαχειριζόμενης υπολογιστικής υποδομής ως υπηρεσίας.
Region — η περιοχή του cloud
Οι μεγάλες πλατφόρμες cloud συνήθως τοποθετούν την υποδομή τους σε διαφορετικές γεωγραφικές περιοχές.
Μπορεί κανείς να συναντήσει την έννοια region.
Για παράδειγμα: Europe region, US region, Asia region.
Η επιλογή της περιοχής μπορεί να επηρεάσει: την καθυστέρηση (latency)· την ανθεκτικότητα σε βλάβες· το κόστος· τις απαιτήσεις τοποθέτησης δεδομένων.
Availability Zone
Μέσα σε μια περιοχή, η υποδομή μπορεί επίσης να χωρίζεται σε ξεχωριστές ζώνες.
Εννοιολογικά: η περιοχή αποτελείται από τις ζώνες A, B και C.
Η εφαρμογή μπορεί να κατανεμηθεί ανάμεσα σε πολλές ζώνες.
- 1Data center — φυσική εγκατάσταση με εξοπλισμό.
- 2Physical server — πραγματικός υπολογιστής με επεξεργαστή, μνήμη και αποθηκευτικά μέσα.
- 3Virtualization — διαμοιρασμός των πόρων του φυσικού server σε απομονωμένα περιβάλλοντα.
- 4VM — εικονική μηχανή με το δικό της λειτουργικό σύστημα πάνω από τον φυσικό εξοπλισμό.
- 5Containers / Applications — απομονωμένα περιβάλλοντα εκτέλεσης εφαρμογών μέσα σε VM ή server.
- 6Cloud service — υπολογιστικοί πόροι που παρέχονται στον χρήστη ως διαχειριζόμενη υπηρεσία.
- 7User — βλέπει μόνο την τελική υπηρεσία, δεν βλέπει τη φυσική υποδομή πίσω της. Αυτό είναι ένα εννοιολογικό παράδειγμα: η πραγματική αρχιτεκτονική cloud μπορεί να διαφέρει.
Όμως λίγες ζώνες δεν κάνουν την εφαρμογή αθάνατη
Μπορεί κανείς να τοποθετήσει servers στη Zone A και στη Zone B και παρόλα αυτά να χάσει την υπηρεσία εξαιτίας: σφάλματος στην εφαρμογή· λανθασμένης ρύθμισης· προβλημάτων με τη βάση δεδομένων· διαγραφής δεδομένων· παραβίασης λογαριασμού διαχειριστή.
Η ανθεκτικότητα σε βλάβες είναι ολόκληρη η αρχιτεκτονική.
Όχι απλώς ένα τσεκάρισμα:
«Έχουμε cloud».
Τι είναι η ανθεκτικότητα σε βλάβες
Για παράδειγμα: ο Server A χάλασε, ενώ ο Server B και ο Server C συνεχίζουν να λειτουργούν.
Αν οι χρήστες συνεχίζουν να δουλεύουν, η αρχιτεκτονική άντεξε τη βλάβη του Server A.
Όμως και η εφεδρικότητα μπορεί να είναι διαφορετική
Η ύπαρξη τριών servers δεν βοηθάει και πολύ αν όλοι τους: βρίσκονται στο ίδιο κτίριο· εξαρτώνται από την ίδια τροφοδοσία· συνδέονται μέσω ενός μόνο κρίσιμου καναλιού· χρησιμοποιούν την ίδια κατεστραμμένη βάση δεδομένων.
Γι' αυτό κατά τον σχεδιασμό είναι σημαντικό να ρωτάμε:
Ποιες εξαρτήσεις παραμένουν κοινές;
Αυτό είναι το γνωστό μας ενιαίο σημείο αστοχίας
Στην προηγούμενη ενότητα είχαμε ήδη συναντήσει την ιδέα του Single Point of Failure, SPOF.
Αν ένα στοιχείο είναι ικανό να σταματήσει ολόκληρο το σύστημα, αποτελεί κρίσιμη εξάρτηση.
Για παράδειγμα, οι web servers μπορεί να είναι τρεις, αλλά αν η μοναδική βάση δεδομένων δεν είναι διαθέσιμη, η υπηρεσία μπορεί και πάλι να σταματήσει.
- 1Ο Load balancer κατανέμει τα αιτήματα των χρηστών ανάμεσα στον Server A, τον Server B και τον Server C — και οι τρεις λειτουργούν.
- 2Ο Server B γίνεται μη διαθέσιμος — τα αιτήματα συνεχίζουν να πηγαίνουν στον Server A και στον Server C, η υπηρεσία παραμένει διαθέσιμη.
- 3Όμως και οι τρεις servers απευθύνονται στην ίδια ακριβώς βάση δεδομένων.
- 4Αν αυτή η μοναδική βάση δεδομένων γίνει μη διαθέσιμη, η υπηρεσία μπορεί και πάλι να σταματήσει — η εφεδρικότητα των servers δεν εξάλειψε αυτό το κοινό σημείο αστοχίας.
Πολλοί servers ≠ αποκέντρωση
Αυτό είναι ιδιαίτερα σημαντικό πριν μιλήσουμε για κρυπτονομίσματα.
Ας φανταστούμε μια υπηρεσία: 1000 servers, 50 data centers, 20 countries.
Όμως όλοι τους ανήκουν σε έναν οργανισμό, ο οποίος: καθορίζει τους κανόνες· ελέγχει τα δεδομένα· μπορεί να αλλάξει το σύστημα· διαχειρίζεται την πρόσβαση.
Τεχνικά η υποδομή είναι πολύ κατανεμημένη.
Οργανωτικά μπορεί να παραμένει:
συγκεντρωτική.
Και αντίστροφα
Το δίκτυο Bitcoin αποτελείται από πολλούς ανεξάρτητους κόμβους.
Όμως ένας συγκεκριμένος χρήστης μπορεί να απευθύνεται σε αυτό μέσω μίας υπηρεσίας: Wallet → one RPC provider → Blockchain network.
Τότε το βασικό δίκτυο είναι κατανεμημένο.
Ενώ η διαδρομή ενός συγκεκριμένου χρήστη περιέχει μια συγκεντρωτική εξάρτηση.
Έχουμε ήδη συναντήσει αυτή την αρχή:
πρέπει να αναλύουμε ολόκληρη την αρχιτεκτονική, όχι ένα μόνο χαρακτηριστικό.
- 1Centralized service — εταιρεία με χίλιους servers σε πολλά data centers: η υποδομή είναι κατανεμημένη, η διαχείριση είναι συγκεντρωτική.
- 2Distributed network — ανεξάρτητοι κόμβοι A, B και C χωρίς ενιαίο διαχειριστή.
- 3Η διαδρομή ενός συγκεκριμένου χρήστη — Wallet → ένας RPC provider → Distributed network.
- 4Το κύριο συμπέρασμα — ακόμα και ένα κατανεμημένο βασικό δίκτυο μπορεί να χρησιμοποιείται μέσω ενός συγκεντρωτικού σημείου πρόσβασης. Αυτό είναι μια σημαντική γέφυρα προς τα επόμενα μαθήματα για τα κρυπτονομίσματα.
Τι μπορεί να βρίσκεται πίσω από τον ιστότοπο ενός κρυπτοχρηματιστηρίου
Η Emma ανοίγει τον ιστότοπο.
Βλέπει το exchange interface.
Πίσω του μπορεί να βρίσκεται ένα πολύ πιο περίπλοκο σύστημα: web frontend → API → authentication service → trading system → database → wallet infrastructure.
Και κάθε στοιχείο μπορεί να λειτουργεί: σε ξεχωριστό server· σε εικονική μηχανή· σε container· σε πολλά data centers.
Ο χρήστης συνήθως δεν βλέπει τίποτα από όλα αυτά.
Γι' αυτό «ο ιστότοπος λειτουργεί» δεν σημαίνει ακόμα «λειτουργεί ολόκληρο το σύστημα»
Μπορεί να ανοίγει η αρχική σελίδα, αλλά να μη λειτουργεί το API.
Μπορεί να λειτουργεί το API, αλλά να μην είναι διαθέσιμη η βάση δεδομένων.
Μπορεί να λειτουργεί η διεπαφή, αλλά προσωρινά να έχει σταματήσει η ανάληψη κεφαλαίων.
Μια σύγχρονη διαδικτυακή υπηρεσία συνήθως αποτελείται από πολλά στοιχεία.
Και πού είναι εδώ η ασφάλεια;
Η υποδομή cloud δεν καταργεί τους συνηθισμένους κινδύνους.
Χρειάζεται να προστατεύονται: οι λογαριασμοί διαχείρισης· οι κανόνες δικτύου· οι servers· οι εφαρμογές· τα δεδομένα· τα εφεδρικά αντίγραφα· τα κλειδιά πρόσβασης.
Επιπλέον, μέρος της υποδομής πλέον διαχειρίζεται ο πάροχος cloud.
Το μοντέλο διαμοιρασμένης ευθύνης
Πολύ απλοποιημένα: ο πάροχος μπορεί να είναι υπεύθυνος για το φυσικό data center, τον εξοπλισμό και μέρος της βασικής υποδομής cloud.
Ο πελάτης εξακολουθεί να είναι υπεύθυνος για: τους δικούς του λογαριασμούς· τις ρυθμίσεις πρόσβασης· τις εφαρμογές· τα δεδομένα· τους κανόνες δικτύου.
«Είναι cloud, άρα την ασφάλεια θα τη ρυθμίσει ο πάροχος» — κακή στρατηγική
Για παράδειγμα, ένας χρήστης δημιούργησε έναν server στο cloud.
Σε αυτόν έτρεξε μια βάση δεδομένων.
Και επέτρεψε πρόσβαση από 0.0.0.0/0 στο database port.
Ο πάροχος cloud μπορεί να προστατεύει άψογα τον δικό του φυσικό εξοπλισμό.
Όμως τον κανόνα πρόσβασης τον δημιούργησε ο ίδιος ο χρήστης.
Δηλαδή:
ένα ασφαλές cloud δεν διορθώνει αυτόματα μια μη ασφαλή διαμόρφωση του πελάτη.
Ποιος είναι λοιπόν ο client;
Το ενδιαφέρον είναι ότι οι ρόλοι μπορούν να αλλάζουν.
Η Emma χρησιμοποιεί την εφαρμογή: Emma app → Exchange API.
Εδώ η εφαρμογή της Emma είναι ο client.
Όμως το ίδιο το κρυπτοχρηματιστήριο μπορεί να απευθύνεται: Exchange → Cloud database.
Εδώ πλέον το σύστημα του χρηματιστηρίου λειτουργεί ως client μιας άλλης υπηρεσίας.
Γι' αυτό:
client και server είναι ρόλοι σε μια συγκεκριμένη αλληλεπίδραση, όχι μόνιμοι τίτλοι υπολογιστών.
Τι πρέπει κυρίως να θυμόμαστε
- Ο client ζητά μια λειτουργία δικτύου ή δεδομένα, ο server τα παρέχει.
- «Client» και «server» είναι πρωτίστως ρόλοι σε μια συγκεκριμένη αλληλεπίδραση.
- Server μπορεί να είναι τόσο ένας φυσικός υπολογιστής όσο και ένα πρόγραμμα σε εικονικό περιβάλλον.
- Ένας φυσικός server μπορεί να εξυπηρετεί πολλά εικονικά συστήματα.
- Το data center παρέχει τη φυσική υποδομή για τον εξοπλισμό servers και δικτύου.
- Η εικονική μηχανή συμπεριφέρεται σαν ξεχωριστό υπολογιστικό σύστημα πάνω από τον φυσικό εξοπλισμό.
- Το container απομονώνει την εφαρμογή και το περιβάλλον της, συνήθως χωρίς ξεχωριστό πλήρες guest λειτουργικό σύστημα.
- Το cloud computing παρέχει πόρους υποδομής και λογισμικού ως απομακρυσμένα διαχειριζόμενες υπηρεσίες.
- Το cloud δεν καταργεί τους φυσικούς servers — κρύβει σημαντικό μέρος της υποδομής από τον χρήστη.
- Το Region και το Availability Zone βοηθούν να κατανέμονται οι πόροι γεωγραφικά και υποδομικά.
- Η ύπαρξη πολλών servers ή data centers δεν σημαίνει αυτόματη ανθεκτικότητα σε βλάβες.
- Πολλοί servers δεν σημαίνουν αποκέντρωση: ο οργανωτικός έλεγχος και η τεχνική κατανομή είναι διαφορετικά χαρακτηριστικά.
- Ένα κατανεμημένο δίκτυο blockchain μπορεί επίσης να χρησιμοποιείται μέσω μιας συγκεντρωτικής υπηρεσίας.
- Στο cloud η ασφάλεια συνήθως είναι διαμοιρασμένη ευθύνη του παρόχου και του πελάτη.
Τι ακολουθεί
Τώρα γνωρίζουμε από ποια βασικά μέρη αποτελείται το Internet: τοπικό δίκτυο· διευθύνσεις· πακέτα· routers· TCP και UDP· θύρες· clients· servers· data centers· cloud.
Απομένει να τα συνδυάσουμε όλα σε μία εικόνα.
Τι συμβαίνει ανάμεσα στη στιγμή:
η Emma πάτησε το κουμπί
και τη στιγμή:
τα δεδομένα εμφανίστηκαν σε άλλον υπολογιστή;
Παράλληλα θα εξετάσουμε και μερικές δημοφιλείς παρανοήσεις:
Το Internet και ο Web είναι το ίδιο πράγμα;
Το Wi-Fi σημαίνει ότι λειτουργεί το Internet;
Το Cloud σημαίνει απουσία φυσικών servers;
Το VPN κάνει τον χρήστη αόρατο;
Συνεχίζουμε — στο τελικό μέρος του Μαθήματος 9 — «Ανακεφαλαίωση: πώς ταξιδεύουν τα δεδομένα στο Internet».
- Ο πελάτης ζητά μια δικτυακή λειτουργία ή δεδομένα, ο server τα παρέχει.
- «Πελάτης» και «server» είναι πρωτίστως ρόλοι σε μια συγκεκριμένη αλληλεπίδραση.
- Ένας server μπορεί να είναι είτε φυσικός υπολογιστής είτε πρόγραμμα σε εικονικό περιβάλλον.
- Ένας φυσικός server μπορεί να εξυπηρετεί πολλά εικονικά συστήματα.
- Το κέντρο δεδομένων παρέχει τη φυσική υποδομή για τον εξοπλισμό server και δικτύου.
- Μια εικονική μηχανή συμπεριφέρεται ως ξεχωριστό υπολογιστικό σύστημα πάνω από το φυσικό υλικό.
- Ένα container απομονώνει την εφαρμογή και το περιβάλλον της, συνήθως χωρίς δικό του πλήρες guest OS.
- Το cloud computing παρέχει πόρους υποδομής και λογισμικού ως απομακρυσμένα διαχειριζόμενες υπηρεσίες.
- Το cloud δεν καταργεί τους φυσικούς servers — κρύβει σημαντικό μέρος της υποδομής από τον χρήστη.
- Η περιοχή (region) και η ζώνη διαθεσιμότητας βοηθούν στην κατανομή πόρων γεωγραφικά και υποδομικά.
- Η ύπαρξη πολλών servers ή κέντρων δεδομένων δεν σημαίνει αυτόματα ανοχή σφαλμάτων.
- Πολλοί servers δεν σημαίνουν αποκέντρωση: ο οργανωτικός έλεγχος και η τεχνική κατανομή είναι διαφορετικά χαρακτηριστικά.
- Ένα κατανεμημένο δίκτυο blockchain μπορεί και πάλι να χρησιμοποιείται μέσω μιας κεντρικοποιημένης υπηρεσίας.
- Στο cloud, η ασφάλεια είναι συνήθως μια ευθύνη που μοιράζονται ο πάροχος και ο πελάτης.