S>Кто-нибудь проводил примерный рассчет, когда Cloud Functions имеет смысл а когда нет?
IMHO, Cloud Functions/Lambda/ServerLess — это по функциональности shared hosting. Просто посмотри, сможет ли Shared Hosting решить твою задачу и сколько это будет стоить (денег и времени).
Здравствуйте, Shmj, Вы писали:
S>Кто-нибудь проводил примерный рассчет, когда Cloud Functions имеет смысл а когда нет?
Я примерно так это вижу. Это в принципе касается всех облачных фишек.
1. Минимальная стоимость. Если у тебя проект в стадии разработки или начальной эксплуатации, то облако вероятно будет бесплатным. Скажем в яндекс облаке конкретно по cloud functions ты будешь иметь примерно 20 рублей в месяц бесплатных. БД — 40 рублей и так далее. Это, конечно, ерунда, но с какой-то точки зрения приятно иметь возможность запускать проект, на который не будут тратиться деньги. VPS деньги жрать будет всегда, вроде и немного, но копейка рубль бережёт.
2. Автоматическая масштабируемость. VPS тут в пролёте. Если проект внезапно стал популярным, то облако позволит его хорошо масштабировать, без облака будет очень неудобно. Плюс — масштабируемость почасовая. К примеру на текущей работе у нас ровно эта проблема: с ростом системы стали не справляться серверы, приходится их всё время апгрейдить. При этом используется он исключительно в рабочие дни с 9 до 18, в остальное время нагрузка около-нулевая. Поэтому на текущем этапе есть желание мигрировать в облако, правда самодельное на кубернетесе, но в основном из-за того, что для нас критично хранение данных в Казахстане, а этого никто из популярных облаков не даёт.
Т.е. до определённого момента завязываться на облако хорошо и правильно, это позволит тратить меньше денег на инфрастуктурные расходы. Помимо прочего администрирование своих инсталляций это достаточно нетривиально.
По моим наблюдениям начиная с какого-то масштаба компании уже начинают брать под контроль всё это, нанимают специальных админов и тд. И там от облака нужно только масштабирование виртуальных серверов, а что внутри них крутится — уже обычно что-то вроде кубернетеса и тд, т.е. происходит процесс отвязки от облака, помимо прочего это позволит при необходимости переехать на другое облако, линукс везде одинаковый.
Лично для себя я так это сформулировал:
1. Облаками пользоваться надо, VPS и тем более свои серверы это технологии прошлого века.
2. Если проект не предполагается на вырост, то можно завязываться на проприетарные API облака. Но надо помнить, что всегда остаётся опасность, что вас по какой-то причине выкинут из облака и придётся искать другое облако и эта завязка на API может стать проблемой.
3. В целом лучше не завязываться, а использовать максимально нейтральные технологии. Взять тот же cloud functions. Ты можешь писать функцию с API яндекса, а можешь написать просто http-сервер, который стартует, начинает слушать указанный порт и обрабатывать запросы. И то и другое будет в облаке работать примерно одинаково, но второй вариант ты всегда можешь запустить хоть на том же VPS, а первый — нет. Или другой пример — протокол S3, у которого есть куча реализаций.
4. В некоторых моментах вероятно придётся завязаться, например в базе данных. Это проблема, да. Но БД это слишком специфичная штука, чтобы её можно было на ходу менять. Тут у меня хорошего решения нет. Да, можно managed postgres использовать, но преимущества по-настоящему облачной БД в масштабируемости очевидны, а БД это то, что чаще всего ограничивает масштабируемость. Ну в любом случае если завязываться и придётся, то лучше минимизировать эти точки. Принципы проектирования программ никто не отменял — делите их на слои, абстрагируйте доступ к данным и тд.
Здравствуйте, vsb, Вы писали:
vsb>4. В некоторых моментах вероятно придётся завязаться, например в базе данных. Это проблема, да. Но БД это слишком специфичная штука, чтобы её можно было на ходу менять. Тут у меня хорошего решения нет. Да, можно managed postgres использовать, но преимущества по-настоящему облачной БД в масштабируемости очевидны, а БД это то, что чаще всего ограничивает масштабируемость. Ну в любом случае если завязываться и придётся, то лучше минимизировать эти точки. Принципы проектирования программ никто не отменял — делите их на слои, абстрагируйте доступ к данным и тд.
В AWS есть Aurora Serverless, мускуль или постгрес как автоматически масштабирующаяся реляционка. Интерфейс совместим с обычной базой, но есть свой новомодный где не требуется следить за соединениями, а всё сведено к "послал SQL — получил результат".
Здравствуйте, vsb, Вы писали:
vsb>По моим наблюдениям начиная с какого-то масштаба компании уже начинают брать под контроль всё это, нанимают специальных админов и тд. Apple недостаточно большая еще? https://www.turningcloud.com/blog/apple-uses-aws/
УПД вобщем да EC2 самая большая часть у всех. Хотя и остальные сервисы используются.
Здравствуйте, GarryIV, Вы писали:
vsb>>По моим наблюдениям начиная с какого-то масштаба компании уже начинают брать под контроль всё это, нанимают специальных админов и тд. GIV>Apple недостаточно большая еще? GIV>https://www.turningcloud.com/blog/apple-uses-aws/
Здравствуйте, vsb, Вы писали:
vsb>>>По моим наблюдениям начиная с какого-то масштаба компании уже начинают брать под контроль всё это, нанимают специальных админов и тд. GIV>>Apple недостаточно большая еще? GIV>>https://www.turningcloud.com/blog/apple-uses-aws/
vsb>Вроде у Apple есть свои ЦОДы.
хз про объемы расходов Apple на свои датацентры я не знаю.
