>>Похвалюсь. Про нас тут в гугле написали.

50 тысяч пользователей, 2.1М поездок за год. А в чем прикол-то? Это любой 4 процессорный дрыщевый сервер осилит. Зачем облако ?

Не понимаю я эти современные технологии.

>>Пардон, "дороговато"

Я беру в хендерсоне, вполне устраивают.

> tesseract ©   (04.10.17 01:03) [60]
>
> >>Похвалюсь. Про нас тут в гугле написали.
>
> 50 тысяч пользователей, 2.1М поездок за год. А в чем прикол-
> то? Это любой 4 процессорный дрыщевый сервер осилит. Зачем
> облако ?
>
> Не понимаю я эти современные технологии.

У нас в старой системе в принципе так и есть. Обычный клиент-сервер.

Во-первых, ты исходишь из того, что поездки равномерно распределены. Но это не так. Например, в течение сезона по ночам или всю зиму поездок ровно ноль, а вот в теплый субботний летний вечер поездок столько, что дешевый сервер не справится. То есть приходится держать сервер с запасом только ради того, чтобы выдержать пиковую нагрузку несколько часов в год. А вот кластер в облаке может управлять своей производительностью автоматически в реальном времени.

Потом, это же цифры для одного города. А у нас их сейчас три. Дальше - больше. Управлять облаком проще и дешевле, чем пятнадцатью серверами.

Ну и наконец стабильность. Если у тебя сервер упал, то вся система не работает. А кластер kubernetes и гугловые облачные БД целиком уронить намного сложнее.

> Если у тебя сервер упал

а если два и кластером? сие еще оооочень в дооблачные времена делали, с той же распределенной нагрузкой, с географическим разносом, новелл 6.5

Не понимаю я эти современные технологии.


вот смотри пример.
дюжина одинаковых ораклов (или не ораклов) - филиальная сеть.

иногда надо получить данные со всех сразу. типа консолидированный отчет.
ты делаешь дблинки, и на главном рисуешь вьюху из дюжины юнион олл.
нормально?
нет.

но если обработка распределенная, то
-данные получаешь быстрее
-если до какого сервера нет канала, то это не влияет на доступность данных остальных серверов

>>А вот кластер в облаке может управлять своей производительностью автоматически в реальном времени.

Это-то я прекрасно знаю. Правда "реальное время" это сильное преувеличение. Если данных как у курка -то да, реальная учетная база немножко падать начнет.

> KilkennyCat ©   (04.10.17 04:39) [63]
>
> > Если у тебя сервер упал
>
> а если два и кластером? сие еще оооочень в дооблачные времена
> делали, с той же распределенной нагрузкой, с географическим
> разносом, новелл 6.5

Можно что угодно сделать самостоятельно, непонятно только зачем и что это даст.

> tesseract ©   (04.10.17 10:51) [65]
> Это-то я прекрасно знаю. Правда "реальное время" это сильное
> преувеличение. Если данных как у курка -то да, реальная
> учетная база немножко падать начнет.

Нет, не преувеличение. Запуск новых нод занимает секунды
Ну и Google Datastore падать не начнет :)

Т.е. по сути гугл задешево кому угодно дает доступ к инфраструктуре, которую раньше эксклюзивно под себя делали только большие и богатые.

У какого-нибудь Мегафона и без гугловых облаков все хорошо с шардингами, репликациями и балансировкой нагрузки. Но не всем целесообразно строить собственный датацентр.

>>Запуск новых нод занимает секунды

Зачем ноды на такой нагрузке? Они на cortex-m0 что-ли? И секунды уже не "реальное время", а "приемлимое".

>>Но не всем целесообразно строить собственный датацентр.

Как замена мощной, распределенной системе с >100к активных сессий,  это отличное решение.  Но на малых нагрузках оверхед такой системы будет процентов 50-70.

Реклама: вычислю на кофейной гуще требуюмую призводительность ит-инфраструктуры

Можно что угодно сделать самостоятельно, непонятно только зачем и что это даст.

бывает такое, что делаешь что-то конкретное, но "по другому".
и когда это конкретное уже готово,
ты вдруг видишь
что если туда добавить пару штрихов,
то получается супер удобный и полезный и уже универсальный инструмент.

> tesseract ©   (04.10.17 12:48) [69]
>
> Но на малых нагрузках оверхед такой системы будет процентов 50-70.

Глупость какая-то. Честно.

Оверхед по сравнению с чем? По сравнению с самодельной конфигурацией из дублирующих друг друга серверов, которые 99% времени простаивают без дела?

Или оверхед в том, что можно не нанимать человека, который будет обслуживать кластер из физических серверов?

Тут ведь еще и вопрос стоимости масштабирования важен. Вчера у тебя один город, сегодня три, через месяц 15, через год 50. Когда ты в облаке, этот рост происходит легко и естественно. А вот в обратном случае ты закопаешься в операционных расходах на обслуживание сотен серверов.

Почему не загнать все 50 на один мегасервер? Города должны иметь возможность работать независимо друг от друга по куче разных причин.

> Kerk ©   (04.10.17 12:11) [66]
> Можно что угодно сделать самостоятельно, непонятно только
> зачем и что это даст.

это понятно. я к тому, что
> Не понимаю я эти современные технологии.

- технологии не современные. И всякая модность облака и плюшки-фишки - это всё было давным давно, только не у всех.

>>Оверхед по сравнению с чем?

По сравнению с функцией без кучи маршалинга и диспетчерезации между серверами, затрат на лишнюю маршрутизацию.

> tesseract ©   (04.10.17 14:18) [75]


> По сравнению с функцией без кучи маршалинга и диспетчерезации
> между серверами, затрат на лишнюю маршрутизацию.
>
>

так это уже головная боль гугла, что там за оверхеды у них.
в новых технологиях одни плюсы, за исключением возникновения зависимости от того же гугла, но это минус довольно условный.

>>так это уже головная боль гугла, что там за оверхеды у них.

Изначально был разговор про "нафига такую малую нагрузку переносить в облако"?

По теме ответил только ты :-)

>>новелл 6.5

у меня много красивых бумажек имеено по 6.5 :-)

Как-то все не весело на рынке труда :)