z-sector · February 9, 2025 12:10 · Oct 25, 2022 · Oct 25, 2022 · Apr 29, 2021
diff --git a/distributed-monolith-vs-microservices-ru.md b/distributed-monolith-vs-microservices-ru.md
@@ -1,6 +1,6 @@
 # Чеклист "Мои микросервисы - это распределенный монолит?"  
 
-Из [You're not actually building microservices](https://www.simplethread.com/youre-not-actually-building-microservices/)
+Из статьи [You're not actually building microservices](https://www.simplethread.com/youre-not-actually-building-microservices/)
 
 ## Проверка на симптомы 
 
@@ -36,7 +36,9 @@
 
 По мере увеличения размера системы и количества разработчиков вы обнаружите, что разделение сервисов станет обычным делом. 
 
-### Из [Segment's Goodbye Microservices](https://segment.com/blog/goodbye-microservices/)
+### Из статьи [Segment's Goodbye Microservices](https://segment.com/blog/goodbye-microservices/)
+
+Некоторые проблемы с которыми вы столкнетесь в микросервисах по мере роста:  
 
 > Чтобы облегчить бремя разработки и поддержки этих кодовых баз, мы создали общие библиотеки, чтобы упростить и сделать общими преобразования и функциональные возможности, такие как обработка HTTP-запросов, в местах использования проще и единообразнее. 
 

diff --git a/distributed-monolith-vs-microservices-ru.md b/distributed-monolith-vs-microservices-ru.md
@@ -1,28 +1,39 @@
-### Из [You're not actually building microservices](https://www.simplethread.com/youre-not-actually-building-microservices/)
+# Чеклист "Мои микросервисы - это распределенный монолит?"  
 
-Итак, вы создаете микросервисы? Взгляните на некоторые из этих симптомов и решите для себя:
+Из [You're not actually building microservices](https://www.simplethread.com/youre-not-actually-building-microservices/)
 
-- [ ] Изменение одного микросервиса часто требует изменений в других микросервисах
+## Проверка на симптомы 
+
+Итак, вы создаете микросервисы?  
+Взгляните на некоторые из этих симптомов и проставьте галочки, где вы согласны:
+
+- [ ] Изменение одного микросервиса часто требует изменений в других микросервисах (сильная связанность)
 - [ ] Развертывание одного микросервиса требует одновременного развертывания других микросервисов
 - [ ] Наши микросервисы слишком болтливы (много общаются друг с другом)
 - [ ] Одни и те же разработчики работают с большим количеством микросервисов
 - [ ] Многие из наших микросервисов совместно используют хранилище данных
 - [ ] Наши микросервисы имеют один и тот же код или модели
 
-Сейчас, я не говорю, что если ваша реализация микросервисов соответствует одному из пунктов, у вас есть проблема... всегда есть исключения. Но по большей части, если вы киваете головой в некоторых из приведенных выше пунктов, возможно, вы не работаете с микросервисами.
+Если у вас есть хотябы одна галочка - у вас проблема... конечено, всегда есть исключения. Но по большей части, если вы киваете головой в некоторых из приведенных выше пунктов, возможно, вы не работаете с микросервисами.
 
-Как проверить? Chraos Engenering https://www.gremlin.com/blog/is-your-microservice-a-distributed-monolith/ 
+## Как проверить пункты чеклиста  
 
-...
+Подробно в статье [Is your microservice a distributed monolith?](https://www.gremlin.com/blog/is-your-microservice-a-distributed-monolith/) (2020)
+Вкратце: попробовать пошатать систему с "Chraos Engenering" подходом.  
 
-Если вы начинаете с монолита, ваша цель должна в том, чтобы не дать ему перерасти в чудовище. Ключ к этому - просто слушать свое приложение! Я знаю, что легче сказать, чем сделать, но по мере роста вашего монолита задайте себе несколько вопросов:
+## А если у меня уже есть монолит?
 
-- [ ] Есть ли что-нибудь, что масштабируется с иной скоростью, чем отсальные части системы?
+Если вы начинаете с монолита, ваша цель должна быть в том, чтобы не дать ему стать чудовищем.  
+Ключ к этому - просто слушать свое приложение!   
+Я знаю, что легче сказать, чем сделать, но по мере роста вашего монолита задавайте себе несколько вопросов:
+
+- [ ] Есть ли что-нибудь, что масштабируется с иной скоростью, чем остальные части системы?
 - [ ] Есть ли что-нибудь, что кажется «привязанным» к внешней части системы?
-- [ ] Что-нибудь меняется намного быстрее, чем отсальные части системы?
-- [ ] Есть ли в системе часть, требующая более частого развертывания, чем отсальные части системы?
+- [ ] Что-нибудь меняется намного быстрее, чем остальные части системы?
+- [ ] Есть ли в системе часть, требующая более частого развертывания, чем остальные части системы?
 - [ ] Есть ли в системе часть, внутри которой независимо работает один человек или небольшая команда?
-- [ ] Есть ли подмножество таблиц в хранилище данных, не связанных с остальными частями системы? 
+- [ ] Есть ли подмножество таблиц в хранилище данных, не связанных с остальными частями системы?  
+
 По мере увеличения размера системы и количества разработчиков вы обнаружите, что разделение сервисов станет обычным делом. 
 
 ### Из [Segment's Goodbye Microservices](https://segment.com/blog/goodbye-microservices/)

diff --git a/distributed-monolith-vs-microservices-ru.md b/distributed-monolith-vs-microservices-ru.md
@@ -0,0 +1,43 @@
+### Из [You're not actually building microservices](https://www.simplethread.com/youre-not-actually-building-microservices/)
+
+Итак, вы создаете микросервисы? Взгляните на некоторые из этих симптомов и решите для себя:
+
+- [ ] Изменение одного микросервиса часто требует изменений в других микросервисах
+- [ ] Развертывание одного микросервиса требует одновременного развертывания других микросервисов
+- [ ] Наши микросервисы слишком болтливы (много общаются друг с другом)
+- [ ] Одни и те же разработчики работают с большим количеством микросервисов
+- [ ] Многие из наших микросервисов совместно используют хранилище данных
+- [ ] Наши микросервисы имеют один и тот же код или модели
+
+Сейчас, я не говорю, что если ваша реализация микросервисов соответствует одному из пунктов, у вас есть проблема... всегда есть исключения. Но по большей части, если вы киваете головой в некоторых из приведенных выше пунктов, возможно, вы не работаете с микросервисами.
+
+Как проверить? Chraos Engenering https://www.gremlin.com/blog/is-your-microservice-a-distributed-monolith/ 
+
+...
+
+Если вы начинаете с монолита, ваша цель должна в том, чтобы не дать ему перерасти в чудовище. Ключ к этому - просто слушать свое приложение! Я знаю, что легче сказать, чем сделать, но по мере роста вашего монолита задайте себе несколько вопросов:
+
+- [ ] Есть ли что-нибудь, что масштабируется с иной скоростью, чем отсальные части системы?
+- [ ] Есть ли что-нибудь, что кажется «привязанным» к внешней части системы?
+- [ ] Что-нибудь меняется намного быстрее, чем отсальные части системы?
+- [ ] Есть ли в системе часть, требующая более частого развертывания, чем отсальные части системы?
+- [ ] Есть ли в системе часть, внутри которой независимо работает один человек или небольшая команда?
+- [ ] Есть ли подмножество таблиц в хранилище данных, не связанных с остальными частями системы? 
+По мере увеличения размера системы и количества разработчиков вы обнаружите, что разделение сервисов станет обычным делом. 
+
+### Из [Segment's Goodbye Microservices](https://segment.com/blog/goodbye-microservices/)
+
+> Чтобы облегчить бремя разработки и поддержки этих кодовых баз, мы создали общие библиотеки, чтобы упростить и сделать общими преобразования и функциональные возможности, такие как обработка HTTP-запросов, в местах использования проще и единообразнее. 
+
+...
+
+> Общие библиотеки ускорили создание новых направлений. Знакомство с единым набором общих функций сделало обслуживание менее проблемным. 
+
+> Однако стала возникать новая проблема. Тестирование и развертывание изменений в этих общих библиотеках повлияло на все наши направления. На его обслуживание стали уходить много времени и усилий. Вносить изменения для улучшения наших библиотек, зная, что нам придется тестировать и развертывать десятки сервисов, было рискованным делом. При нехватке времени инженеры включали только обновленные версии этих библиотек в одном месте кода (single destination’s codebase). 
+
+> Со временем версии этих общих библиотек начали расходиться в разных целевых базах кода. Огромное преимущество, которое мы когда-то получали, заключающееся в сокращении настройки каждой целевой кодовой базы, начало меняться. В конце концов, все они использовали разные версии этих общих библиотек. Мы могли бы создать инструменты для автоматизации развертывания изменений, но на этом этапе не только снизилась производительность труда разработчиков, но и мы начали сталкиваться с другими проблемами с микросервисной архитектуры. 
+
+По моему опыту, самым большим преимуществом микросервисов является разделение команд. 
+В монолитном приложении очень сложно поддерживать продуктивность разработчиков, поскольку количество разработчиков увеличивается, а унаследованный код накапливается. Разделение сервисов и предоставление каждой команде разработчиков контроля над собственными кодовыми базами позволяет им разрабатывать собственные продукты в своем собственном темпе. 
+
+Если у вас всего одна команда разработчиков, микросервисы будут намного менее привлекательными. Тем не менее, все же есть некоторые преимущества, такие как возможность изолированного рефакторинга частей вашей кодовой базы (включая, возможно, переписывание их на разных языках) и возможность индивидуально настраивать масштаб времени выполнения различных частей вашей кодовой базы.
No results found