Извиняюсь за кликбейтный заголовок, но это правда. Почему сегодня мы используем микросервисы? Ответ лежит в основе принципов Agile и Lean.
Мы хотели стать лучше в создании программного обеспечения, которое хотят наши клиенты, держа их в центре внимания, принимая соответствующие отзывы, пока не стало слишком поздно. Для этого нам нужно было как можно быстрее выпускать программные продукты. Тонкая вертикальная нарезка наших продуктов, переход от MVP к MVP.
Все в порядке, когда вы создаете отдельное приложение, мобильное или другое. Но это вряд ли имеет место на любом современном предприятии, есть зависимости, которые появляются на каждом этапе программы с самого начала до момента, когда необходимо масштабировать и взаимодействовать с другими системами предприятия. Это медленно создает перекрестные зависимости прямо на уровне базы данных, где не только вы зависите от других систем, но и другие системы зависят от вас. Это резко замедляет разработку, и петля обратной связи, о которой мы говорим, уже не такая короткая.
Введите микросервисную архитектуру. Не вдаваясь в подробности, архитектура микросервиса основана на одной простой предпосылке: каждый сервис должен быть абстрагирован и отвечает за свою функциональность и данные от начала до конца. Если службе необходимо взаимодействовать с вами, вы определяете интерфейс того, как она будет работать через API. Тем самым ограждая себя от перекрестной зависимости.
Мир снова прекрасен, вы можете выпускать быстрее и получать ценные отзывы для итерации вашего продукта. Но в каждом среднем и крупном предприятии таится еще один зверь — всегда необходимая функция MI. Традиционно функции MI в организациях полагались на устаревшие методы хранения для запуска отчетов, поэтому они не запускали их в транзакционных системах, что здорово и так и должно быть. Но эти технологии ограничены. Вы должны заранее обработать свои данные, структурировать их, а затем загрузить в свою систему хранения. Они делают это, тесно связывая его с вашими схемами и запуская против них ETL, и внезапно вы привязываетесь к уровню базы данных. Итерации теперь зависимы, и всех тех преимуществ, ради которых вы выбрали микросервисы, больше нет.
Итак, что делать теперь? Или как этого избежать?
Вы можете избежать этого, создав озеро данных (что непросто, но требует гораздо меньшего обслуживания и накладных расходов, чем тысячи строк PLSQL, которые необходимо поддерживать для хранилища данных). Основная предпосылка озера данных заключается в том, что оно буквально переворачивает хранение с ног на голову. Вместо того, чтобы преобразовывать и структурировать данные, когда вы помещаете их в свое хранилище, вы можете просто выгрузить в него все, а с помощью современных технологий вы даже можете выгрузить в него неструктурированные данные, такие как текстовые файлы, изображения и даже видео, и, в зависимости от использования, структурировать их, в то время как извлечение данных из озера.
Это в сочетании с передовой аналитикой, методами машинного обучения и искусственного интеллекта, которые уже доступны и очень доступны, может предоставить вам отличную информацию о ваших клиентах, как никогда раньше. Все время позволяя бизнес-вертикалям вашего предприятия итерировать свои приложения так, как они хотят, и используя микросервисную архитектуру так, как она предназначена для использования.
