Количество разрабов не говорит ни о чём. Они же не один продукт делают все вместе. Вполне может быть так, что есть какой-нибудь большой монолит на десятки или сотни человек, а рядом команды по два-три человека, которые делают крохотные приложения со специфичными задачами. Вот это хорошее приложение для микросервисов. В конце концов, микросервисы - это скорее про организацию работы, а не про архитектуру. Т.е. это в большей степени административная вещь.
Так и не понял, в чем беда микросервисов и выгода монолита?
В статье не рассматриваются плюсы и минусы микросервисов. Её мысль: хватит пихать микросервисы куда ни попадя, где надо и где не надо. Это не панацея, это инструмент для решения специфичных проблем в специфичных условиях. Как и любой другой инструмент.
Беда не в микросервисах как таковых, а в хайпе вокруг них. Так происходит с каждой технологией, до которой добираются маркетологи и начинают её продавать с пеной у рта, обещая решить все проблемы бизнеса, а заодно накормить голодающих в Африке и вылечить рак. Так было с микросервисами, так было с 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` — на один символ назад.
Количество разрабов не говорит ни о чём. Они же не один продукт делают все вместе. Вполне может быть так, что есть какой-нибудь большой монолит на десятки или сотни человек, а рядом команды по два-три человека, которые делают крохотные приложения со специфичными задачами. Вот это хорошее приложение для микросервисов. В конце концов, микросервисы - это скорее про организацию работы, а не про архитектуру. Т.е. это в большей степени административная вещь.
В статье не рассматриваются плюсы и минусы микросервисов. Её мысль: хватит пихать микросервисы куда ни попадя, где надо и где не надо. Это не панацея, это инструмент для решения специфичных проблем в специфичных условиях. Как и любой другой инструмент.
Беда не в микросервисах как таковых, а в хайпе вокруг них. Так происходит с каждой технологией, до которой добираются маркетологи и начинают её продавать с пеной у рта, обещая решить все проблемы бизнеса, а заодно накормить голодающих в Африке и вылечить рак. Так было с микросервисами, так было с 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.