Имея за плечами три года в качестве генерального директора Google Cloud, к настоящему времени Томаса Куриана печать на организации четкая. Это была одна из подтем конференции Google NEXT на прошлой неделе.
Как облачный провайдер, который появился позже, чем Amazon Web Services (AWS) и Microsoft Azure, неудивительно, что Google Cloud активно набирает сотрудников. Но примечательно, особенно на высшем уровне управления, что многие принадлежащий недавние сотрудники вышли из рядов признанных поставщиков на предприятии. Последний Геррит Казмайер, ранее работавший в SAP, в качестве главы отдела данных и искусственного интеллекта Google. Эти новые лица обеспечили взгляд вовне, чего давно не хватало в Googleplex.
Неудивительно, что тон слегка изменился. Google не обязательно отказывался от обмена сообщениями «Беги как Google» – то, что всегда было ключевым фактором привлекательности Google Cloud. «Беги как Google» все еще появляется, когда Google обсуждает свои подходы к безопасности с нулевым доверием, ИИ и глобальной магистрали, по которой проходит его трафик. Но все чаще речь идет о встречах с предприятиями, где они живут, а также о применении автоматизации Google – например, недавно представленной служба миграции базы данных что делает миграцию MySQL и PostgreSQL более простой по сравнению с аналогичными сервисами от AWS и Azure.
Даже если базовая технология уникальна, например, с Cloud Spanner или Портфолио AI, Google дополняет эти службы более привычными операциями. На прошлой неделе на NEXT Google анонсировал предварительный просмотр PostgreSQL API для Cloud Spanner. До этого предприятиям, которые хотели внедрить эту услугу, которая предоставляет распределенную, глобальную, согласованную глобальную базу данных транзакций, приходилось изучать новую платформу. Как рассказал брат Big on Data Эндрю Браст в своем обзоре данных и ИИ, Spanner теперь использует оболочку PostgreSQL поверх своего уникального механизма хранения.
Добавление Google API PostgreSQL не так уж и уникально; AWS и Azure используют это для Аврора для PostgreSQL и База данных SQL Azure для Гипермасштабирование PostgreSQL, соответственно. Фактически, использование API-интерфейсов для совместимости на уровне приложений с базами данных с открытым исходным кодом становится обычным явлением в облаке. Возникающий шаблон проектирования включает в себя разработку канонических облачных механизмов хранения с последующим применением API-интерфейсов, чтобы базы данных выглядели знакомыми, изобилующими одинаковыми вызовами и типами данных. AWS использует такие подходы для Aurora, DocumentDB, и Пространства ключей для Apache Cassandra; Azure использует этот шаблон проектирования для Cosmos DB и PostgreSQL Hyperscale; Google делает то же самое для Cloud Spanner и Firestore.
Spanner представляет собой хороший пример того, как Google Cloud различается и адаптируется. Под капотом Spanner есть архитектурные отличия, которые, например, обходятся без таких возможностей, как хранимые процедуры, требуя от разработчиков размещения всей логики на уровне приложения. Тем не менее, с PostgreSQL API типы данных и команды должны оставаться знакомыми. Хотя на данный момент мы не знаем, насколько поддерживается PostgreSQL PL / pgSQL.
Google также встречает клиентов там, где они живут, со своими программа партнерства с базами данных с открытым исходным кодом который учитывает Confluent, DataStax, Elastic, InfluxData, MongoDB, Neo4J и Redis. Хотя управляемые услуги DBaaS большинства этих поставщиков также доступны на AWS и Azure, в Google есть совместные продажи и поддержка. Основная идея заключается в том, что вам не нужно менять отношения с поставщиком базы данных с открытым исходным кодом, чтобы получить поддержку от Google Cloud. Как мы уже отмечали ранее, мы надеемся, что Google Cloud также начнет расширять встроенную интеграцию для Облачный поток данных, BigQuery, и Vertex AI – сервисы, которые могут расширить эти сервисы баз данных до сквозных решений, подобных, например, Azure Synapse Analytics.
Предоставлено: Google Cloud.
Неудивительно, что благодаря лидерству, исходящему от корпоративных платформ, все больший акцент делается на решениях. Хотя Google не уникален в своем предложении решений, приведенная выше диаграмма показывает, что с момента появления контакт-центра AI пару лет назад его портфель значительно вырос.
Частично фокус на решениях – это объединение синергии на платформе. Это общая проблема для каждого облачного провайдера, чей портфель услуг раздули на грани того, чтобы стать практически подавляющее.
Данные и ИИ являются яркими примерами того, как смешанные услуги могут повысить продуктивность клиентов. Объявление Google о Google Earth Engineс возможностью передачи геопространственных метаданных в BigQuery – это новая интеграция, которая использует возможности аналитики, исходящие от материнской компании.
Но как насчет объединения частей, которые уже существуют в портфеле, в виде интегрированных или смешанных услуг? Ранее мы намекнули о расширении досягаемости партнеров по базам данных с открытым исходным кодом до различных служб данных, аналитики и ИИ. Лазурь SAP, и Oracle уже начали предлагать смешанные облачные сервисы для хранилищ данных, от конвейеров преобразования данных до искусственного интеллекта и визуализации. Существует большой потенциал для более тесной интеграции с оперативными базами данных, которые составляют большую часть партнерского портфеля с открытым исходным кодом. Со стороны Google слишком много очевидных синергий между BigQuery и Смотритель, например, не говоря уже о Dataflow и Vertex AI.
В Looker явно есть баланс; К чести, Google не превратил Looker в подчиненный сервис, поддерживающий только Google Cloud и платформы данных Google. И да, до этого BigQuery был одним из поддерживаемых Looker источников. На NEXT мы увидели некоторые шаги к более тесной интеграции с другими сервисами Google Cloud, такими как Connected Sheets, которые теперь могут быть представлены как Looker Block на его семантическом уровне. Мы бы хотели, чтобы те же возможности были распространены на конвейеры, разработанные в Cloud Dataflow, что вы, вероятно, могли бы сейчас выполнить вручную.
Multicloud – еще один пример того, как Google Cloud ищет клиентов там, где они есть. По общему признанию, Google – не единственный облачный провайдер, который заявляет о запуске своей плоскости управления на чужой территории; Microsoft продвигает ту же возможность с Лазурная дуга. Но неудивительно, что Google, как соперник AWS и Azure (который начал работу раньше), использует многооблачные технологии по большему количеству направлений. Он говорит клиентам: «Мы знаем, что у вас, вероятно, уже есть данные в других облаках, поэтому давайте перенесем аналитику туда, где она есть». На NEXT было объявлено GA BigQuery Omni, который может распространять аналитику на несколько облаков. Мы надеемся, что это также дает средства для минимизации платы за исходящие данные с иностранной территории.
Говоря о выходных зарядах, мы хотели бы подбить Google Cloud: почему бы не резко сократить или полностью не избавиться от исходящих зарядов? Это еще больше подтолкнет клиентов AWS и Azure к использованию облачных сервисов Google, не опасаясь уплаты штрафа.
Вероятно, самым интересным анонсом мультиоблака, появившимся на прошлой неделе, был предварительный просмотр Распределенное облако. Это гибридная облачная платформа, которую можно запускать на границе сети Google (в любой из более чем 140 точек доступа по всему миру); внутри оператора связи; в местах расположения клиентов, таких как фабрики или розничные магазины; или дома в собственном дата-центре заказчика. Google Distributed Cloud – это управляемое облако, но им может управлять заказчик, партнер Google или сам Google. Есть некоторые параллели с Аванпосты Амазонки, Амазонка Длина волны, Oracle Cloud @ Заказчик, IBM Cloud Satellite, и HPE GreenLake – хотя есть много различий в объеме того, что предлагает каждое из этих гибридных облаков.
Хотя Google, возможно, не уникален в автоматизации миграции баз данных, добавлении знакомых API PostgreSQL, предложении решений или расширении гибридных облачных стратегий, тот факт, что он не только говорит клиентам, что нужно все менять и делать что-то так же, как Google, – это существенное изменение тона.
