Комментарии 42
Чтобы запустить стартап в доамазоновую эпоху нужно было найти хостинг и зарегистрироваться. Отправить письмо в компанию, которая предоставляет сервера. Через неделю-другую, наконец, получить доступ и начать настройку. Если стартап затребует еще серверов — повторить всё по новой. До получения в эксплуатацию машины проходило больше месяца.
Страсти-то какие, если ты стартап, то в те времена можно было легко начать с офисного компа и выделенного айпишника, никто тебя даже не ДДОСил. А потом перейти на пул айпишников и стойку с серверами в том-же самом офисе. И таких прям дофига было. У нас в офисе в Беркли, в том-же самом, что и 25 лет назад, до сих пор стойки с серверами пашут, хотя почти все основные сервисы переехали на AWS.
Крупные компании-монополисты сейчас тратят ресурсы на разработку не эффективных технологий для решения задач клиента, а чтобы эффективно брать за это деньги. Этакий скрытый углеродный след (то как приходится использовать лямбды чтобы сделать что то сложное в статье описано, будешь использовать ресурсов многократно выше чем мог бы при правильной реализации)… это почти прямая аналогия проблемы безудержного потребления из мира предметных товаров, когда все разрабатывается с главной целью — чтобы клиент купил и выкинул как можно быстрее, чтобы снова купить новое. Все должно быть сложным и дорогим к обслуживанию, все должно быть не прочным чтобы ломалось ровнеханько после гарантийного срока,… и все это завуалировано под 'клиенту надо по современнее и новее, зачем ему со старьем сидеть', параллельно делая все старое, что еще могло бы работать — неработоспособным.
Жаль статья написана языком, что нельзя дать людям, не очень сведующим в it чтобы прониклись, но цитировать избранное про вендорлок и высокие цены надо обязательно.
Все должно быть сложным и дорогим к обслуживанию, все должно быть не прочным чтобы ломалось ровнеханько после гарантийного срока
все это завуалировано под 'клиенту надо по современнее и новее, зачем ему со старьем сидеть', параллельно делая все старое, что еще могло бы работать — неработоспособным
То есть вы считаете что подняв самому то что есть в амазоне для большого проекта вы сделаете его более надеждным? У меня есть опыт сопровождения и класических проектов и облачных-я на достаточно большом проекте не смогу гарантировать такую же надеждность какую смогу добиться в амазоне.
Чем выше требования к надежности тем выше цена, это логично.
Вот только помним что нет нужды вдаваться в крайности, не нужно самостоятельно на своих мощностях поднимать сервер, лучше это сделать в нормальном датацентре, плюс возможность получить новую машину в секунды, с помощью apiуже стали нормой
Вопрос только в софте и его поддержки (тут тоже есть своя надежность и точки отказа).
Потом пришли лямбды, которые вообще разделили функционал по эндпоинту. Получились такие нано-сервисы. Каждый эндпоинт — это отдельное приложение. Всё это хорошо до момента, пока не понимаешь, что тебе нужно 10 таких эндпоинтов, у тебя переиспользуются сущности, есть взаимосвязи между приложениями. Конечно, можно скопипастить всё это дело, будет 10 лямбд, которые будут повторять друг друга. А что такого? Я стартап, мне надо быстрее на рынок!
Хм, жесть какая-бить по одному эндпоинту на сервис. Был в 3 компаниях, ни разу не видел такого. Обычно 1 лямбда — 1 микросервис, ничем принципиально в плане написания не отличается от классчиеских сервисов. Руководил командой в которой было около 400 эндпоинтов(очень примерно, никто не считал)-это нам по этой логике надо было писать 400 лямбд?
Причем например если посмотреть бибилотеки амазона(например для алексы) там тоже не предпологается такой подход.
Это же ловушка: мы решим вашу маленькую проблему очень легко, но потом вы будете до конца дней хостится у нас, потому что переход встанет в копеечку. Представим успешный стартап, у которого всё получилось. Миллион пользователей, деньги. Да, приходиться делиться с Амазоном. Чем дольше ты остаешься, тем рискованнее переходить. Получается нет момента, когда переход будет оправданным. В итоге ты всю жизнь платишь Амазону страшную кучу денег.
А иначе ты создаешь отдел который для тебя пишут и поддерживает эту инфраструктуру. И если на маелньких проектах это небольшая проблема, то на больших распределленных проектах это ооочень дорого и долго. Для каждого проекта надо индивидуально смотреть что выгоднее, но с фразой "В итоге ты всю жизнь платишь Амазону страшную кучу денег." как-то очень сложно согласиться.
Амазон как раз для больших компаний и выгоден. Когда у них парк в 1000 машин, заказанных 100 отделами, с средней утилизацией CPU в 6%. Все это заменятся на лямбды, которые дороже, но утилизационный уже 100%. Или права доступа, те же 1000 машин к которым неизвестно кто, когда и зачем имеет доступ. А у AWS есть IAM, Cloud Trail и System Manager которые все это позволяет контролировать.
Но если внимательно посмотреть на терраформ, для того, чтобы нормально поддерживать и Гугл, и Амазон, тебе нужно два терраформа.
Довольно верное замечание, а ещё есть приложения, которые внутри себя поддерживают облачных провайдеров, и тогда описание конфигурации перетекает в них, но это всё равно несколько конфигураций, и для гибридного разворачивания уже хочется шаблонизатор, который бы генерировал конфигурации в зависимости от провайдера.
Поясните, пожалуйста, старому разработчику, как так получается?
Ты решил сделать стартап. Появилась классная мысль — сдавать свою надувную кровать. Налабал формочку, подключил базу. Теперь нужны сервера. Но, блин, ты не хочешь нанимать дорогих опсов, которые будут сидеть в дата-центре и настраивать сети и фаерволы, таскать железо… В этот момент появляется Амазон и берёт всё на себя.
Если ты нанял разработчика для "налабать формочки + базу", скорее всего, он уже знает, где можно разместить код. Сервер, VPS, shared-hosting (для совсем бедного стартапа). И ведь много не надо. Средненький VPS держал спокойно по 15-20 тыс. посетителей в день. Сервер - гораздо больше.
В какой момент нам стало лень выполнить на серваке через шелл 30 команд, но не лень разворачивать это всё в облаках? Или я чего-то не понимаю?
Согласен, причем в данном варианте среднему инженеру проще поднять базу+веб-сервер на впске и значительно дешевле чем идти в облако. Для АВСа понадобится куча дополнительных знаний и слоев абстракций.
Как раз преимщество облаков будет там где усложнится инраструктура/повысятся требования к надежности/увеличиться нагрузка и понадобиться масштабирование/. Ну или ты уже спецалист по амазону.
В AWS в данном варианте понадобится 4 клика в wizard-е какого-нибудь Elastic Beanstalk или AppRunner, пенсионерка справится. А VPSки есть в AWS Lightsail.
По цене будет примерно так же, по надежности и удобству работы на порядок лучше.
А VPSки есть в AWS Lightsail
В данном варианте vps vs amazon я именно смотрю на вариант поднять облачную инфраструктуру на основе амазоновских сервисов vs поднятая впска на которой сами поднимаете то что вам надо. Понятно что можно также поднять впску в амазоне, но особых отличий от других облаков приницпально небудет, по цене-скорее всего дороже, просто сам по себе амазон стоит дороже чем какой-нибудь lenode, DO.
А вот для поднятия полноценной облачной инфраструктуры нужна экспертиза, если у вас она есть-то, как я и написал амазон отличный вариант. А если нету то вам надо понять какой сервис выбрать, как их сконфгурить, расчитать стоимость(что при интеграции уже 3-4 сервисов может оказать непростым делом). Вы вместо поднятия знакомых сервисов будете изучать аналоги амазоновские.
То есть, если вам полностью подходит хорошо известное вам решение, то лучше использовать его? С этим не поспоришь. Еще лучше когда все уже готово и работает, тогда вообще ничего делать не надо.
Но вот вдруг вы, например, не умеете поднимать мониторинг и логгинг на vpsках, а надо. В амазоне он сразу у вас есть. Или придет к вам усатый суперинтендант и спросит соответствие стандартам хранения перс данных. AWS сервисы уже сертифицированы, а вам надо искать контору.
Может быть, иногда имеет смысл приобрести какие-то новые знания и опыт с новыми технологиями, а не использовать старые пока работает, а потом вдруг обнаружить себя отставшим от паровоза?
Или придет к вам усатый суперинтендант и спросит соответствие стандартам хранения перс данных.AWS сервисы уже сертифицированы, а вам надо искать контору.
Во-первых речь шла о небольших проектах. Обычно к ним никто не приезжает.
Во-вторых например в России насколько я знаю перс данные надо хранить в России, серверов у амазона там нету. Так что получится наоборот сложнее.
Может быть, иногда имеет смысл приобрести какие-то новые знания и опыт с новыми технологиями, а не использовать старые пока работает, а потом вдруг обнаружить себя отставшим от паровоза?
Создавать облачную инфраструктуру когда вы ней не понимаете и когда она вам ненужна по-моему такая себе идея. А развиваться всегда полезно, но если при старте комерческого проекта вы хотите просто поизучать что-то то думаю у проекта немаленький шанс вылететь в трубу.
Во-первых, как вы узнаете, нужна она вам или нет, если вы ничего в ней не понимаете? А во-вторых, закупить оборудование при старте коммерческого проекта, когда у вас нет четких данных о нагрузке, технологиях, архитектуре и сроках проекта еще более "такая себе идея".
А экспертиза в облачной инфраструктуре - это просто часть ее стоимости. Нанять человека с опытом в облаках можно, можно отправить на курсы имеющихся админов.
На стадии "налабал формочки + базу" != нанял разработчика ?
На стадии "разработчик знает где разместить код" != сервер, vps, shared ?
Вы уж простите, но мне кажется ключевое здесь "старому разработчику" =)
Современный c# знает, что у него есть ажур, там у него есть бесплатный акк с лимитами в который его visual studio фигачит прям не вставая с дивана.
Самое клевое и забавное в этом то, что так реально проще и дешевле и быстрее.
Потом сложнее, но зато потом могут появится деньги на тех кто разгребет этот бред. А если не появятся - дак и хрен с ним.
Тридцать команд многовато. А если заюзать какой-нить ансибл, тем более плейбуков на любой вкус и цвет.
Для наколенного проекта ваш подход может и будет работать, но вот когда у вас эти проекты будут по 7 штук в неделю начинаться и заканчиваться, причем в разных странах и с разными стеками, вот тогда вы без Амазона загнетесь.
А предсказуемость затрат на амазоне куда лучше, чем на собственном сервере. Потому что там можно посчитать (там выше говорили, что кто-то с калькулятором считал, но это только справочно, нормально считать надо уметь на мониторинге), сколько вы условно платите за действие пользователя, и сколько вам это действие приносит. На своем вы так посчитать не сможете, потому что стоимость действия пользователя у вас будет нелинейно зависеть от количества пользователей.
Впрочем, я знаю много людей, которые вместо того, чтобы разбираться и оптимизировать сервисы, просто докупают мощностей. Таким глубокая кастомизация не нужна. Ну, тоже подход. Но не мой.
Да, у вас есть сервера с платой X в месяц, независимо от того, приносит деньги ваш проект или нет.
И вы кривите душой, говоря, что можете всё настроить. Вы должны все сами настроить, никто не сделает это за вас, как в облаках. И тут вам или нужно очень много всего уметь, и тогда ваш довод, что облака надо изучать, звучит странновато. Или вы настроите все кое-как и работать оно будет хреново.
Может разные представления о стартапах?
Для стартапа нормально ожидать, что вот сейчас что-то случится (кто-то где-то прорекламирует, например), и произойдет хабраэффект. Нагрузка вырастет не два раза, а в 20.
В облаке Scale Set отработает автоматически, добавит производительности, когда надо, уберет лишнюю, когда не надо...
А в условном Хетцнере вы, с вашим опытом, может и настроите такое руками. Но обычному стартапу с облаками реально проще.
Причем речь ведь не только о том, чтобы поднять еще один VPS с очередным веб сервером. Те же базы данных:
Variable workloads
You're running a lightly-used application, with peaks of 30 minutes to several hours a few times each day or several times per year, such as a human resources, budgeting, or operational reporting application. Now, you no longer have to provision to peak capacity, which would require you to pay for resources you don't continuously use, or to average capacity, which would risk performance problems and a poor user experience.
Unpredictable workloads
You're running workloads with database usage throughout the day, and also peaks of activity that are hard to predict - for example, a traffic site that might see a surge of activity when it starts raining. Now, your database will auto-scale capacity to meet the needs of the application's peak load and scale back down when the surge of activity is over.
Scaled-out databases split across multiple servers
Customers with high write or read requirements often split databases across several instances to achieve higher throughput. However, customers often provision too many or too few instances, increasing cost or limiting scale. With Aurora Serverless v2 (Preview), customers split databases across several Aurora instances and let the service adjust capacity instantly and automatically based on need. It seamlessly adjusts capacity for each node with no downtime or disruption, and uses just the right amount of capacity needed to support applications.
Стартап - это очень про непредсказуемость. Сомневаюсь, что на обычных VPSках сразу такая архитектура закладывается. А тут из коробки, достаточно совсем немного подумать заранее. Конечно, все можно испоганить, но в облаке восползоваться готовыми решениями проще, чем накручивать самому заранаее, не будучи уверенным, что это вообще взлетит и понадобится.
И нет, я не агитирую идти в облака :) Но определенные преимущества у них есть.
Мне, кстати, пришла в голову метафора - были телемастера, офигенно важные люди. Ну и где они сейчас... Конечно им обидно, что их профессионализм стал гораздо меньше востребован, и высокие зарплаты платят не им. При этом кому-то хорошо, что отпала нужда чинить всякие телефизоры и прочую электронику, проще заменить блок или даже устройство целиком. А кто-то бьется в кровь с условным Эпплом за право поменять аккумулятор в наушнике.
Как бы меня ни бесила тенденция все утаскивать в облако, везде навязывать сервисную модель вместо "купил навсегда", есть тенденции бизнеса. И облака надо учить...
P.S. По вашей цитате ниже:
Я говорил, что используя облака, вы теряете гибкость и контроль над своим проектом. Вы его контролируете ровно на столько, на сколько позволяет это панель управления.
Я уже на первых этапах знакомства с облаками начал смотреть на CLI. И мои подзрения подтвердились. В Web-интерфейсе доступно гораздо меньше параметром, чем в CLI. Так что даже простые вещи типа быстренько создать vnet для лабы стараюсь не "накликивать". Да вы и сами прекрасно знаете про Infrastructure as a Code, ну какая панель в продуктиве...
А уж когда мне довелось посмотреть, как чувак по памяти на powershell отлаживает Azure, я в очередной раз убедился, что фнукциональность определяется не "панелью управления", а знаниями и навыками. Не вижу особой разницы от "поставить LAMP и покрутить кучу настроек". В код ни стартап, ни Роснефть не поелезет.
Ну и до кучи - здесь чувак сам смотрел настройки и дебаги всего. В обычной организации я не представляю сколько народу ему пришлось бы привлечь. И сетевики (в т.ч. из разных регионов - часовых поясов), и безопасники, и прикладники...
Амазон выложил опенсорсный движок лямбд для запуска легковесных виртуальных машин
Где можно посмотреть?
А вот сейчас все таки порешил, что «а нафиг»? У клиента есть API через который он может получить доступ ко всем своим данным. Хочет как-то их обрабатывать сразу же после того, как посетитель оформил заказ? Отлично! Я просто дергаю веб-хук, посылаю HTTP запрос на его сервер, а дальше он там сам у себя пусть как хочет делает это.
Плюсы:
— Серверная часть простая, унифицированная и безопасная. Одна строчка кода на HTTP запрос.
— Клиент (человек, программист) может использовать сколь угодно сложные вычисления, сколько хочет процессоров и памяти и времени.
— Эти ресурсы клиент может покупать у любого провайдера по выбору, виртуалки или физические машины, или из офиса, или на домашнем старом ноуте запустить.
— Клиент может писать и развивать свой код так, как ему хочется, на любых языках программирования, хоть даже самых экзотических.
— Система контроля версий, бэкапы, откаты итд — да пожалуйста, как вам удобно — так и делайте.
Лямбды нужны в первую очередь тем, кто это хочет эти лямбды продавать, как амазон. (а так как я не планирую продавать процессорное время для лямбд — в моем проекте моим клиентам это и не нужно). Во-вторых — может быть где-то кому-то все таки нужны… лямбда, наверное, исполняется чуть ближе к данным, может быть чуть быстрее. Но скорее всего эти преимущества не так уж велики и не так уж важны в большинстве случаев.
Многое встает на места, если представлять облако, как глобальный логический "мейнфрейм". У мейнфремов по объективным причинам исторически не сложилось с отвязкой софта от платформы, поэтому до сих пор 50 млрд. финансовых транзакций в день обрабатывается на иерархической СУБД 1968 года выпуска на "железе" того же производителя. Несмотря на круг децентрализации, переходов на открытые системы и клиент-сервер. Пока глобальных "мейнфреймов" несколько, они старательно делят рынок, огораживая своих клиентов, посмотрим, во что это выльется.
Если нужна редкая, ресурсоемкая операция, требующая хитрых манипуляций, лямбда — то, что надо.
НЕТ! Прям кажется, что амазоновскую аттестацию этот чувак так и не прошел.
Если вам нужна ресурсоемкая, требующая хитрых манипуляций операция, то лямбда вам прямо-таки противопоказана, со всеми ее лимитами и огромной ценой за RAM/CPU.
Лямбда вам нужна для частых (но можно и редких), быстрых, простых операций, желательно работающих с другими ресурсами амазона.
Для редких ресурсоемких лучше spot-ы использовать тогда уж.
Кроме того, со временем лямбды поддерживают все больше CPU и памяти, также растет размер локального /tmp — так что они уже начинают поддавливать снизу контейнеры, если нужно посчитать что-то не очень большое и долгое.
— У тебя было такое: долго мучает боль в профессии, и вдруг выходит инструмент, который её побеждает?
У меня так было с Puppet, да и с Ansible. Docker снял много боли - изоляция избавила от зависимостей на хосте.
Serverless глазами инженера: “используешь, перестаешь программировать, становишься оператором Амазона”