Это уже к вопросу о фундаментальных знаниях: алгоритмы, устройство компьютера и тд. Обычно то, что дается в хороших универах на начальных курсах. Соответственно, когда человек приходит из другой профессии(или после школы например), то как правило этих знаний нет и появляется сильный пробел, когда он начинает писать программы, зная только синтаксис. Тут мне кажется можно вообще отдельную статью сделать на эту тему.
Инвесторы далеко не глупые люди. Когда вкладывают в 10-20 проектов(даже не столько проект, сколько люди в команде), то нет мнимых ожиданий что все проекты взлетят. Но это безусловно не отменяет ответственности автора. Хорошо то, что делаются выводы. А это в свою очередь позволит уберечь будущие деньги инвесторов. И у инвесторов больше интереса к тем, кто уже проваливал проекты и терял деньги.
Так и есть. Но на мой взгляд, лучше делать попытки и выглядеть «глупо», чем «красиво» ничего не пытаться. Как часто бывает: cегодня ты выглядишь глупо, через год начинают обращать внимание, а через 2 года восхваляют.
Я не автор, но добавлю от себя.
Минусы у такого подхода есть, поэтому если проект маленький, то особых преимуществ не получите. НО по мере того как система будет разрастаться, вы начнете сталкиваться с типичными проблемами монолита:
— тяжелое или практически невозможное горизонтальное масштабирование
— много конфликтов при работе нескольких команд
— ci/cd для отдельных компонентов
и список можно дальше перечислять.
Много компаний уже пришли к тому, что с имеющимися монолитами очень тяжело дальше жить и всячески пытаются переходить на микросервисную архитектуру.
Хотелось было бы конечно узнать большей деталей, слишком поверхностно с технической точки зрения. С точки зрения среднестатистического болельщика, вполне интересно посмотреть на циферки)
Минусы у такого подхода есть, поэтому если проект маленький, то особых преимуществ не получите. НО по мере того как система будет разрастаться, вы начнете сталкиваться с типичными проблемами монолита:
— тяжелое или практически невозможное горизонтальное масштабирование
— много конфликтов при работе нескольких команд
— ci/cd для отдельных компонентов
и список можно дальше перечислять.
Много компаний уже пришли к тому, что с имеющимися монолитами очень тяжело дальше жить и всячески пытаются переходить на микросервисную архитектуру.
Можете статью Фаулера почитать, почему такой подход появился
martinfowler.com/articles/microservices.html