Комментарии 71
Если новый проект делать, то собственно почти без разницы в каком облаке начинать, особенно если есть желание экспериментов
почти без разницы в каком облаке начинать
Ой-вей…
Все данные синхронизируются с ФСБ, где в них онлайн ищется что-то запрещенное и в случае успеха к владельцу выезжает маски-шоу, изымающее компьютерную технику, которая идет на строительство СберКлауд?
Кроме очевидных составляющих по фичам и стоимости, интересуют юр. поддержка российских законов по персональным данным и прочему. Если еще нет, то надеюсь, что скоро появится.
Так же можно говорить, что AWS и GCP синхронизируются с ЦРУ и ФБР. Непонятно зачем строить бизнес на чем-то запрещенном.
Только ЦРУ и ФБР далеко, а ФСБ — близко.
Ну, и вы можете себе представить ситуацию, когда вы не пропускаете хама с обочины в свой ряд, а он оказывается агентом США и уничтожает вашу жизнь? Я — не могу.
А вот вариант, когда он оказывается вполне себе сотрудником силовых ведомств РФ и уничтожает вашу жизнь — легко.
А тут и ехать никуда не надо. Чувствуете разницу?
То есть риск не нулевой, да, в обоих случаях. Но вот шанс срабатывания риска — разный.
Они могут везти больного родственника в больницу.
Очень неприятный опыт
В 99 остальных это просто борзые люди. И пока по обочинам носятся хамы, извините, я вникать в каждую ситуацию не буду.
А еще мне нравится наблюдать, как в Москве машины ездят по тротуарам. Эти тоже спешат в больницу где-то в ближнем Подмосковье?
Так и на вокзале 1 из 100 случаев действительно нуждается, и ему дать денег — благое дело. Но вот остальные 99 попрошайки, половина из которых участвует в организованной преступности.
всяческих вам удач
Жизнь станет намного лучше и счастливее.
Вселенная разберётся, как и когда наказать за overusage.
PS. как же, бл… блин, бесят, когда вылезают такие «розовые пони» и с невинной физиономией — ну как же, у нас тоже закон и порядок, почему вы не доверяете нашим сервисам и службам? потому, блин, что нет ни одной причины им доверять; зато обратных причин — дофигища. Так понятно?
Где хуже/лучше — весьма сложно определить, т.к. нужно собрать полноценную статистику, а не какие-то отдельные случаи.
Почитайте наши _новые_ законы.
Где сажают за мирные митинги и пикеты? Где детей предпочтут уморить в детдоме, нежели дать усыновить иностранцам — и только как месть за персональные санкции.
Власть менее жестокая пока, чем «советы», но по подлости сравнялись точно.
Но вы ведь все это знаете — и на голубом глазу пишете «весьма сложно определить». Это называется бесстыдство. Так что — да, вполне кореллируете с нынешней властью.
Непонятно зачем строить бизнес на чем-то запрещенном.
Запрещенным по российскому законодательству может стать что угодно. Например туристическая фотография сувенирной лавки в Мадриде, потому что на витрине лежит немецкая медаль со свастикой.
Глеб Борисов рассказывает о Yandex Cloud Functions, IoT, API Gateway www.youtube.com/watch?v=rExb5NRl1T0
Андрей Фомичев рассказывает о Yandex Database Serverless www.youtube.com/watch?v=o0-IpbkQKjc
Михаил Костин рассказывает про Object Storage www.youtube.com/watch?v=qsmfFgTtkiE
И приятный бонус для всех кто хочет попробовать Serverless — уровень нетарифицируемого использования (free tier) для сервисов экосистемы бессерверных вычислений cloud.yandex.ru/docs/billing/concepts/serverless-free-tier включает:
- Yandex API Gateway
- Yandex Cloud Functions
- Yandex Database
- Yandex Object Storage
- Yandex Message Queue
- Yandex IoT Core
- Yandex Virtual Private Cloud
О, и приходите к нас в телеграм-чат задавать вопросы: t.me/YandexCloudFunctions
aws.amazon.com/ru/lambda/pricing
cloud.yandex.ru/docs/functions/pricing
Но так в лоб сравнивать сложно, нужно подходить комплексно по всему объему используемых компонентов. Разница получится сильно больше.
Эти ваши Lambda Cloud Functions умеют работать по вебсокетам?
Да меня меня как-то не интересует вендор-лок, спасибо.
А что, простите, не вендор-лок?
aws, azure, gcp, сбер?
VPC/VPS
Ждем когда будет раскол и sbercloud делать свои решения, а не купленные. Ведь чем больше будет объем клиентов и потенциальной базы, то и будет жаль зависеть от вендора — который, делает решения по своей логике (иногда, мне не ясна данная логика, но как есть).
В целом, если бы статья напрямую не противопоставляла себя крупному облачному провайдеру aws, то читать было бы по приятнее, тем более первая картинка, прям говорит нам «смотрите, какие мы молодцы и как умеем — это только начало», по факту настороженность по отношению к новому облаку будет еще выше… Могу только пожелать удачи и быть более аккуратным с дальнейшей публикацией статьей с целью увеличить аудиторию.
В общем, у сбера есть нормальные такие шансы остаться с кучей облачного софта на руках без его поддержки вендором. Пилили бы уже своё.
Ничего ему не сделается, такие корпорации как Huawei, IBM, Сбер слишком плотно связаны с государством, они будут на плаву пока эта связь не прервется (а это очень длительный и редкий процесс) или пока не схлопнется само государство, чего тоже не ожидается в обозримом будущем. В худшем случае Huawei уйдет с рынка смартфонов, как в свое время Siemens. Только у Huawei еще останется огромный внутренний рынок смартфонов.
Почему-то во всех моих экспериментах serverless сливает по скорости разработки старому-доброму VPS. Про стоимость ресурсов даже не буду говорить.
Какая такая экономия на поддержке когда нужно плясать с бубном вокруг ограничений этого serverless?
Откуда вдруг готовность к нагрузкам если вы все ещё ходите в реляционную БД? А если не ходите, то внезапно оплачиваете костыли к NoSQL для базовых вещей вроде транзакций или отсутствия join.
Откуда возьмётся малая стоимость обслуживания когда вы строите систему на максимально примитивных (с точки зрения API и фич) технологиях, которые нужны только фейсбуку и гуглу? После того как вы вбухаете в 2 раза больше денег в разработку вы действительно сможете экономить $10 в месяц если вашим детищем никто не пользуется.
1. Сервисом никто никогда не воспользуется — я за него ничего не буду платить.
2. Набежит миллиард пользователей и каждый принесёт денег. Оно всё выдержит, а я озолочусь!
Возможно их ставки и сыграют, кто же знает. «В среднем по больнице», нет, конечно же :)
И в DynamoDB есть транзакционное изменение данных.
Есть у вас два узла, половина данных на одном, половина на другом — так нужно для масштабирования. Теперь у вас транзакция, которая модифицирует часть данных на одном узле, часть на другом. Скоординировать такое можно либо путём переговоров между узлами (медленно) либо имея координатор транзакций (не быстро, точка отказа, что-то вроде contended lock в многопоточной системе). У Яндекса координатор, да ещё и заигрывания с однопоточными tablets, в связке с транзакциями это может быть очень весело.
Можно также heroku вспомнить, там все без докера, без оплаты за запросы и было много лет назад. Такой подход сильно лучше лямбды, но не без ограничений.
То есть запускать что-то не имея серверов можно было ещё 10 лет назад. Но тема serverless чаще всего всплывает в контексте «бесплатного или автоматического масштабирования. Но чудес не бывает и «бесплатное» масштабирование требует особых систем хранения (без полноценных транзакций, чаще всего) и особой архитектуры. И все это стоит очень дорого в разработке. Вот о чем речь.
Еще не ясно как жить без foreign keys в любых ситуациях кроме тривиальных?
Serverless о трех вещах — плате только за использование (за энергетическую величину вида CPU * MEM * SEC), бесконечном автоматическом масштабировании (в пределах возможности датацентра) и управляемых ресурсах (видимого сервера попросту нет и поэтому он не может упасть или зависнуть)
По стоимости во много раз дешевле новомодных кублетов, которые и не масштабируются (только в рамках железа, на которые эти кубы руками установили), и не гарантируют никакой отказоустойчивости (управляющий куб может зависнуть)
В serverless такое не возможно по очевидным причинам — это плата как за услугу, и тот же AWS обеспечивает ее всеми силами, а если не выполнит SLA — окажется должен денежек. Кублеты же держатся на добром слове и квалификации devops-инженера
Преимущества собственного hardware-сервера тоже понятны — с этим спора нет. Для многих задач это дешевле и удобней. Но вот истинная загадка — что побуждает людей покупать облачные кублеты за астрономические деньги?
Выбор hardware-сервера или serverless-решения зависит от задачи и может выигрывать или проигрывать по ряду параметров. Но кубы же проигрывает по всем показателям всем вместе взятым — они и дороже, и круглосуточно едят денежки, и могут упасть
Автоматического масштабирование бывает когда архитектура под это сделана, такая архитектура во много раз дороже «традиционного» подхода. Сервера зависают и у Амазона тоже, никаких денежек вы с Амазона не получите при нарушении SLA если только вы не размером с Амазон.
Под кублетом видимо k8s имеется в виду, если так, то эта штука имеет смысл только для очень специфических сценариев. K8s позволяет отделить людей которые за железо отвечают от людей которые программы пишут, такой хитрый интерфейс взаимодействия. Никаких проблем масштабирования он не решает сам по себе. Как интерфейс взаимодействия тоже не все гладко, работает приемлемо только если ничего не глючит, а это не всегда так.
Не надо использовать Serverless там где требуется работа не по запросу, а постоянный сервис.
Как вариант, страница на S3, которая держит линк на api gateway запускающий функцию, которая что-то делает в базе. Отличный сценарий для IoT.
Мы сами тоже участвовали в хакатоне SberCloud (команда Get Outfit), но чужие впечатления очень помогают расставить всё по местам.
Вам объяснили, из-за чего АнтиКуб не прошёл в финал? Вроде бы проект хороший, некоторые в финале были послабее.
Serverless шагает по планете. Сравним SberCloud и AWS