Поиграться, конечно, хорошо, если это происходит дома, или, в крайнем случае, на работе, если платят «будущими дивидендами от стартапа»…
И не поверю, что здесь ни у кого не было опыта сбора стартовавшего с микросервисов проекта в монолит, или перехода с модной NoSQL на реляционную СУБД, или переписывания реализованного, например, на GO (ничего не имею против этого ЯП) «прогрессивным» разработчиком микросервиса на родной для команды Kotlin или Java (в том случае, если не было объективной причины использовать GO на проекте, помимо желания разработчика)…
Автору, спасибо! Статья хорошая, ее можно дополнить книгой «Идеальный программист» Роберта Мартина.
И вы, комментаторы, все пишите красиво, правильно… Однако, потом, после очередного посещения модной конференции или прочтения хайповой статьи, начинаете бизнесу палки в колеса вставлять своими технологическими или архитектурными экспериментами, которые годятся только чтобы на собеседованиях хвастаться… То решите прототип для стартапа сразу с микросервисной архитектуры создавать, то соберетесь Kubernetes в проект из двух стабильных сервисов внедрять, то Big Data и Machine Learning на базу данных с парой тысяч строк натравить…
Для меня эти истины были понятны еще когда я только джуном устроился, потому что до этого много лет разным мелким бизнесом занимался. Но как такое понимание может взяться у разработчика, после получение образования Computer Science в институте, и даже нескольких лет работы?.. Только после того, как его назначат управленцем в бизнес — СТО
Увеличил шрифты, загрузил картинку большего размера, но Хабр не дает возможность увеличить ее в интерфейсе. Рекомендую загрузить эту картинку и увеличивать вручную. Она достаточно хорошего качества.
Спасибо за комментарий. Заголовок и содержание поправил, чтобы не вносить путаницу с Docker'ом, и показать, что статья — справочная диаграмма использования памяти Java процесса.
Спасибо за комментарий. Согласен, информация про Docker полезной нагрузки статье не добавляет и заголовок вводит в заблуждение. Исправил. OS также имеет возможность убить процесс, из-за потребления памяти и результат будет аналогичен моей истории с Docker.
Хаха, да такие случаи самые «веселые», когда идет разработка «многослойного» hardware + software продукта… :) И, на удивление, именно с таким случаем я сталкивался. Был дефект в коннекторе кабеля питания :)
Пока не планирую. Может слишком много текста получиться… Мне понравилась книга «Designing Data Intensive Applications» автора Martin Kleppmann, в ней довольно хорошо разбирается почти все из моих диаграмм
Приятно изучать такую эффектно выглядящую и профессионально составленную диаграмму! Я так и вижу, как можно успешно продать российскому бизнесу внедрение какого-либо решения с помощью ее презентации.
Ваша классификация подробная и понятная, даже если исключить конкретные реализации (которые, развиваясь, со временем могут перемещаться по диаграмме), можно проводить по ней сессии обмена знаниями в коллективе…
Интересно, с какой практической целью Вы составили эту диаграмму? Как Вы ее используете?
Полностью согласен! Осмысленность в решениях, смелость в признании ошибок и воля к их исправлению - хорошие качества опытных людей :)
И не поверю, что здесь ни у кого не было опыта сбора стартовавшего с микросервисов проекта в монолит, или перехода с модной NoSQL на реляционную СУБД, или переписывания реализованного, например, на GO (ничего не имею против этого ЯП) «прогрессивным» разработчиком микросервиса на родной для команды Kotlin или Java (в том случае, если не было объективной причины использовать GO на проекте, помимо желания разработчика)…
И вы, комментаторы, все пишите красиво, правильно… Однако, потом, после очередного посещения модной конференции или прочтения хайповой статьи, начинаете бизнесу палки в колеса вставлять своими технологическими или архитектурными экспериментами, которые годятся только чтобы на собеседованиях хвастаться… То решите прототип для стартапа сразу с микросервисной архитектуры создавать, то соберетесь Kubernetes в проект из двух стабильных сервисов внедрять, то Big Data и Machine Learning на базу данных с парой тысяч строк натравить…
Для меня эти истины были понятны еще когда я только джуном устроился, потому что до этого много лет разным мелким бизнесом занимался. Но как такое понимание может взяться у разработчика, после получение образования Computer Science в институте, и даже нескольких лет работы?.. Только после того, как его назначат управленцем в бизнес — СТО
Ваша классификация подробная и понятная, даже если исключить конкретные реализации (которые, развиваясь, со временем могут перемещаться по диаграмме), можно проводить по ней сессии обмена знаниями в коллективе…
Интересно, с какой практической целью Вы составили эту диаграмму? Как Вы ее используете?