Если что-то лежит, то налицо другая проблема, не связанная с архитектурой. Отказоустойчивость, высокая доступность, балансировка нагрузки - это отдельная дисциплина, в которую умеют сисадмины, но часто, увы, не умеют разработчики (хотя концепция DevOps и стремится обучить разработчиков самих поддерживать свои продукты)
Вдобавок, пользователи обычно привередливы, им не нужен продукт, работающий на 99%. Им нужен продукт, просто работающий. Если работает 9 микросервисов из 10, но лежит отвечающий за аутентификацию - продукт бесполезен, ибо пользователь просто не залогинится. Если лежит отвечающий за кеширование - продукт бесполезен, ибо пользователю надоест долго ждать ответа от сервиса, он плюнет и уйдёт. И т.д.
Продукт - это система, она должна работать вся целиком, чтобы приносить пользу.
За RoR ничего не скажу, потому как вопрос "микросервисы или монолит" к веб-фреймворку как-то слабо применим.
Фреймворк часто диктует архитектуру. Для PoC или MVP монолиты идеальны. Да, потом их можно разобрать на кусочки или даже в рамках того же монолита всё переделать так, что от изначального стиля фреймворка ничего не останется. Но изначально рельсы поощряют именно монолит.
Basecamp is a small team. As I mentioned, we have just 12 programmers
Хороший пример того, чего можно добиться, когда люди занимаются делом, а не жонглируют микросервисами в kubernetes :)
Basecamp действительно не показатель. Есть другие примеры рельсовых монолитов: github, spree, shopify. Кто-то потом ушёл в SOA, кто-то вообще в другие языки, а кто-то остался на рельсах и монолите. Яркий пример сейчас - gitlab: https://about.gitlab.com/company/history/.
Количество разрабов не говорит ни о чём. Они же не один продукт делают все вместе. Вполне может быть так, что есть какой-нибудь большой монолит на десятки или сотни человек, а рядом команды по два-три человека, которые делают крохотные приложения со специфичными задачами. Вот это хорошее приложение для микросервисов. В конце концов, микросервисы - это скорее про организацию работы, а не про архитектуру. Т.е. это в большей степени административная вещь.
Так и не понял, в чем беда микросервисов и выгода монолита?
В статье не рассматриваются плюсы и минусы микросервисов. Её мысль: хватит пихать микросервисы куда ни попадя, где надо и где не надо. Это не панацея, это инструмент для решения специфичных проблем в специфичных условиях. Как и любой другой инструмент.
Беда не в микросервисах как таковых, а в хайпе вокруг них. Так происходит с каждой технологией, до которой добираются маркетологи и начинают её продавать с пеной у рта, обещая решить все проблемы бизнеса, а заодно накормить голодающих в Африке и вылечить рак. Так было с микросервисами, так было с GraphQL, с NoSQL, с Elixir и так далее.
Как видели микросервисы опытные люди ещё в самом начале хайпа, можно почитать вот здесь, например: https://martinfowler.com/articles/microservices.html. Разумеется, прошедшие 10 лет дали больше пищи для размышления, но выводы верны до сих пор:
One reasonable argument we've heard is that you shouldn't start with a microservices architecture. Instead begin with a monolith, keep it modular, and split it into microservices once the monolith becomes a problem.
иихо самое глупое - это обвинять в ошибках проектирования архитектурный паттерн.
Если разработчик (а ещё лучше - тот, кто ставит ему задачи, вплоть до владельца бизнеса) понимает, что продукт нужно проектировать, то такой проблемы и не возникнет.
Прям вот ни капли не сомневаюсь, что у автора есть опыт поддержания монолитного сервиса, скажем так, с 60 разработчиками и 3кк строками кода в состоянии "согласованной команды и приложения".
Правильно делаете, ведь автор - создатель Ruby on Rails, basecamp.com и hey.com. Опыта работы с монолитами и командами для их создания у него больше, чем чуть менее чем у всех комментаторов на хабре
Тогда и Маяковского читать незачем, ведь у него словотворчество сплошь и рядом. А здесь безобиднее, автор ничего не выдумывал, а использовал широко известные мемы.
Олбанский тем и хорош, что он демонстративно искорёжен, так что его легко отличить от безграмотности. Например, "ниасилил" или "превед". Но никогда "подскажыте" или "в крации". Это - просто безграмотность.
Нет, совсем без даунтайма не обязательно. 5-10 минут может быть допустимо, часы - вряд ли. Речь о том, что обкатанные, проверенные временем быстрые способы типа `pg_upgrade --link` легко и просто работают на машинах. Но в контейнерах (а ещё лучше в кубе) это превращается в упражнения, без которых лучше бы обойтись. При этом проблема даже не в контейнерах как таковых: если данные хранятся локально, то контейнеры бесплатны с т.з. производительности (но не когнитивной нагрузки). Проблема в докере и его PID 1. С тем же LXC сложностей нет.
Поэтому я бы десять раз подумал, прежде чем применять докер для stateful нагрузок вообще и баз в частности.
Обновить версию докеризированной субд становится в разы проще.
Вы пробовали? Хотя бы постгрес. Хотя бы между соседними версиями. Допустим, 11 -> 12. Можно даже не слишком большую, гиг на 300. Просто чтобы pg_dump/pg_restore стал слишком долгим для использования в продакшене, где даунтайм имеет значение.
Следование этому пути делает традиционные CI-системы ненужными в рамках процесса разработки. Промежуточные звенья, такие как коммиты в удаленные Git-репозитории, сборочные машины, хранилище контейнеров (container registry) и так далее, больше не требуются
Следующий шаг - убрать лишние сущности типа Kubernetes и Syncthing и загружать код прямо на машины. Например, по FTP. Это делает традиционные CI-системы ненужными и обеспечивает просто феноменальную скорость работы. А в веб-разработке можно пойти и дальше и встраивать исполняемый код прямо в HTML страницы. Исключительно для удобства.
Командная оболочка Bash хороша, но когда дело доходит до написания скриптов, люди часто выбирают более удобный язык программирования
Да
и JavaScript прекрасно для этого подходит.
Да, если знаешь только JavaScript. Сделать выбор из одного варианта несложно. Если же знаешь что-то ещё - однозначно нет.
Шелл-скрипты предназначены для того, чтобы быть клеем между остальными утилитами. Именно так их и следует использовать. По мере появления более сложных задач появляются и другие языки, более сложные и с разным предназначением: от обработки текста до полноценного ООП. Это awk, perl, ruby, python.
Пожалуйста, используйте JavaScript в той области, для которой он создан - для выполнения скриптов в браузере. Все остальные задачи решаются более подходящими инструментами.
В статье я расскажу, как с помощью PaaS-инструментов упростить и ускорить разработку микросервисов так, чтобы в конечном счёте на создание полноценного продукта у вас уходило не больше 15 минут.
Никак. Потому что микросервисы - это про интерфейсы. То, о чём можно не задумываться в POC/MVP монолита, а именно проектирование модулей и интерфейсов, в случае микросервисов нужно делать заранее, до начала разработки. А проектирование (или архитектура, если угодно) требует времени на то, чтобы думать. Собственно код (и уже тем более инфра) вторичны.
Это совсем не так. Во-первых, на главной гитхаба есть блок "Our response to the war in Ukraine". Но если это можно списать на разговоры, то в плане действий гитхаб тоже был одним из первых: он забанил всех, кто заходил с крымских айпишников, ещё в 2014 году. Причём не логин, который бы можно было обойти через VPN, а именно аккаунты. Конкретно - платные услуги для аккаунтов, в число которых входили любые приватные репы (даже стандарные 2 штуки на бесплатном аккаунте). Поэтому те, кто поверил, что гитхаб вне политики, в один прекрасный день обнаружил, что не имеет доступа к собственным репам и даже не может их забрать с гитхаба, не сделав их сперва публичными.
> 20 лет администрирую никсы, 20 лет не использую в bash/zsh и ко ctrl+a или ctrl+b. В начало строки я возвращаюсь чудесным образом кнопкой Home, на один символ назад я думаю угадаете как.
Искренне за Вас рад.
> Использование emacs-режима может быть интересно только существам с 17 щупальцами, которые могут использовать и сам emacs, а я — классический гуманоид, у меня две руки на которых по пять пальцев.
Т.е. Вы ничего не знаете о emacs.
Оба плохи. В стандартном емакс-подобном режиме, т.е. в дефолтном режиме оболочек (как bash, так и zsh) `ctrl+a` — переход в начало строки, а `ctrl+b` — на один символ назад.
Если что-то лежит, то налицо другая проблема, не связанная с архитектурой. Отказоустойчивость, высокая доступность, балансировка нагрузки - это отдельная дисциплина, в которую умеют сисадмины, но часто, увы, не умеют разработчики (хотя концепция DevOps и стремится обучить разработчиков самих поддерживать свои продукты)
Вдобавок, пользователи обычно привередливы, им не нужен продукт, работающий на 99%. Им нужен продукт, просто работающий. Если работает 9 микросервисов из 10, но лежит отвечающий за аутентификацию - продукт бесполезен, ибо пользователь просто не залогинится. Если лежит отвечающий за кеширование - продукт бесполезен, ибо пользователю надоест долго ждать ответа от сервиса, он плюнет и уйдёт. И т.д.
Продукт - это система, она должна работать вся целиком, чтобы приносить пользу.
Вам известно, а кому-то нужно повторять снова и снова. Что автор и делает. По моему мнению, больше даже не для инженеров, а для бизнесменов.
Фреймворк часто диктует архитектуру. Для PoC или MVP монолиты идеальны. Да, потом их можно разобрать на кусочки или даже в рамках того же монолита всё переделать так, что от изначального стиля фреймворка ничего не останется. Но изначально рельсы поощряют именно монолит.
Хороший пример того, чего можно добиться, когда люди занимаются делом, а не жонглируют микросервисами в kubernetes :)
Basecamp действительно не показатель. Есть другие примеры рельсовых монолитов: github, spree, shopify. Кто-то потом ушёл в SOA, кто-то вообще в другие языки, а кто-то остался на рельсах и монолите. Яркий пример сейчас - gitlab: https://about.gitlab.com/company/history/.
Количество разрабов не говорит ни о чём. Они же не один продукт делают все вместе. Вполне может быть так, что есть какой-нибудь большой монолит на десятки или сотни человек, а рядом команды по два-три человека, которые делают крохотные приложения со специфичными задачами. Вот это хорошее приложение для микросервисов. В конце концов, микросервисы - это скорее про организацию работы, а не про архитектуру. Т.е. это в большей степени административная вещь.
В статье не рассматриваются плюсы и минусы микросервисов. Её мысль: хватит пихать микросервисы куда ни попадя, где надо и где не надо. Это не панацея, это инструмент для решения специфичных проблем в специфичных условиях. Как и любой другой инструмент.
Беда не в микросервисах как таковых, а в хайпе вокруг них. Так происходит с каждой технологией, до которой добираются маркетологи и начинают её продавать с пеной у рта, обещая решить все проблемы бизнеса, а заодно накормить голодающих в Африке и вылечить рак. Так было с микросервисами, так было с GraphQL, с NoSQL, с Elixir и так далее.
Как видели микросервисы опытные люди ещё в самом начале хайпа, можно почитать вот здесь, например: https://martinfowler.com/articles/microservices.html. Разумеется, прошедшие 10 лет дали больше пищи для размышления, но выводы верны до сих пор:
Если разработчик (а ещё лучше - тот, кто ставит ему задачи, вплоть до владельца бизнеса) понимает, что продукт нужно проектировать, то такой проблемы и не возникнет.
Правильно делаете, ведь автор - создатель Ruby on Rails, basecamp.com и hey.com. Опыта работы с монолитами и командами для их создания у него больше, чем чуть менее чем у всех комментаторов на хабре
Удивительное совпадение https://www.eia.gov/dnav/ng/hist/n9133us2M.htm
Тогда и Маяковского читать незачем, ведь у него словотворчество сплошь и рядом. А здесь безобиднее, автор ничего не выдумывал, а использовал широко известные мемы.
Олбанский тем и хорош, что он демонстративно искорёжен, так что его легко отличить от безграмотности. Например, "ниасилил" или "превед". Но никогда "подскажыте" или "в крации". Это - просто безграмотность.
Но причём тут NEOvim? Всё это есть в Vim из 1991 года, а многое - в Vi из 1976. Собственно,
vimtutorНет, совсем без даунтайма не обязательно. 5-10 минут может быть допустимо, часы - вряд ли. Речь о том, что обкатанные, проверенные временем быстрые способы типа `pg_upgrade --link` легко и просто работают на машинах. Но в контейнерах (а ещё лучше в кубе) это превращается в упражнения, без которых лучше бы обойтись. При этом проблема даже не в контейнерах как таковых: если данные хранятся локально, то контейнеры бесплатны с т.з. производительности (но не когнитивной нагрузки). Проблема в докере и его PID 1. С тем же LXC сложностей нет.
Поэтому я бы десять раз подумал, прежде чем применять докер для stateful нагрузок вообще и баз в частности.
Вы пробовали? Хотя бы постгрес. Хотя бы между соседними версиями. Допустим, 11 -> 12. Можно даже не слишком большую, гиг на 300. Просто чтобы pg_dump/pg_restore стал слишком долгим для использования в продакшене, где даунтайм имеет значение.
Следующий шаг - убрать лишние сущности типа Kubernetes и Syncthing и загружать код прямо на машины. Например, по FTP. Это делает традиционные CI-системы ненужными и обеспечивает просто феноменальную скорость работы. А в веб-разработке можно пойти и дальше и встраивать исполняемый код прямо в HTML страницы. Исключительно для удобства.
Финское правительство пошло туда, куда велено. Самих финнов-то никто не спрашивал и спрашивать не собирается: https://www.euractiv.com/section/politics/short_news/finnish-president-says-nato-referendum-no-longer-necessary/
Да
Да, если знаешь только JavaScript. Сделать выбор из одного варианта несложно. Если же знаешь что-то ещё - однозначно нет.
Шелл-скрипты предназначены для того, чтобы быть клеем между остальными утилитами. Именно так их и следует использовать. По мере появления более сложных задач появляются и другие языки, более сложные и с разным предназначением: от обработки текста до полноценного ООП. Это awk, perl, ruby, python.
Пожалуйста, используйте JavaScript в той области, для которой он создан - для выполнения скриптов в браузере. Все остальные задачи решаются более подходящими инструментами.
Никак. Потому что микросервисы - это про интерфейсы. То, о чём можно не задумываться в POC/MVP монолита, а именно проектирование модулей и интерфейсов, в случае микросервисов нужно делать заранее, до начала разработки. А проектирование (или архитектура, если угодно) требует времени на то, чтобы думать. Собственно код (и уже тем более инфра) вторичны.
Это совсем не так. Во-первых, на главной гитхаба есть блок "Our response to the war in Ukraine". Но если это можно списать на разговоры, то в плане действий гитхаб тоже был одним из первых: он забанил всех, кто заходил с крымских айпишников, ещё в 2014 году. Причём не логин, который бы можно было обойти через VPN, а именно аккаунты. Конкретно - платные услуги для аккаунтов, в число которых входили любые приватные репы (даже стандарные 2 штуки на бесплатном аккаунте). Поэтому те, кто поверил, что гитхаб вне политики, в один прекрасный день обнаружил, что не имеет доступа к собственным репам и даже не может их забрать с гитхаба, не сделав их сперва публичными.
Искренне за Вас рад.
> Использование emacs-режима может быть интересно только существам с 17 щупальцами, которые могут использовать и сам emacs, а я — классический гуманоид, у меня две руки на которых по пять пальцев.
Т.е. Вы ничего не знаете о emacs.