How to become an author
Search
Write a publication
Pull to refresh

Comments 20

А вот отсутствие доводов против как то не закончено звучит.

Total votes 1: ↑1 and ↓0+1
Спасибо, что читаете! Мы планируем сделать серию материалов — во второй части расскажем про опыт российских проектов и уже далее перейдем к разбору кейсов, описывающих решение тех или иных проблем.
This comment wasn’t rated yet0
Для баланса может неплохо бы указать кто дропнул облака и использует свои сервера, вроде Dropbox (есть ли еще примеры?). Из тех кто про это пишет еще StackExchange использует свои железки, причем они подробно описывают какие и какова получается нагрузка (https://nickcraver.com/blog/)
Total votes 1: ↑1 and ↓0+1
Да, конечно. Мы неоднократно рассказывали о таких проектах, но в рамках одной из частей нашей серии материалов обязательно разберем и такой сегмент. Все-таки здесь нужно смотреть целый ряд кейсов, поэтому эту тему логично выделить в качестве самостоятельного материала.
This comment wasn’t rated yet0
Все крупные проекты используют свое железо — облака выходят в 3-4 раза дороже, плюс облака — это инженеры и разработчики, на которых ты никак не можешь повлиять.
Total votes 2: ↑2 and ↓0+2
Мы тоже сейчас занимаемся миграцией на AWS. Пока что основная проблема в освоении доступных в AWS компонентов. По каждому из них есть просто тонны документации и статей, но решение конкретной проблемы порой приходится долго искать. Нередко оказывается, что предполагаемое тобой решение просто не поддерживается в конфигурации (CloudFormation), зато есть в остальных API.
Total votes 1: ↑1 and ↓0+1
А мы с начала 2018 года мигрируем с PaaS Google на классических хостеров.
Решение принято после того как в течение 2-х месяцев подряд нам пришлось отдать за хостинг 70% прибыли (при том что раньше это было на уровне 4-7% и потому никого не беспокоило).
Ну и с точки зрения технологий — разработчики не могут создавать сервисы тяжелых вычислений так как это очень серьезно поднимает стоимость хостинга. А эти сервисы позволили бы повысить качество наших услуг в свою очередь.

По опыту могу предложить не завязываться на специфические средства AWS а проложить стандартизирующую прокладку дающую защиту от vendor lock. Например Kubernetes, Mesos или т.п.

Или очень тщательно просчитывать завязываясь на специфические компоненты AWS
Total votes 1: ↑1 and ↓0+1
Согласен, что облака — это далеко не панацея и не под каждую задачу подходит.
Сейчас у нас это в рамках эксперимента проводится. Знаю, что также прорабатывается возможность использования услуг Google, но я не знаю какие уже получены выводы на этот счёт. А вообще, облачная инфраструктура с Kubernetes, Mesos и Kafka уже сейчас работает на наших собственных мощностях. И будет работать, если миграция будет признана неудачной.
This comment wasn’t rated yet0
Годом ранее Netflix завершил свою долгую миграцию на виртуальную инфраструктуру Amazon. С 2016 года все важные процессы — от трансляции потокового видео до управления данными о сотрудниках и клиентах — происходят в облаке.

Это ложь. У нетфликса в амазоне был очень маленький кусок сервисов (типа авторизация клиентов) и от них они собирались отказываться из-за того, что расходились с амазоном в каких-то технических аспектах. Все сервера с контентом у них на собственных физических серверах и они много чего разрабатывают для быстрой отдачи с этих серверов. Вот, в частности: medium.com/netflix-techblog/serving-100-gbps-from-an-open-connect-appliance-cdb51dda3b99
Total votes 3: ↑2 and ↓1+1
Сорри мой инглиш. Я правильно понял что в облаках у Нетфликса только бизнес-логика а сам видео контент Нетфликс раздает со своих собственных серверов?
This comment wasn’t rated yet0
Кажется, что перенос бизнес-логики, управляющей стриминговым сервисом такого масштаба — это все-таки существенный шаг (не на пару месяцев работы и объемы данных достаточно существенные могут быть):

We rely on the cloud for all of our scalable computing and storage needs — our business logic, distributed databases and big data processing/analytics, recommendations, transcoding, and hundreds of other functions that make up the Netflix application
Total votes 1: ↑1 and ↓0+1
Кажется, что перенос бизнес-логики, управляющей стриминговым сервисом такого масштаба — это все-таки существенный шаг (не на пару месяцев работы и объемы данных достаточно существенные могут быть):

Как мне кажется, основная причина переноса бизнес-логики в AWS — это сетевая задержка. Т.е. стримить потоковое видео вы можете из единственного дата-центра, но если вы будете авторизовать пользователей по всему миру в единственном дата-центре, то из-за сетевой задержки и особенности работы TCP (установление соединений и так далее) все задачи авторизации/поиска контента и так далее у пользователя будут «тормозить». Уверен, что как только бизнес-логика станет достаточно большой задачей, нетфликс все же соберется и организует свои собственные дата-центры по миру. Во-первых, это будет дешевле, ну а во-вторых, достаточно странно платить деньги за какие-то услуги своему прямому конкуренту (Amazon имеет свой собственный видео-сервис).
Total votes 2: ↑2 and ↓0+2
Как раз для уменьшения сетевых задержек и экономии на CDN они ставят коробки провайдерам, а остальная нагрузка там динамическая и её выгодно покупать в облаке по мере надобности.
This comment wasn’t rated yet0
Решил поискать информацию по Uber. И оказалось, что они также ни на какие облака не переезжают, а предпочитают строить собственные и покупать дата-центры у Майкрософта:
www.datacenterdynamics.com/content-tracks/design-build/microsoft-sells-data-center-to-uber/94260.fullarticle

Ну и пока искал информацию по стартапам в облаках, нашел статью с кричащим названием: «WHY SOME STARTUPS SAY THE CLOUD IS A WASTE OF MONEY».
www.wired.com/2013/08/memsql-and-amazon

Frenkiel estimates that, had the company stuck with Amazon, it would have spent about $900,000 over the next three years. But with physical servers, the cost will be closer to $200,000. «The hardware will pay for itself in about four months,» he says.


Общий вывод — если ваш стартап завтра может загнуться, то покупайте облака. Если планируете работать долго, то только свое железо, только хардкор.
Total votes 4: ↑2 and ↓20
Кажется, вы сами себе противоречите (ссылка на ваш пост):

Подавляющее большинство ИТ-инфраструктур малого бизнеса, с которыми мне пришлось сталкиваться, имеют один существенный недостаток – они не масштабируемы. Нет, нет, проблема не в том, что к имеющимся в настоящий момент 50-ти компьютерам вы не можете подключить 51-й. Проблема в том, что заложенная изначально архитектура создает с ростом бизнеса непропорционально больше проблем и затрат, нежели приносит пользы.
This comment wasn’t rated yet0
Никакого противоречия с моей статьей нет. Масштабируемость — это возможность системы справляться с возрастающей нагрузкой исключительно за счет добавления аппаратных ресурсов. В моей статье описаны причины по которым в малом бизнесе масштабировать заложенную изначально инфраструктуру не получается и одна из таких причин (пункт 9 в статье) это как раз использование облачных сервисов.
Total votes 3: ↑2 and ↓1+1
Решение о переходе в облака или использовании собственных решений нужно принимать не на основании эмоций или «одна фирма сказала», а на основании калькулятора. Это же бизнес, или не бизнес? Поэтому калькулятор — самый главный советчик. Причем считать надо время владения за разумный период времени, а не сравнивать только первый год.
Плюс к этому практически все облачные сервисы перед покупкой как О.Бендер «разворачивают перед нами широкие горизонты и окрашивают их в голубой и розовый цвета». А потом, когда контракт подписан на год или более, часто оказывается, что документация даже не соответствует действительности — знаем, сталкивались. И если даже калькулятор дает добро, то лучше всего стартовать с пилотного проекта и посмотреть, как хороши или не очень их сервисы и API для твоего проекта.
This comment wasn’t rated yet0
Sign up to leave a comment.

Your account

Sections

Information

Services

Support
© 2006–2024, Habr