Первый из представленных способов видится более простым, управляемым и (ключевое заблуждение) дешевым. К сожалению, большая часть комментариев негативного характера в адрес микросервисной архитектуры, о которых говорилось выше, обусловлена именно приоритетом данному варианту развития (эволюционному). На первый взгляд, ситуация кажется простой: провести анализ созданных ранее решений, выделить в них те элементы, которые могут представлять собой микросервисы, а далее провести реализацию очерченного функционала в соответствии с намеченным планом и на новом технологическом уровне. При этом зачастую к новым решениям применяется mindset прошлого типовым вариантом разбиения информационных систем на микросервисы стала реализация функциональных подсистем в формате отдельных микросервисов. При этом подсистемы зачастую были сильно связаны между собой, содержали большое количество перекрестных вызовов, так называемые «божественные» объекты и функции (содержащие избыточное количество данных и функционала соответственно). Результатом обычно был рассмотренный по ходу настоящего раздела «распределенный монолит». Снижалась производительность систем, их надежность и управляемость ИТ-ландшафта организаций в целом. Релизные модели и циклы предыдущих поколений не позволяли эффективно управлять жизненным циклом изменений, объемы регрессионного тестирования существенно возрастали. Для устранения возникавших проблем приходилось расширять штат специалистов, решать возникшие проблемы механическим увеличением трудозатрат; альтернативой становился революционный переход (при этом существенные временные, трудовые и финансовые ресурсы уже были вложены в попытку перехода эволюционного).
Революционный переход предполагал создание нового ИТ-ландшафта параллельно существующему. С целью исключения нарушения стабильности функционирования производственных и бизнес-процессов текущие информационные системы продолжали выполнять задачи, в то время как по мере создания и развития нового ИТ-ландшафта в парадигме микросервисной архитектуры новый функционал создавался (переводился) в рамках него. Перевод осуществлялся по бизнес-функциям, а не по структурам предыдущих архитектурных поколений. По итогам замещения функционала, выполняемого унаследованным ИТ-ландшафтом, последний выводился из эксплуатации. Потенциальные проблемы mindset наблюдались и в случаях революционного перехода: соблазн следовать шаблонам прошлого, идти проторенным путем часто превалировал над новыми концепциями. Но при создании нового ИТ-ландшафта «с нуля» выявление проникновения практик предыдущих поколений производилось на более ранней стадии, нежели в случае эволюционного перехода, в связи с чем могло оперативно устраняться. Именно таким путем шли лидеры технологического рынка.
Таким образом, варианты революционного и эволюционного развития архитектуры можно уподобить Сцилле и Харибде из «Одиссеи»: проход рядом со скалой Сциллы грозил Одиссею и его спутникам гибелью части экипажа, Харибда же общей гибелью всех мореходов. Именно поэтому главным аспектом архитектурного перехода, развития архитектуры являлся и является mindset, который должен быть направлен строго на революционное развитие.
Архитектура и открытый код
Ранее уже отмечалось, что использование решений с открытым исходным кодом является одной из ключевых тенденций развития современной архитектуры. Следование данной тенденции позволяет существенно ускорить разработку новых ИТ решений, а также повысить их качество, но и предъявляет новые требования к работе архитектора.
17 сентября 1991 года Линус Торвальдс опубликовал в сети исходный код ядра операционной системы Linux, что считается началом эпохи программных продуктов с открытым исходным кодом. Долгое время программное обеспечение с открытым исходным кодом, имевшее свободно распространяемые версии, считалось уделом узких групп энтузиастов, его применение в реальной промышленной среде представлялось нецелесообразным ввиду опасений в части надежности, безопасности, сопровождения и т. д. Тем не менее, данное направление программного обеспечения оказалось востребовано стартапами (как утверждали недоброжелатели, исключительно из-за фактора отсутствия лицензионных платежей). Но и по мере успеха ряда стартапов и превращения их в технологические гиганты (например, Meta Platforms, ранее Facebook), интерес уже лидеров технологического рынка к решениям на базе открытого кода не только не снижался, но и сами компании стали активными участниками процесса создания новых решений с открытым исходным кодом выше уже приводился пример распределенной СУБД Apache Cassandra (исходно проект создан в Facebook). Можно утверждать, что существует связь между гибкими практиками разработки, решениями с открытым исходным кодом и технологическим прорывом.
В XVII веке итальянский философ и экономист Антонио Серра в работе «Краткий трактат о средствах снабдить в изобилии золотом и серебром королевства, которые их не добывают» отметил: «Если ты хочешь узнать, какой из двух городов богаче, определи, каким количеством профессий владеют его жители. Чем больше профессий, тем богаче город». Приведенный тезис можно считать первым направлением в оценке влияния разделения труда на общую эффективность производства. Развитие данных наработок было произведено Адамом Смитом в труде «Исследование о природе и причинах богатства народов». Результатом стала теория разделения труда как основы повышения эффективности производственных цепочек. В дальнейшем данный тезис практически не оспаривался как сторонниками учения Смита, так и противниками. Необходимо отметить, что для ИТ данная теория также справедлива. Развитие и использование решений с открытым исходным кодом является ее наглядным подтверждением.
Безусловно, отсутствие лицензионных платежей было важным фактором, обусловившим использование открытых решений в стартапах. Но сводить все к фактору «бесплатности» в корне неверно. «Бесплатных» технологий не существует: свободно распространяемое программное обеспечение исходно требовало значительно больших усилий для достижения требуемых показателей работоспособности, нежели «закрытое» (vendor-lock), в случае которого можно было полагаться на экспертизу сотрудников компании поставщика. Но именно этот аспект, исходно казавшийся негативным, оказался серьезным преимуществом. За поставляемым солидными компаниями программным обеспечением стояли истории успеха, лучшие практики, «золотые» топологии, крупные и длительные проекты внедрений. В случае необходимости получения быстрых результатов и минимально жизнеспособного продукта, поставка которого заказчикам и/или инвесторам становилась вопросом выживания стартапов, во всех перечисленных выше атрибутах «закрытого» программного обеспечения не было практического смысла. Гораздо более важными аспектами, характеризующими технологии, были возможности максимально быстрой адаптации под нужды компании добавление нового функционала, исправление ошибок, отработка новых конфигураций и т. д. В этих аспектах «открытое» программное обеспечение априори превосходило «закрытое». С одной стороны, у компании-стартапа была возможность доработки технологий с открытым исходным кодом под максимально полную технологическую синергию с решаемыми задачами. С другой стороны, заказчик получал решение именно своих конкретных задач, а не реализацию и повторение шаблонов прошлого. Указанные аспекты приносили открытому программному обеспечению соответствующую популярность. С ростом популярности происходило расширение и углубление разделения труда в разработке технологий.
Предположим, что существовало программное обеспечение Х, позволяющее решать технологические задачи, востребованные стартапами. Каждый стартап, используя Х для автоматизации своих нужд, добавлял в него что-то свое в части функционала. Формировавшиеся правила развития решений с открытым исходным кодом рекомендовали (а в случае ряда лицензий и требовали) публиковать вносимые изменения, дополнительный функционал в открытом доступе, развивая Х. Х, обретая дополнительный функционал, получал потенциал дополнительной популярности среди стартапов. По мере превращения стартапов в технологические гиганты рос и соответствующий потенциал популярности Х, увеличивалось число архитекторов и разработчиков, использовавших Х в своих решениях. Иллюстративно это показано на Рисунке 11.
Стартапы, ряд которых перерастает в технологические гиганты, используют для автоматизации своих потребностей программное обеспечение Х с открытым исходным кодом. При этом география компаний распределенная, они работают по всему миру и на регулярной основе публикуют изменения, производимые в Х. Необходимо отметить, что при развитии стартапов до уровня технологических лидеров они занимали на рынке ниши, которые оставались незанятыми (или занятыми в незначительном объеме) компаниями традиционных направлений человеческой деятельности. При этом и требования к ним предъявлялись новые. Например, упоминавшийся пример технологического гиганта Meta Platforms (ранее Facebook), предложившего миру глобальную социальную платформу, ставшую не только средством общения, формирования и продвижения социальных связей, но и площадкой ведения бизнеса, предполагал работу с принципиально новым кругом пользователей и партнеров, а также предложение и поддержку новых форматов работы. Данный пример предполагал качественно новые требования к используемому программному обеспечению, в результате специалисты компании активно развивали технологические платформы, публикуя вносимые изменения. В итоге программное обеспечение с открытым исходным кодом приобретало функционал, качественно отличавший его от «закрытых» решений.