Создание микросервисов

Если вы читаете эту книгу, то, наверное, работаете в организации, создающей программный код. Вы можете разрабатывать программы для собственных внутренних целей, или для внешнего клиента, или и для того и для другого. Тем не менее, даже если вы представляете организацию, способную создавать существенные объемы заказных программ, вы все равно пользуетесь программными продуктами, предоставляемыми внешними сторонами, будь то коммерческие продукты или программы с открытым кодом. Почему именно так это и происходит?

Во-первых, ваша организация почти наверняка испытывает большие потребности в программных средствах, которые нельзя удовлетворить своими силами. Подумайте обо всех продуктах, которыми пользуетесь, от инструментов, применяемых в офисах, типа Excel до операционных систем и систем начисления заработной платы. Создание всего этого для внутреннего потребления может стать непосильной затеей. Во-вторых, что более важно, это будет экономически невыгодно! Например, стоимость создания собственной системы электронной почты будет значительно больше стоимости использования существующих сочетаний почтового сервера и клиента, даже если это будут коммерческие варианты.

Мои клиенты часто задаются вопросом: «Создавать или покупать?» Обычно, когда происходит подобный разговор с обычной предпринимательской организацией, я и мои коллеги даем совет, который сводится к следующему: «Создавать, если то, что вы сделаете, будет уникальным и может считаться стратегическим активом, и покупать, если нужный инструмент к данной категории не относится».

Например, используемая в обычной организации система начисления заработной платы может не считаться стратегическим активом. Людям во всем мире начисляют зарплату одинаково. Точно так же большинство организаций склоняются к приобретению готовых систем управления контентом (CMSes), если использование подобного инструментария не рассматривается как что-то ключевое по отношению к их бизнесу. Однако в прежние времена меня привлекали к переделке сайта Guardian, и было принято решение создать заказную систему управления контентом, поскольку она была основой газетного бизнеса.

Поэтому намерение временами использовать коммерческие программные продукты сторонних производителей вполне обоснованно и может только приветствоваться. Но многие из нас в конечном счете проклинают некоторые из таких систем. Почему же так происходит?

Отсутствие должного контроля

Одна из проблем, связанных с объединением с COTS-продуктами CMS- или SaaS-инструментов и расширением их возможностей, заключается в том, что многие технические решения, как правило, уже были сделаны для вас. Как интегрироваться с инструментом? Это решение поставщика. Каким языком программирования можно воспользоваться для расширения возможностей инструмента? Это зависит от поставщика. Можно ли сохранить конфигурацию инструмента в системе управления версиями и восстановить ее с нуля, чтобы иметь возможность непрерывной интеграции в настройках? Это зависит от выбора, сделанного поставщиком.

Если вам повезет, то вопрос о том, насколько легко или трудно работать с инструментом с точки зрения разработчика, будет рассмотрен как часть процесса выбора инструмента. Но даже при том вы фактически уступаете некоторый уровень контроля внешней стороне. Вся хитрость заключается в том, чтобы вернуться к проведению интеграции и адаптации на своих условиях.

Адаптация

Многие инструментальные средства, приобретаемые предпринимательскими организациями, продаются с возможностью глубокой адаптации именно под ваши потребности. Осторожно! Зачастую из-за самой природы цепочки инструментов, к которой у вас есть доступ, стоимость адаптации может быть значительно выше создания с нуля какого-нибудь продукта на заказ! Если вы решили приобрести продукт, чьи конкретные возможности не предназначены специально для вас, то, может быть, более разумным решением будет подстроить под него порядок работы организации, чем заниматься сложной адаптацией этого продукта под свои нужды.

Хорошим примером опасности подобного рода могут послужить системы управления контентом. Мне приходилось работать с несколькими CMS, которые по своей конструкции не поддерживали непрерывную интеграцию, у которых были ужасные API и в которых даже несущественное обновление исходного инструментария могло разрушить любые сделанные вами настройки.

Наиболее проблемным в этом смысле является продукт компании Salesforce. На протяжении многих лет компания проталкивала свою платформу Force.com, которая требовала использования языка программирования Apex, существовавшего только внутри экосистемы Force.com!

Тонкости интеграции