Вот есть облачные платформы у 3 гигантов. У микрософта -- Azure, у Amazon -- AWS, у Google -- GAE.

Они появились почти одновременно (в исторических масштабах), при этом каждый выкатил свои фишки.

Amazon был первопроходцем, сначала там было все похоже на VDS, но с поминутной оплатой. Потом уже расширили и сделали простую возможность настойки авто-масштабирования.

Микрософт сразу начал с авто-масштабирования.

Google, конечно, хотел обскакать всех со своим GAE -- оплата за такты процессора, а не за время.

Но вот популярность GAE низкая. И уже боязно туда лезть, ведь раз низкая популярность, значит скоро они его закроют, как многие другие сервисы. А раз скоро закроют -- то не стоит в него вкладывать время и силы, если уж так хочешь облаков -- используй решения от более стабильных конкурентов. А раз никто не хочет рисковать -- значит деньги туда не пойдут и Гугл его 100% закроет, как мы раньше видели закрытие многих сервисов Google.

Получается Google такой большой недотепа. Ранее они заявляли, что мы закрываем сервисы, так как хотим сосредоточиться на основных -- поиске и gmail. Так нахрен вы их воощбе открывали, о чем думали?

Вот по этому теперь им стоит позабыть об открытии новых сервисов, того же Cloud Computing -- они недотепы, опять все начнуть и бросят. Никто не будет связываться с такими.

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

А есть какая-то статистика по GAE/AWS/Azure? GAE непривычен тем, что для оптимальной утилизации ресурсов там надо писать на каких-то своих фреймворках, использовать какие-то гугловые недобазы. А на амазоне просто виртуалка с обычным человеческим линуксом без всяких глупостей. Честно говоря до сих пор не понимаю, зачем люди используют всю эту муру вместо того, чтобы купить обычный VPS.

Здравствуйте, vsb, Вы писали:

vsb> зачем люди используют всю эту муру вместо того, чтобы купить обычный VPS.
К обычному VPS нужно еще купить сисадмина, который на коленке сделает на обычных VDS
— autoscaling
— load balancing
— monitoring
— distributed database

А на этой муре(AWS) можно все эти вещи мышкой накликать за 50 баксов в месяц.

09.12.2016 10:22, c3p0 пишет:
> vsb> зачем люди используют всю эту муру вместо того, чтобы купить
> обычный VPS.
> К обычному VPS нужно еще купить сисадмина, который на коленке сделает на
> обычных VDS
> — autoscaling
> — load balancing
> — monitoring
> — distributed database

Почему-то у меня такое ощущение, что 99.9% проектов, хостящихся в AWS
это не потребуется никогда. Старый становлюсь, мнительный )

--
WBR,
Serge.

deleted

Здравствуйте, rean, Вы писали:

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

R>Просто вы пока не работали с big data c огромным количеством пользователей по всему миру.

Да никто с такими проектами не работает, все покупают виртуалку на амазоне в 10 раз дороже какого-нибудь цифрокеана и запускают там какой-нибудь мелкий сайтик.

R>Данная модель(мура) вычисляет очень хитро — на ближайшей к пользователю инстанции. Грубо говоря, это параллельный php на сотнях или тысячах ближайших серверах без нагрузки на магистральные каналы связи. Например, нужный код может физически оказаться прямо на сервере в вашем городе и нет надобности вокруг земного шара гонять траффик.

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

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

Здравствуйте, vsb, Вы писали:

vsb>Да никто с такими проектами не работает, все покупают виртуалку на амазоне в 10 раз дороже какого-нибудь цифрокеана и запускают там какой-нибудь мелкий сайтик.

Ну не скажите. Иногда даже обычный сайтец после публикации новости о продукте на популярном сайте перестает работать. А это ваш можно сказать звездный час и есть риск его профукать.

Даже если 95% времени у вас загрузка процессора 1-5%, то ради такого звездного часа стоит переплатить.

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

Свое оборудование -- это когда у вас стабильная загрузка сервиса, когда вы стоите на ногах.

H>Почему-то у меня такое ощущение, что 99.9% проектов, хостящихся в AWS
H>это не потребуется никогда. Старый становлюсь, мнительный )

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

Например у вас магазин с непрерывным потоком заказов. И простой ему крайне вреден. Покупаете распределенныен ресурсы и натягиваете базу данных на несколько серверов в несколько кликов.
Здесь даже не про big-data или какие-то сложные вычисления. Подойдет и для магазина, торгующего памперсами. Думаю на амазоне таких проектов миллион.

Здравствуйте, c3p0, Вы писали:

C>Например у вас магазин с непрерывным потоком заказов. И простой ему крайне вреден. Покупаете распределенныен ресурсы и натягиваете базу данных на несколько серверов в несколько кликов.
C>Здесь даже не про big-data или какие-то сложные вычисления. Подойдет и для магазина, торгующего памперсами. Думаю на амазоне таких проектов миллион.

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

09.12.2016 16:55, c3p0 пишет:

> Например у вас магазин с непрерывным потоком заказов. И простой ему
> крайне вреден. Покупаете распределенныен ресурсы и натягиваете базу
> данных на несколько серверов в несколько кликов.

Зачем??? Сколько у вас по времени в год занимает простой из-за
недоступности одного VPS в том же DigitalOcean? У меня вот
околоноля.

Натягивание же чего угодно "на несколько серверов" предполагает что софт
изначально написан с прицелом на работу в кластере, иначе риски того,
что он будет глючить на порядок выше рисков недоступности сервера.

--
WBR,
Serge.

Здравствуйте, vsb, Вы писали:

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

Это налог на невежество.

С>Расскажите мне пожалуйста, как обычная реляционная база растягивается на несколько серверов.

Рассказываю
https://aws.amazon.com/rds/details/multi-az

Здравствуйте, c3p0, Вы писали:

С>>Расскажите мне пожалуйста, как обычная реляционная база растягивается на несколько серверов.

C>Рассказываю
C>https://aws.amazon.com/rds/details/multi-az

>БД в нескольких зонах доступности Amazon RDS автоматически создает первичный инстанс БД и синхронно реплицирует данные на резервный инстанс в другой зоне доступности.
>синхронная физическая репликация для поддержания синхронизации резервного инстанса с основным.

Ускорения в такой схеме я не вижу. Один центральный сервер, на него все пишут, запись в него должна расползтись по всем репликам, а это занимает время, и — пока она не окажется на всех репликах, чтение ни с одной реплики не должно показать эту запись. Такая запись займет больше времени, чем запись на один сервер. Что же, у амазона каналы собственные, прямое оптоволокно прямо из Санта-розы в Шанхай? Я конечно несколько утрирую, есть всякие READ UNCOMITTED — а много ли разработчиков вообще пользуются уровнями изоляции при работе с БД? Даже — много ли людей в курсе про такое?

Во время моей работы в одной новосибирской MS-ориентированной конторе, которая делала техническую часть стартапа на Azure для тройки менеджеров из MS (учится папа за васю весь год, ага), там был подсчет голосов. И реализован он был в таком виде на EntityFramework:

using (var base = CreateContext()
{
    var voting = base.GetVotingById(id);
    voting.Votes++;
    base.SaveChanges();
}

(уж не помню, кто это написал — то ли MS-овцы, то ли мой предшественник — хипстерского вида мастер на все руки — бэкенд, фронтенд, MVC, Angular)

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

do
{
    try
    {
        using (var base = CreateContext()
        {
            var voting = base.GetVotingById(id);
            voting.Votes++;
            base.SaveChanges();
        }
    } catch (ConcurrentModifyException e)//или как там оно зовётся...
    {
        continue;
    }
} while (false);

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

С>Я хочу сказать, что чудес не бывает, и автоматическим может быть только вертикальное масштабирование, а для одновременной работы нескольких серверов программист тоже должен приложить усилия, и немаленькие. И таких программистов еще поискать надо, а тем более — менеджеров для них.

Спасибо за рассказ про голосование.
Согласен, что для работы на кластере серверов нужны нетривиальные решения, заточенные под конкретные приложения.

Мне, как клиенту database-хостинга, который не любит возиться с базами, нужно надежное хранилище, в которое можно положить и достать и получать уведомления на почту о доступности базы. И эту задачу амазон решает, размазывая(зеркалируя, реплицируя). Производительность для меня не особо критична. Радует что в случае поломки основной базы, она будет автоматически восстановлена из копии. Короче позволяет расслабиться и заниматься другими более важными делами. Настроив автоматические бэкапы конечно же.

Здравствуйте, Слава, Вы писали:

С>

С>do
С>{
С>    try
С>    {
С>        using (var base = CreateContext()
С>        {
С>            var voting = base.GetVotingById(id);
С>            voting.Votes++;
С>            base.SaveChanges();
С>        }
С>    } catch (ConcurrentModifyException e)//или как там оно зовётся...
С>    {
С>        continue;
С>    }
С>} while (false);
С>

Это пример из документации, неоднократно видел. Можно даже сказать паттерн. Для RSDN бы подошел, к примеру, здесь не так уж часто ставят оценки и исключение будет возникать редко (ошибка возникнет если по одному id слишком часто будут голосовать). Для ютюба не подойдет -- там по 100 оценок в секунду на 1 популярное видео, будет тормозить из-за ConcurrentModifyException. Есть другое решение с применением транзакций в кеш-памяти (или неблокирующих операций) с периодическим сохранением в базу.

Здравствуйте, Shmj, Вы писали:

S>Это пример из документации, неоднократно видел. Можно даже сказать паттерн. Для RSDN бы подошел, к примеру, здесь не так уж часто ставят оценки и исключение будет возникать редко (ошибка возникнет если по одному id слишком часто будут голосовать). Для ютюба не подойдет -- там по 100 оценок в секунду на 1 популярное видео, будет тормозить из-за ConcurrentModifyException. Есть другое решение с применением транзакций в кеш-памяти (или неблокирующих операций) с периодическим сохранением в базу.

Дело в том, что хватило бы обычного update vote set counter = counter + 1 where id = @id

http://stackoverflow.com/questions/193257/in-ms-sql-server-is-there-a-way-to-atomically-increment-a-column-being-used-a

На уровне изоляции который в MSSQL по умолчанию READ COMMITTED

Здравствуйте, Слава, Вы писали:

С>Дело в том, что хватило бы обычного update vote set counter = counter + 1 where id = @id
С>http://stackoverflow.com/questions/193257/in-ms-sql-server-is-there-a-way-to-atomically-increment-a-column-being-used-a
С>На уровне изоляции который в MSSQL по умолчанию READ COMMITTED

Тут дело даже не в облаках а в особенности Entity Framework, в котором нет голых UPDATE.