Количество не всегда значит качество

На Re:Invent, о котором я уже писал, был представлен ещё и десяток сервисов AWS - теперь их у компании почти 200. И среди базовых, всем и всегда нужных - баз данных, серверов и разнообразных вариантов хранения данных есть совершенно диковинные, например, БД временных рядов или QLDB на основе blockchain.

Оставим за кадром необходимость таких специфических областей применения, и окупается ли их разработка. Моё личное мнение что при таком масштабе инновации могут иногда совершаться ради инноваций, а не только для действительного захвата рынка и решения каких-то важных задач.

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

Например, Athena - такой себе Hive в браузере - у вас есть данные на S3, а в веб консоли вводятся SQL-запросы для поиска и анализа по этим данным. Очень удобно и быстро. На момент запуска, году в 2016-ом, даже интеграция с S3, на базе которого и работает сервис, оставляла желать лучшего. А интеграция с CloudWatch, сервисом для мониторинга, появилась только в начале 2019 года. То есть раньше не было реального способа отследить время исполнения запроса и выявить узкие места.

Примерно в то же время был представлен Glue - ETL-сервис. И опять никакой интеграции между сервисами в течение года, насколько я помню. Хотя оба эти решения аналитики данных очень близко связаны и взаимно дополняют друг друга.

И так в большинстве случаев происходит со всеми сервисами: AWS выпускает, по сути, MVP который потом допиливается по мере развития и необходимости. Не сказать, что такой подход не оправдан с точки зрения бизнеса - если продукт не выстрелит, то зачем его развивать. Или вектор развития, по мнению команды, отличен от заказчика, что не менее важно. Тем не менее, обеспечивать изначальную интеграцию между новыми сервисами и существующими core-продуктами для повышения привлекательности и работоспособности сервиса явно что-то нужное изначально. Иначе это напоминает облачное решение от одного из производителей БД который поставив свои программно-аппаратные комплексы в свой ЦОД назвал их облаком, при этом напрочь забыв что такое облако по NIST.

С другой же стороны понятно стремление занять новые для себя ниши и рынки в надежде на рост интереса со стороны заказчиков. Обидно когда из-за отсутсвия взрывного роста потребления сервиса интерес к нему быстро угасает.

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365