Еще одна сервисная контора которая быстро внедрила и поддержкой заниматься не будет. Зато, когда требования выставляются, так сразу осуждения - "у вас херово, а с нас требуете". У местных это называется тех долг(тот компромисс на который пошли что бы реализовать, то что бизнес хочет здесь и сейчас), а у вас контракт и должны сделать все по стандарту.
От сюда все негодования, что ущемляют и тп. Видел такое и не раз, потом приходилось это все поддерживать и в итоге переписывать, что бы хоть как то это можно было развивать.
Да, Вы все правильно говорите — нужно комплексно подходить и подкручивать только там где необходимо и понимать зачем крутишь.
Не скажите… время на поднятие инстанса иногда то же очень важно.
Важности не отрицаю, но разница в 10 секунд не критичная. Приложение редко перезапускаем, а если и перезапускаем всегда есть еще как минимум одно плечо, которое возьмет на себя нагрузку.
Но а то что в статье описано — это вообще прямого отношения к SpringBoot не имеет
За автора отвечать не буду, но выглядит так, что автор хотел показать что вообще можно сделать и Spring тут как каркас, который сейчас очень(ну прям очень) много где используется. Да это и не плохо.
Думаю, статья имеет право на жизнь. Да она будет не очень полезна продвинутым разработчикам, но ребятам у кого не было опыта — покажет какие инструменты есть и надеюсь они пойдут читать как это все работает, что бы осознанно тюнить свое приложение
так тут фишка не в том что бы уменьшить время для «готов принимать HTTP», а время на обработку запросов. И статья, как сделать пару тривиальных действий и можно улучшить перфоманс.
Как по мне не очень критично сколько грузится сервис — 4 сек или 10. Зато профита больше(как минимум поддерживать проще проект будет)
Симки дорого, но может можно купить аккаунты или виртуальные номера — для получения одноразового кода регистрации(первый попавшийся магазин предлагает 1 рубль за номер на 20 минут)
Плюс можно по логину можно искать в социалках — думаю совпадений будет довольно много
Наказать кого то хорошо, а с фейлом что делать?
Если образовалась дыра, ее нужно закрыть, а уже потом думать, что можно сделать что бы такого не случилось.
по сути моки меняем на фактически реальную реализацию сервера к которому обращаемся, да ничего особенно делать не нужно сервер запросы проксировал и сохранил, но еще встает вопрос управления файлами, которых как я понимаю будет не мало, для всего api.
Свой фреймворк конечно хорошо, если он не едет дальше по другим отделам вдохновленных вашим успехом. Вот тут начинается головная боль и у тех кто использует, и у тех кто поддерживает
Порпробую ответить — золотой середины нет, team lead должен сам решать когда и сколько тратить времени на коммуникации пологаясь только на свой опыт и требования проекта.
А цифры 60%, может 50% это цифры из теории очень среднего проекта и с реальностью переодически расходятся, хотя наверное если считать большими перодами 2 -3 года, то будет похоже на правду.
С такой стороный не смотрел на эту проблему, но это могло бы работать в идельном мире. Но таже Vmware не публикует свой код в GPL, а сколько небольших компаний юзают либы и не публикуют свой код.
Там все не просто с лицензиями..., мысль отличная, нужно подумать над ней. Но в риалиях современного мира, я видел когда софт в оборонку поставляется с нарушением лицензий, в военских частях стоят откровенной пиратский софт.
Монолит монолиту рознь. Монолит может быт на какойнить не очень популярной технологии которая досталась нам от внешнего вендора, плюс нужно учитывать такие факторы, как текучка, за пару лет на неочень преспективных проектах комнада может поменятся полностью и уже новая команда будет долго разбиратся с новым стеком и тогда стоимость потдержки будет расти.
Монолиты так же живут хорошо в облаках, ток стоит это других денег, а Микросервисы это не вынужденый архитектурный стиль, микросервисы хорошо маштабируются и не нужно перепрлачивать за серверное железо, позволяют более грамотно утилизировать ресурсы.(это частный случай)
А про облака и тп — это наверное уже про стоимость владения, которая складывается не только из поддержки, но сервера, лицензии и обновления — и это может быть дороже чем содержать команду и расчитывается она не на один год, а на период(года).
Причин что бы команда развалилась наверное было множество, а вот такая выходка послужила поводом. если человека/команду все устраивает в процесе, то они никуда так сразу не сорвутся. Программист понимает, что он делает то что не многие смогут оценить, работа есть работа. Да бывает не очень приятно
Архитектура — это же ведь не только про компоновку компонентов, но и про развертывание, и про поддержку и тестирование. При выборе архитектуры нужно учитывать не только плюсы той или иной архитектуры, но и риски, и проблемы с которыми можем столкнутся и тп.
Если при проектировании были учтены все эти факторы и была выбрана подходящая архитектура для проекта, которая решает задачи проекта, то и поддержка, тестирование, разработка не будут вызывать боль.
Надо будет прогонять бизнес тестирование что для монолита, что для маленького сервиса — по трудозатратам выходит одинаково. А функционально проверить изменения и в монолите можно если это не спагетти код.
Плюс спорный вопрос, что тестить проще. Если монолит целиком переписать и потом его тестировать — то ну его нафиг, так вообще не полетит. А если сделать roadmap для переезда на новую платформу(ради чего мы переписываем), то изменения можно будет да же под бизнесовыми задачам провести и протестировать.
Тут наверное вопрос к спеке, микросервисы должны упрощать работу, если нужна информация по пользователю.
У сервиса должно быть понятное API — если нет, то это боль которая превращает наши сервисы еще в больший комок грязи.
И если мы интегрируемся с сервисами, мы должны знать только контракт и особо разбираться что там под капотом происходит нет смысла.
По поводу количества людей на проекте, думаю это не корректно — по человеку на сервис, небольшая команда может пилить и 100 сервисов, нужна только хорошая документация, выстроенный процесс. Сервисы не очень большие и после разработки все разом не очень часто меняются.
А вы то батенька кто такой?
Еще одна сервисная контора которая быстро внедрила и поддержкой заниматься не будет. Зато, когда требования выставляются, так сразу осуждения - "у вас херово, а с нас требуете". У местных это называется тех долг(тот компромисс на который пошли что бы реализовать, то что бизнес хочет здесь и сейчас), а у вас контракт и должны сделать все по стандарту.
От сюда все негодования, что ущемляют и тп. Видел такое и не раз, потом приходилось это все поддерживать и в итоге переписывать, что бы хоть как то это можно было развивать.
Про синдром самозванца не очень тема раскрыта, а вот пробежатся по курсу было круто. Спасибо!
Важности не отрицаю, но разница в 10 секунд не критичная. Приложение редко перезапускаем, а если и перезапускаем всегда есть еще как минимум одно плечо, которое возьмет на себя нагрузку.
За автора отвечать не буду, но выглядит так, что автор хотел показать что вообще можно сделать и Spring тут как каркас, который сейчас очень(ну прям очень) много где используется. Да это и не плохо.
Думаю, статья имеет право на жизнь. Да она будет не очень полезна продвинутым разработчикам, но ребятам у кого не было опыта — покажет какие инструменты есть и надеюсь они пойдут читать как это все работает, что бы осознанно тюнить свое приложение
Как по мне не очень критично сколько грузится сервис — 4 сек или 10. Зато профита больше(как минимум поддерживать проще проект будет)
Плюс можно по логину можно искать в социалках — думаю совпадений будет довольно много
Если образовалась дыра, ее нужно закрыть, а уже потом думать, что можно сделать что бы такого не случилось.
А чем это лучше MokMvc?
А цифры 60%, может 50% это цифры из теории очень среднего проекта и с реальностью переодически расходятся, хотя наверное если считать большими перодами 2 -3 года, то будет похоже на правду.
Там все не просто с лицензиями..., мысль отличная, нужно подумать над ней. Но в риалиях современного мира, я видел когда софт в оборонку поставляется с нарушением лицензий, в военских частях стоят откровенной пиратский софт.
Монолиты так же живут хорошо в облаках, ток стоит это других денег, а Микросервисы это не вынужденый архитектурный стиль, микросервисы хорошо маштабируются и не нужно перепрлачивать за серверное железо, позволяют более грамотно утилизировать ресурсы.(это частный случай)
А про облака и тп — это наверное уже про стоимость владения, которая складывается не только из поддержки, но сервера, лицензии и обновления — и это может быть дороже чем содержать команду и расчитывается она не на один год, а на период(года).
Причин что бы команда развалилась наверное было множество, а вот такая выходка послужила поводом. если человека/команду все устраивает в процесе, то они никуда так сразу не сорвутся. Программист понимает, что он делает то что не многие смогут оценить, работа есть работа. Да бывает не очень приятно
Если при проектировании были учтены все эти факторы и была выбрана подходящая архитектура для проекта, которая решает задачи проекта, то и поддержка, тестирование, разработка не будут вызывать боль.
Плюс спорный вопрос, что тестить проще. Если монолит целиком переписать и потом его тестировать — то ну его нафиг, так вообще не полетит. А если сделать roadmap для переезда на новую платформу(ради чего мы переписываем), то изменения можно будет да же под бизнесовыми задачам провести и протестировать.
У сервиса должно быть понятное API — если нет, то это боль которая превращает наши сервисы еще в больший комок грязи.
И если мы интегрируемся с сервисами, мы должны знать только контракт и особо разбираться что там под капотом происходит нет смысла.
По поводу количества людей на проекте, думаю это не корректно — по человеку на сервис, небольшая команда может пилить и 100 сервисов, нужна только хорошая документация, выстроенный процесс. Сервисы не очень большие и после разработки все разом не очень часто меняются.