Новые технологии - это же кайф для инженера. Я занимался переводом систем телеком ядра с проприетарного оборудования на виртуализацию, и потом в Кубернетес. Проприетарный вариант был очень закрытым и устаревшим, например при работе с датами в программировании надо было учитывать количество символов в номере дня, и т.п. И смотреть, что происходит в системе было сложной экспертной работой. В виртуализации, с приходом Линукса, сразу руки сильно развязались, автоматизируй что хочешь любыми современными инструментами. А в мире Кубера уже вообще всё уже сделано - и развёртывание, и самовосстановление, и готовый комплексный мониторинг. Что-то из этого отдельными тулзами, но всё уже готово как в виде инструментов, так и в виде подходов, алгоритмов, паттернов.
Идеальный мир в моём представлении - это когда снизу идут технологические инициативы, а сверху - ресурсы )) Ресурсы - это и обучение, и финансовая мотивация, и железо, и время на эксперименты.
Одним из повторяющихся "паттернов" в переходе на микросервисы у нас бывали опасения, что микросервисы никогда не будут такими же быстрыми как хранимые процедуры БД. Ребята, как и я, формировались профессионально, когда мейнстримом были вычисления, максимально приближенные к данным. А тут 12 факторов говорят - работайте с любым хранилищем удалённо. Мы общались с командами, раскручивали внутренние митапы - по микросервисам, паттернам - и решения нашлись: хранить (дублировать) данные в виде, сразу подготовленном к выдаче. Достаточно было не давить на команду, дать им поделать задачи на тестирование, изучение нового подхода, и теперь круче и сам продукт, и разработчики.
Это пример скорее не про отдельную технологию, а про смену архстиля, и мотивацию разработчиков. Введение отдельных технологий работает схожим образом, конечно обновляться нужно, но и делать это "с умом" ))
Это точно. Поиск правильного баланса между low coupling (что разнести) и cohesion (что должно оставаться вместе) это прям челлендж. А если к тому же на больших физических дистанциях, то станете ещё и экспертом контроля распределённой согласованности (retry, circuit breaker, outbox)
Привет! Спасибо!
Новые технологии - это же кайф для инженера. Я занимался переводом систем телеком ядра с проприетарного оборудования на виртуализацию, и потом в Кубернетес. Проприетарный вариант был очень закрытым и устаревшим, например при работе с датами в программировании надо было учитывать количество символов в номере дня, и т.п. И смотреть, что происходит в системе было сложной экспертной работой. В виртуализации, с приходом Линукса, сразу руки сильно развязались, автоматизируй что хочешь любыми современными инструментами. А в мире Кубера уже вообще всё уже сделано - и развёртывание, и самовосстановление, и готовый комплексный мониторинг. Что-то из этого отдельными тулзами, но всё уже готово как в виде инструментов, так и в виде подходов, алгоритмов, паттернов.
Идеальный мир в моём представлении - это когда снизу идут технологические инициативы, а сверху - ресурсы ))
Ресурсы - это и обучение, и финансовая мотивация, и железо, и время на эксперименты.
Одним из повторяющихся "паттернов" в переходе на микросервисы у нас бывали опасения, что микросервисы никогда не будут такими же быстрыми как хранимые процедуры БД. Ребята, как и я, формировались профессионально, когда мейнстримом были вычисления, максимально приближенные к данным. А тут 12 факторов говорят - работайте с любым хранилищем удалённо.
Мы общались с командами, раскручивали внутренние митапы - по микросервисам, паттернам - и решения нашлись: хранить (дублировать) данные в виде, сразу подготовленном к выдаче.
Достаточно было не давить на команду, дать им поделать задачи на тестирование, изучение нового подхода, и теперь круче и сам продукт, и разработчики.
Это пример скорее не про отдельную технологию, а про смену архстиля, и мотивацию разработчиков. Введение отдельных технологий работает схожим образом, конечно обновляться нужно, но и делать это "с умом" ))
Один котик был уставший, а когда много - это они расслабленные ))
Это точно. Поиск правильного баланса между low coupling (что разнести) и cohesion (что должно оставаться вместе) это прям челлендж. А если к тому же на больших физических дистанциях, то станете ещё и экспертом контроля распределённой согласованности (retry, circuit breaker, outbox)
Спасибо! Будем стараться ))