Ребят, не сочтите за слоупока, просто недавно образовалась классическая проблема "босс прочитал новое слово в Тырнетах и теперь мы все дружно бежим его претворять в жизнь". Слово это Azure. Сам хайп я давно уже игнорирую как только впервые о нём прочитал, но сейчас пришлось ещё раз провозиться с кучей обзоров и даже конкретных уроков, что только подтверждает моё первичное мнение:
Azure — это СТЕНА из новоиспечённых API, разделяющая старые технологии от старых программистов. Разумеется, в стене есть дыры (функции API), через которые за денюшку можно взглянуть за стену. Ну, это всем известный факт — если раньше разово продавали продукт и клиент исчезал, то теперь через облако доить клиента можно бесконечно.
Что же мне до сих пор не ясно? Пожалуй, самую малость: я вполне допускаю, что упустил какую-то архиважную деталь и моё видение облаков чересчур уж капиталистично. Вопрос: ЧТО конкретно мне может дать облако сверх того, что я имел до этого?
Вы все знаете стек старых технологий: сервер-железо, ОСь, виртуальные машины, диспетчеры нагрузки, кластеры, СУБД, Web-сервер, Windows-service (да-да, самый обычный типа Windows Time и использующий нативный TCP), Web-service (SOAP), может даже Protocol Buffers, C#, WPF, список всем очевиден, мы все с этим работали. И вот сейчас, даже при всей очевидности доящей роли облаков, клиенты смотрят на новые ворота и отчаянно пытаются их открыть. Я как инженер понимаю, что это новое проприетарное болото и трата времени.
Из хорошего — "резиновые" ресурсы. То есть, при приходе толпы людей, сервера сами поднимутся и запустятся для обработки всей толпы, потом обратно съёжатся, не потребляя деньги.
Из плохого — когда я работал с Azure, у него было сразу три вебморды — старая, новая и сверхновая. И хрен-то найдёшь то что нужно.
Здравствуйте, Kolesiki, Вы писали:
K>Что же мне до сих пор не ясно? Пожалуй, самую малость: я вполне допускаю, что упустил какую-то архиважную деталь и моё видение облаков чересчур уж капиталистично. Вопрос: ЧТО конкретно мне может дать облако сверх того, что я имел до этого?
K>Ваши мнения?
Тезисно: Новая серебряная пуля — DevOps. Изменение цикла разработки и деплоймента приложений. Можешь выпускать апдейты по 10 раз в день и они в течение секунд становятся доступны всем кастомерам. Клиенту не нужно свое железо для установки софта и персонал для его администрирования. Нет поддержки зоопарка старых версий.
Здравствуйте, Kolesiki, Вы писали:
K>Что же мне до сих пор не ясно? Пожалуй, самую малость: я вполне допускаю, что упустил какую-то архиважную деталь и моё видение облаков чересчур уж капиталистично. Вопрос: ЧТО конкретно мне может дать облако сверх того, что я имел до этого?
ИМХО, облако — это ресурсы по требованию. Т.е., понадобился сервер или ресурс какой — развернул его за минуты (и часто настроил за еще несколько минут или часов).
Не нужен — стопорнул и в стороночку сложил или удалил, чтобы не мешался.
Всё остальное — про скорость, дешевизну и прочее — это маркетологический буллшит, на который не надо обращать особого внимания. Оно, как раз, по-разному бывает.
С>Из хорошего — "резиновые" ресурсы. То есть, при приходе толпы людей, сервера сами поднимутся и запустятся для обработки всей толпы, потом обратно съёжатся, не потребляя деньги.
Только резиновость нужно самому архитектурно поддерживать, а если монолит то никакой резиновостью и не пахнет.
Резиновыми их можно было бы назвать, если все было бы прозрачно на уровне кода, например:
long* array = new long [дайте мне 100 террабайт памяти]; //и сотню процессоров для параллельной обработки этого массива
Здравствуйте, turbocode, Вы писали:
С>>Из хорошего — "резиновые" ресурсы. То есть, при приходе толпы людей, сервера сами поднимутся и запустятся для обработки всей толпы, потом обратно съёжатся, не потребляя деньги.
T>Только резиновость нужно самому архитектурно поддерживать, а если монолит то никакой резиновостью и не пахнет. T>Резиновыми их можно было бы назвать, если все было бы прозрачно на уровне кода, например: T>
T>long* array = new long [дайте мне 100 террабайт памяти]; //и сотню процессоров для параллельной обработки этого массива
T>
Для этого 20 лет уже как существует всякое там MPI, а сотню процессоров вам всё равно никто не даст. То есть, бывают вроде машины со 128 ядрами, но это что-то редкое.
С>Для этого 20 лет уже как существует всякое там MPI, а сотню процессоров вам всё равно никто не даст. То есть, бывают вроде машины со 128 ядрами, но это что-то редкое.
В этом и проблема что это физически одна машина со 128 ядрами, а не облако десятка физических машин в сумме которые дают 128 ядер но которое можно выдать пользователю как одну машину на уровне операционной системы.
Здравствуйте, Слава, Вы писали: С>Из хорошего — "резиновые" ресурсы. То есть, при приходе толпы людей, сервера сами поднимутся
Ну не, в это не особо верится. Как правильно заметили, резиновость надо самому поддерживать (не будет же MS ради тебя SQL-кластер лепить!), плюс наверняка для "поднимутся" нужно покупать отдельный план, где тебе гарантируют макс.количество "резерва".
Железо — оно же 100% осталось старое, никто облака из космических технологий не делал. Просто судя по интерфейсу, от прогеров скрыли вообще всё и теперь ты даже не знаешь, где и как работает твоя система — голое ли железо, VM, docker или вообще на одном IIS тыщща вебсайтов — вот что меня пугает.
Раньше ты мог делать чёткий запас по надёжности, причём сам запас зависел от задачи — где узко, там и расширяем. Как это можно сделать в облаках — понятия не имею (например, запросить 1ТБ ОЗУ или организовать шардинг БД).
Здравствуйте, v6, Вы писали:
v6>Тезисно: Новая серебряная пуля — DevOps. Можешь выпускать апдейты по 10 раз в день
Хех... так ведь шлёпать релизы можно и без облаков! Более того — откуда возьмётся это ускорение, если сама суть разработки продукта не поменялась? Как и раньше, это белка в колесе "разработка-тестирование-фидбэк-разработка-тестирование до стадии <<и так сойдёт — можно в релиз>>".
v6> Клиенту не нужно свое железо для установки софта и персонал для его администрирования.
С чего бы? Облако — всего лишь новое название "сервер, где я запустил сервис". Если переделать всё под веб-морду — тогда да, но это вряд ли относится к девопсу.
v6> Нет поддержки зоопарка старых версий.
Увы, есть и никакая методология это не изменит, "зоопарк — он в сути программы". Даже новая вебморда не искоренит факта, что есть старые версии файлов и их тоже нужно уметь открывать.
Здравствуйте, _ABC_, Вы писали:
_AB>ИМХО, облако — это ресурсы по требованию.
Да, очень близко к сути их рекламы. Грусть-тоска в том, сколько это стóит и какую именно часть нужно расширять. И каким конкретно путём. Скажем, тормозную БД можно:
1. Поставить на более мощный проц
2. Увеличить память
3. Поставить сверхбыстрый RAID
4. Сегментировать таблицы
5. Сбросить устаревшие данные
6. Собрать SQL-кластер с балансировщиком и поэтессами
7. Сбросить лишнюю нагрузку (если там ещё файлопомойка и Web)
8. Поменять СУБД(!)
9. Поменять бестолкового админа на того, кто действительно умеет тюнинговать параметры сервера.
Путей — много и все они разной стоимости. Кто и как это решает в облаке, вот в чём вопрос! Не всё можно решить "а подключим мы ещё один сервер!", тут нужен чёткий план трассировки всех компонент.
Я это к чему: теряя контроль над исполняющей средой, мы превращаемся в беспомощных хомячков, прыгающих вокруг мелкомягкой цитадели: "Эй, там, на баржé! Подкрутите там чёнть, система тормозит!".
Т.е. в данном случае мы ухудшаем качество системы
Здравствуйте, Kolesiki, Вы писали:
K>Да, очень близко к сути их рекламы. Грусть-тоска в том, сколько это стóит и какую именно часть нужно расширять. И каким конкретно путём. Скажем, тормозную БД можно: K>9. Поменять бестолкового админа на того, кто действительно умеет тюнинговать параметры сервера.
Единственный правильный ответ. Всё остальное — гадание методом тыкания пальцем в неизвестную область.
K>Я это к чему: теряя контроль над исполняющей средой
В общем-то, определенные гарантии по производительности и надежности они дают. Вопрос в деньгах.
K>Т.е. в данном случае мы ухудшаем качество системы
Ну... Я бы сказал, что сценарии разные бывают. Я представляю себе сценарии, когда облако удобнее и выгоднее.
Правда, они к моей сфере не относятся никак пока что.
Самое главное (ИМХО), что оно даёт — поощряет писать приложения, которые легко горизонтально масштабируются. Это с точки зрения программистов.
С точки зрения клиентов добавилась опция "кластер по требованию", то есть это такая ферма, которая сама расширяется/сужается в зависимости от нагрузки. При этом можно по-прежнему взгромоздить Azure Services на обычный сервак и крутить всё in-house.
То есть облако — это всего лишь особый вид обычного хостинга, просто в отличие от "классического" хостинга, облако можно перенастраивать по ходу дела и прозрачно для самого приложения. И на деньги облака завязаны не более, чем сам хостинг. Собственно, вопрос "хостинг vs облако" чаще всего с практической точки зрения сводится к "клиент не может пользоваться приложением при определённой нагрузке, но зато расходы фиксированны" vs "клиент всегда может пользоваться приложением, но расходы могут плавать".
Здравствуйте, Kolesiki, Вы писали:
K>Ну не, в это не особо верится. Как правильно заметили, резиновость надо самому поддерживать
Резиновость поддерживается на уровне архитектуры. Если система построена на stateless-сервисах, то она легко масштабируется. От Azure требуется только добавлять/удалять ноды в кластер. Правда, вот этого Azure автоматически делать вроде бы пока не умеет.
Плюс, Azure даёт кучу сервисов "из коробки" — там и load balancer есть, и failover-переключение при падении ноды на ASF кластере и service locator и ServiceBus для обмена сообщениями.. там длинная портянка со списком сервисов.
Если архитектура не заточена под масштабируемость, то Azure выступает лишь в виде обычного хостинга. Ну с некоторой возможностью ручного масштабирования через переключение между вариантами доступных мощностей.
K>Просто судя по интерфейсу, от прогеров скрыли вообще всё и теперь ты даже не знаешь, где и как работает твоя система — голое ли железо, VM, docker или вообще на одном IIS тыщща вебсайтов — вот что меня пугает.
Можно поднять там VM и иметь полный доступ, практически к "голому" железу.
Интерфейс — да, сделано, видимо, маркетологами. Куча свистоперделок, а некоторые необходимые вещи физически не доступны через веб-интерфейс.
K>Раньше ты мог делать чёткий запас по надёжности, причём сам запас зависел от задачи — где узко, там и расширяем. Как это можно сделать в облаках — понятия не имею (например, запросить 1ТБ ОЗУ или организовать шардинг БД).
А как сделать 1 ТБ ОЗУ на физической машине? Уже есть такое железо?
Запасы надёжности там вполне настраиваемые. Всё от бюджета зависит.
Здравствуйте, Kolesiki, Вы писали:
K>Azure — это СТЕНА из новоиспечённых API, разделяющая старые технологии от старых программистов. Разумеется, в стене есть дыры (функции API), через которые за денюшку можно взглянуть за стену. Ну, это всем известный факт — если раньше разово продавали продукт и клиент исчезал, то теперь через облако доить клиента можно бесконечно.
K>Что же мне до сих пор не ясно? Пожалуй, самую малость: я вполне допускаю, что упустил какую-то архиважную деталь и моё видение облаков чересчур уж капиталистично. Вопрос: ЧТО конкретно мне может дать облако сверх того, что я имел до этого?
Ответ простой, но тебе не понравится. Azure это не про технологии, Azure это про бизнес. А технологии — следствие.
Здравствуйте, Kolesiki, Вы писали:
v6>>Тезисно: Новая серебряная пуля — DevOps. Можешь выпускать апдейты по 10 раз в день
K>Хех... так ведь шлёпать релизы можно и без облаков! Более того — откуда возьмётся это ускорение, если сама суть разработки продукта не поменялась? Как и раньше, это белка в колесе "разработка-тестирование-фидбэк-разработка-тестирование до стадии <<и так сойдёт — можно в релиз>>".
И с какой скоростью можно "шлепать релизы", и как быстро они попадают к кастомеру и как быстро появляется фидбек от них? В традиционном сценарии фазы этого процесса растягиваются на месяцы, в случае облака это становятся часы и минуты.
От итераций "разработка-тестирование-фидбэк" давно уже уходят.
v6>> Клиенту не нужно свое железо для установки софта и персонал для его администрирования.
K>С чего бы? Облако — всего лишь новое название "сервер, где я запустил сервис". Если переделать всё под веб-морду — тогда да, но это вряд ли относится к девопсу.
Нет. Вот раньше ваш продукт требовал sql-сервер. И клиенту приходилось покупать железо и лицензии, находить персонал, который имеет соответствующую квалификацию для администрирования. Что потом делать с этим добром, если ваш продукт уже не нужен — тоже вопрос. А теперь вы просто клиентский тенант просто пользуется облачным хранилищем и клиент платит только за то, что реально использовал и ничего не администрирует.
v6>> Нет поддержки зоопарка старых версий.
K>Увы, есть и никакая методология это не изменит, "зоопарк — он в сути программы". Даже новая вебморда не искоренит факта, что есть старые версии файлов и их тоже нужно уметь открывать.
Поддержка старых версий файлов — это малая часть от нагрузки (причем выполняется однократно) при поддержке старых версий и обязательстве вносить новые фичи в 2-3 последних релиза параллельно.
Здравствуйте, Kolesiki, Вы писали:
_AB>>ИМХО, облако — это ресурсы по требованию.
K>Да, очень близко к сути их рекламы. Грусть-тоска в том, сколько это стóит и какую именно часть нужно расширять. И каким конкретно путём. Скажем, тормозную БД можно: K>1. Поставить на более мощный проц K>2. Увеличить память K>3. Поставить сверхбыстрый RAID K>4. Сегментировать таблицы K>5. Сбросить устаревшие данные K>6. Собрать SQL-кластер с балансировщиком и поэтессами K>7. Сбросить лишнюю нагрузку (если там ещё файлопомойка и Web) K>8. Поменять СУБД(!) K>9. Поменять бестолкового админа на того, кто действительно умеет тюнинговать параметры сервера.
См. вертикальное масштабирование vs горизонтальное масштабирование.
Облака — они все про горизонтальное. Конечно, это нужно поддерживать на уровне архитектуры.
Здравствуйте, v6, Вы писали:
v6>И с какой скоростью можно "шлепать релизы", и как быстро они попадают к кастомеру и как быстро появляется фидбек от них? В традиционном сценарии фазы этого процесса растягиваются на месяцы, в случае облака это становятся часы и минуты.
v6>От итераций "разработка-тестирование-фидбэк" давно уже уходят.
Выглядит как, что в паттерне "х..як, х..як и в продакшен" сократили фазу "в продакшен" и зациклили "х..як" за деньги клиента. Не, для бизнеса это возможно и в самом деле прибыльно...
Здравствуйте, Michael7, Вы писали:
v6>>И с какой скоростью можно "шлепать релизы", и как быстро они попадают к кастомеру и как быстро появляется фидбек от них? В традиционном сценарии фазы этого процесса растягиваются на месяцы, в случае облака это становятся часы и минуты.
v6>>От итераций "разработка-тестирование-фидбэк" давно уже уходят.
M>Выглядит как, что в паттерне "х..як, х..як и в продакшен" сократили фазу "в продакшен" и зациклили "х..як" за деньги клиента. Не, для бизнеса это возможно и в самом деле прибыльно...
Автотесты. В том числе довольно экзотические и интеллектуальные типа Netflix Chaos Monkey
Здравствуйте, turbocode, Вы писали:
T>В этом и проблема что это физически одна машина со 128 ядрами, а не облако десятка физических машин в сумме которые дают 128 ядер но которое можно выдать пользователю как одну машину на уровне операционной системы.
orleans (для самостоятельного хостинга) и azure service fabric — именно оно. И автомасштбирование есть и настройка через API прямо из запущенного сервиса.
T>>В этом и проблема что это физически одна машина со 128 ядрами, а не облако десятка физических машин в сумме которые дают 128 ядер но которое можно выдать пользователю как одну машину на уровне операционной системы.
S>orleans (для самостоятельного хостинга) и azure service fabric — именно оно. И автомасштбирование есть и настройка через API прямо из запущенного сервиса.
Что оно? Там везде требуются микросервисы, а я хочу чтобы монолит видел что у него в распоряжении есть 1280 ядер и 100 терабайт памяти, так же как и TaskManager на уровне операционной системы — а будут ли эти ядра физически на одной машине или на сотне отдельных в одной сети не важно.
Вопрос: ЧТО конкретно мне может дать облако сверх того, что я имел до этого?
