Mulesoft прагне зробити інтеграцію даних "plug and play", а API легше створювати для нерозробників

MuleSoft хоче значно спростити інтеграцію корпоративних даних і надати всім, а не тільки розробників, навички та інструменти для створення API. Незадовго до Dreamforce минулого тижня, Salesforce компанії оголосив низку ініціатив, спрямованих саме на це, включаючи Flow Designer (новий інструмент, який дозволяє користувачам створювати інтеграції та автоматизувати процеси без написання коду), попередньо створені шаблони інтеграції під назвою Прискорювачі, навчальні ініціативи (через Trailhead) і оновлення Anypoint API Community Manager і Anypoint Exchange, які полегшують людям пошук і ділитися API.

Я мав нагоду поговорити з Урі Сарідом, технічним директором MuleSoft, про оголошення, про те, як MuleSoft полегшує людям створення API, як Mulesoft об’єднує речі за лаштунками для клієнтів Salesforce, а також бачення компанії зробити інтеграцію корпоративних даних більш «plug and play». Нижче наведено відредаговану стенограму інтерв'ю.

Зробити секрет інтеграції даних менш секретним

Білл Детвілер: Тому не будемо говорити про оголошення. Ми збираємося трохи поговорити про це. На чому я справді хочу зосередитися, так це на тому, як MuleSoft є тим секретним соусом, що об’єднує всі різні платформи та всі різні продукти, які пропонує Salesforce.

Урі Сарід: так Є сенс говорити про це. Насправді я хотів би почати ще вище.

Білл Детвілер: Гаразд. чудово

Урі Сарід: Тому що я вважаю, що дуже важливо, коли ми занурюємося в технічні деталі і як насправді все працює, що робить це таємним і так далі, зберігати контекст цього бачення. Тож наша місія — полегшити взаємодію та об’єднати речі. І один із способів підійти до цього бачення — сказати, ну, знаєте, MuleSoft просто якимось магічним чином з’єднує все під сценою, і все якось автоматично з’єднується тощо. Я думаю, що техніки знають, що це насправді не має сенсу.

Білл Детвілер: Це як у фільмах, коли показують хакерство та ці просто випадкові персонажі на екрані.

Урі Сарід: Але бачення є абсолютно правильним, що в кінцевому підсумку для споживача, клієнта, людини в кінцевому підсумку це повинно відчуватися як магія. І найкраща технологія виглядає як магія. Отже, що ми насправді можемо зробити, щоб дозволити нашим клієнтам, якими є компанії, створювати цей чарівний досвід іноді автоматично, що нам потрібно зробити під ковдрою, щоб це дійсно сталося? І інше твердження, яке я б мав, полягає в тому, що так, є секретний соус. Ми повинні зробити це набагато менш секретним. Тому я хотів би поговорити про те, що це за соус і...

Білл Детвілер: Безумовно.

Урі Сарід: Що це за будівельні блоки. І як подумати про це, можливо, найпростіша аналогія полягає в тому, що в якийсь момент з’явилася мережа, і це було неймовірно. Кожна компанія повинна була опублікувати веб-сторінку, і якщо ви не опублікували веб-сторінку, вас не було. Але щоб опублікувати веб-сторінку, вам потрібно було принаймні вивчити HTML. Можливо, вам не потрібно було багато вивчати програмування, але вам потрібно було знати трохи HTML, можливо, трохи JavaScript. Вам потрібно було знати, як публікувати речі на серверах і так далі. І тому все ще було дещо обмежено з точки зору того, хто виробляє, і тоді багато людей зрештою споживатимуть.

Це було чудово. Google дуже допоміг у споживанні, можливо, не стільки у виробництві. У якийсь момент з’явилися блоги. У якийсь момент з’явилися соціальні мережі, такі як Facebook. І тепер кожен міг фактично виробляти, а також споживати.

Білл Детвілер: Тож бар’єр входу був значно нижчим.

Урі Сарід: точно. І саме в цьому напрямку ми рухаємося. Ми хочемо використати всі світові можливості та зробити їх легшими для споживання всім, але потім полегшити для всіх виробництво. І це вимагає деяких фундаментальних змін у нижній частині, і це вимагає трохи іншого мислення. Тож люди не думають про інтеграцію як про важку справу, яку ви робите під ковдрою за допомогою якоїсь магії секретний соус, і врешті-решт ви досягнете цього чудового результату, тому що врешті-решт, ймовірно, ніколи приходить.

Зробити інтеграцію корпоративних даних більш простою за допомогою API

Білл Детвілер: Мені здається, ти натрапив на щось справді важливе. Ви згадали про сумісність, і ми завжди говорили про це в ІТ-просторі. Але сумісність справді важлива зараз більше, ніж у минулому, оскільки, як ми з вами говорили раніше інтерв’ю, сучасні організації мають справу з десятками постачальників, десятками систем у різних географічних регіонах локації. Поговоріть трохи про те, наскільки важливо переконатися, що всі ці системи можуть працювати разом, щоб розкрити потенціал для даних і окремих людей.

Урі Сарід: Абсолютно. Хотілося б, щоб це були десятки. Це полегшило б наше життя.

Білл Детвілер: Це були не сотні.

Урі Сарід: Ми фактично нещодавно підготували звіт про порівняльний аналіз підключення. Виявляється, середнє підприємство використовує майже тисячу різних програм.

Білл Детвілер: Ого.

Урі Сарід: І це тому, що багато чого з’явилося через тіньовий ІТ-простір, тому вони насправді використовують набагато більше речей. Вони просто не знають, що використовують ці речі. Отже, є багато речей, які насправді рухають бізнес. А з мікросервісами та іншими тенденціями їх буде в сотні й тисячі разів більше. Тож ми маємо стати справді хорошими в цій справі, і ми маємо, по суті, зробити речі сумісними. Ви не можете зробити речі сумісними за допомогою ділових угод між компаніями. Це просто не масштабується з комбінаторних причин.

Тож ми маємо зробити їх принципово більш «підключай і працюй». І ось до чого ми йдемо: секретним соусом є API. І знову ж таки, техніки завжди мали API. Але якщо у вас є мільйон різних типів API і ви маєте добре володіти кожною технологією, це не допоможе. Це дає вам фізичний спосіб підключення, але це не дає вам легкого способу зробити речі сумісними. Таким був наш підхід і те, що було справді успішним для ринку, це поняття того, коли я йду щоб підключитися до чогось, я збираюся, якщо необхідно, створити простий API перед цим, якщо він ще не існує.

У деяких випадках вона вже існує. І через це я зв’язок. І кінцевим результатом цього в багатьох випадках є те, що я збираюся створювати нові API. Що ми маємо на увазі під API? Знову ж таки, це не те, що буде надто технічним, складним і дуже конкретним. Головне API — це простота. І це знову ж таки те, що дуже схоже на те, що відбувається з мікросервісами, які роблять одну річ і одну річ добре. Таким чином, API має розкривати можливості та розкривати їх дуже добре. Якщо він справді хороший і робить одну справу, він, швидше за все, витримає випробування часом.

А тепер подумайте про те, що всі створюють API, оскільки їм це потрібно для власних потреб, і всі з’єднання проходять через ці API. Так що це означає? Це означає, що інтеграції насправді набагато надійніші, оскільки вони проходять через ці чітко визначені контракти, і це означає, що створюється багато API. І тому, коли ви збираєтеся будувати наступну інтеграцію, ви, швидше за все, виявите, що частини вже є. І це починає генерувати цей цикл, цей мережевий ефект, який починає робити своєрідне створення, і ми бачили це в кожній іншій мережі.

Ми бачили це на YouTube із відео. Ми бачили це з Facebook, що стосується публікацій. Кожного разу, коли ви справді спрощуєте виробництво, споживання та відкриття, спрацьовує мережевий ефект, і ви отримуєте величезну кількість цінностей. І я думаю, що це тенденція, яка поширюватиметься, а не чекати, поки люди зроблять це один за іншим.

Більше новин і аналізу Salesforce Dreamforce:

• Salesforce запускає новий мобільний додаток Salesforce, Trailhead GO з Apple, ексклюзивні функції iOS, iPadOS
• Як Salesforce правильно влаштував конференцію розробників, а Microsoft, Apple, Facebook і Google заблукали
  
• Урок технологічного лідерства від Барака Обами
  
• Мрія Тіма Кука: кожна компанія працює на iPhone
  
• Salesforce рекламує Service Voice Cloud як майбутнє контакт-центру
  
• Dreamforce 2019: Customer 360 Truth від Salesforce має на меті консолідувати дані клієнтів (TechRepublic)
  
• Dreamforce 2019: Телефонія приєднується до Service Cloud (TechRepublic)
  
• Переможці Dreamforce 2019 Mega Demo Jam вражають публіку репом (TechRepublic)
  

Демістифікація API за допомогою прискорювачів, які підтримують екосистему продуктів Salesforce

Білл Детвілер: І що саме робить MuleSoft, через нові оголошення, через прискорювачі, через інтеграція з Trailhead, люди можуть навчатися та отримувати навички для їх створення API? Що ви робите, щоб допомогти з цим, щоб полегшити створення сумісних API?

Урі Сарід: точно. Таким чином, ми вкладаємо наші гроші в усі канали. Насправді все починається з продукту. Ми маємо інвестувати в те, щоб на рівні продукту створення API було створенням інтеграцій, які ставали все більш доступними для всіх. Це означає, що ті місця, які мають непотрібне тертя, ми повинні видалити. Ті місця, які роблять недоступними для людей, ми повинні видалити. Тож на стороні продукту ви побачите, що сьогодні у нас є Flow Designer, і ви побачите, що ми повністю інвестуємо в те, щоб зробити все більш простою та легшою роботу з такими інструментами, як Flow Designer, для все більшої кількості людей.

У майбутньому будуть інші, які дозволять вам створювати таку композицію дуже легко, і ви побачите з часом, що люди також можуть створювати власні API. Є різні типи API. Ми можемо відразу зрозуміти, які види API. Але коли я їх описав, люди почнуть говорити: зачекайте, API для мене насправді дуже проста річ зрозуміти. Навіть якщо я не дуже досвідчений розробник, навіть якщо я ніколи не вважав себе розробником, вау, це все, що вони мали на увазі під API, це дивовижно. І тоді паралельно ви також повинні допомогти людям, даючи їм навички.

І тому ми тепер є частиною Salesforce, і Salesforce має неймовірну платформу для підвищення кваліфікації людей і розширення навичок. І тому ми схиляємося до цього. Тоді ми маємо обіцянку, що протягом п’яти років ми матимемо 100 000 пілотів інтеграції. Зараз ми говоримо про масштаби. А для людей, яким потрібно зробити це негайно, нам також потрібно прокласти їм шлях і сказати, що саме так інші люди досягли успіху. Тож ви побачите, як ми раз за разом розгортаємо прискорювачі, але загалом у вас є все, що вам потрібно для роботи.

Наприклад, інтеграція з Salesforce, але вони є прискорювачами для речей за межами Salesforce. Наприклад, якщо ви хочете займатися електронною комерцією, як мені використовувати Commerce Cloud? Як переглянути готові API, готові шаблони інтеграції, готові приклади, документацію, еталонні архітектури, всі вони об’єднані разом і доступні там, і їх буде все більше і більше розгорнути. Я думаю, що з часом інші люди створять прискорювачі, і ви матимете екосистему контенту для підтримки екосистеми продукту.

Білл Детвілер: І це одна з речей, яких я також хотів торкнутися. Що, на вашу думку, має зробити галузь, не лише Salesforce, не лише MuleSoft, а галузь загалом, щоб створити ці API? Ви говорите про стандартизацію. Це сталося зі стандартизацією навколо мереж, і ми говоримо про стандартизацію навколо коду та мов. Розмова про стандартизацію навколо API.

Урі Сарід: Так. Неймовірно важливо. І знову ж таки, стандартизація насправді інколи відбувається буквально навколо API, наприклад, давайте використаємо ту саму поверхню API. Найчастіше це насправді стандартизація навколо, наприклад, того, як ми моделюємо дані подібними способами, як ми маємо однакову модель домену для цих речей. Є тисячі способів думати про клієнта. Клієнт є клієнтом, і клієнта, як правило, описують у формі даних, можливо, кількома способами, але це все одно означає, що клієнт. Отже, якщо ми можемо надати це семантичне значення клієнту, замовленню, медичній картці тощо, тоді раптом наші системи можуть стати достатньо розумними, щоб сказати: зачекайте, я знаю, як зв’язати цей запис пацієнта з цим, тому що я знаю їхнього пацієнта записи.

І тоді відображення може почати виконуватися автоматично. Ви вже бачите в Flow Designer, що у нас є машинне навчання, щоб рекомендувати зіставлення. У якийсь момент ці відображення будуть повністю автоматизовані, коли всередині системи буде достатньо впевненості. Тож я думаю, що нам потрібно буде стандартизувати деякі концептуальні моделі, стандартизувати деякі моделі даних, стандартизувати деякі API та переконатися, що є якомога більше стимулів для спільного використання цих видів речей. Це вимагає зміни мислення організації. Замість того, щоб говорити, що це все про мене, ви повинні бути відкритими, щоб поділитися цими речами, принаймні в галузях за галузями.

Білл Детвілер: Чи вважаєте ви, що епоха садів, огороджених стінами, закінчилася, якщо використовувати занадто вживаний термін? Я маю на увазі, що ви бачите цю конкуренцію, ви бачите цю прив’язаність до постачальника. Навіть у сучасному світі багатохмарних технологій, кількох постачальників сумісності, і клієнти, які вимагають більшої сумісності, кажуть: «Я не хочу бути прив’язаним до цього постачальника». Я хочу мати можливість отримати свої дані. Я хочу мати можливість приймати свої програми та переміщувати їх між постачальниками. Чи вважаєте ви, що сьогодні постачальники не можуть продовжувати наполягати на блокуванні? Або ці постачальники просто не досягнуть успіху на ринку, можливо, як це було в минулому через клієнтів просто вимагають більшої сумісності, і ви просто залишитеся на узбіччі або потрапите на перемога?

Урі Сарід: правильно. Тому довгостроково це не працює.

Білл Детвілер: правильно.

Урі Сарід: Короткостроково, організаційній динаміці все ще притаманно сказати: «Гей, я маю тут хорошу справу». Я володію платформою. Наприклад, я володію певною екосистемою. Дозвольте мені схилити його до способів, які принесуть мені деякий дохід у короткостроковій перспективі. Довгостроково це не працює. Тож організації повинні поставити собі питання: чи збираюся я вибрати постачальника, який явно рекламує інтероперабельність, яка показує, що означає інтероперабельність, яка запрошує постачальників у те, що має за своєю суттю відкритість архітектура? Чи піду я з кимось, хто збирається замкнутись?

І я справді думаю, що з часом ми побачимо, що всі основні постачальники охоплять сумісність, а взаємосумісність з часом не повинна означати, що я працюю з ними і я працюю з ними. Сумісність означає, що я працюю над відкритою архітектурою, деякими відкритими стандартами. Я активно ділюся інформацією з іншими постачальниками в цьому просторі і, як наслідок, з нашими клієнтами отримайте вигоду від того, що вони обирають нас з правильної причини, а не тому, що вони заблоковані в.

Білл Детвілер: Вони повинні, тому що всі мої дані, усі інвестиції, які я зробив у цю програму, навчання для моїх людей тут...

Урі Сарід: точно.

Білл Детвілер: І я більше нікуди не можу взяти?

Урі Сарід: точно.

Білл Детвілер: Тож ми торкнулися цього трохи раніше, коли ви говорили про щось на зразок технічної сторони, тому що наша аудиторія трохи технічніша.

Урі Сарід: Так.

Білл Детвілер: Я хотів би закінчити, трохи зазирнувши за вуаль, чи що там відбувається? Ну, що, мабуть, найбільш захоплююче для вас у технічній частині API і що MuleSoft робить зараз?

Урі Сарід: Це відноситься до загальної сфери моделювання. Тож я твердо вірю в те, що коли у вас є хороша, потужна та водночас проста модель проблеми, яку ви намагаєтеся вирішити, ви будете неймовірно швидшими та ефективнішими у фактичному розв’язанні. Під моделями я буквально маю на увазі мову моделювання та структуру моделювання, розглядаючи моделі як дані та належне їх зберігання та надсилаючи запити між моделями. Отже, наприклад, коли ми дивимося на специфікацію API, яка справді розповідає вам у машиночитаний спосіб, як мені насправді, які можливості надає цей API.

Ми не розглядаємо це як документ. Ми не розглядаємо це як блог. Ми розглядаємо це як графік значущих приміток. Що таке змістовна замітка? Це, наприклад, ресурс. З цим ресурсом пов’язані наступні методи HTTP. Це тип даних, який надає цей ресурс. І, до речі, цей тип даних сам по собі є маленьким графіком нотаток. Це реальні дані. Отже, тепер ви можете запитати графік, ви можете запитати ці специфікації API, хлопці, ви послідовні? Які можливості ви розкриваєте? Чи конфіденційна ця інформація тощо.

Зачекайте, ця інформація конфіденційна? Що означає бути чутливим? Перейдемо до чутливості моделі. Перейдемо до моделювання типів даних. Давайте змоделюємо бізнес-семантику. Отже, це не просто повідомлення HTTP, яке повертає 201, це створення рахунку-фактури, яке повертає успішно створений рахунок-фактуру. Ну, як ми змоделюємо бізнес-семантику поверх цього та зв’яжемо її з цією фактичною транзакцією HTTP? І тепер, коли я маю бізнес-семантику природно, технічно, безпосередньо накладену поверх цієї взаємодії, тепер я можу створювати інструменти для бізнес-користувачів, щоб дозволити їм сказати, що б ви хотіли зробити, коли замовлення є створений?
І я можу згенерувати бізнес-подію з цього і сказати, що коли створюється нове замовлення, я хотів би підписатися на нього та створити це, наприклад, ліцензію. А тепер уявіть бізнес-користувачів, які керують своїм підприємством і кажуть: «Я хочу трохи магії». Я хочу сказати, що щоразу, коли генерується рахунок-фактура або щоразу, коли генерується нова ліцензія, я хотів би також залучати цього користувача до певної реклами, щоб змусити його зробити більше. Отже, я думаю, ми побачимо такі інструменти, коли матимемо цю комбінацію справжніх даних моделювання під кришкою.

Білл Детвілер: І це просуває через API відсутність коду, філософію низького коду, чи не так?

Урі Сарід: Так.

Білл Детвілер: Що, я думаю, як і до вашої попередньої точки зору, є чимось, чого ми раніше не бачили, тому що люди думають про API, він начебто складний або просто...

Урі Сарід: точно.

Білл Детвілер: Те, як я виводжу дані чи щось таке...

Урі Сарід: точно. точно. І я думаю, що саме тут я вже говорив про різні типи API, ми також повинні усвідомити, що можливість публікувати події також є API. Це теж договір. Ви можете покластися на те, що я публікую вам події, щоб ви могли щось зробити з цими подіями. Тому ми інвестуємо значні кошти в AsyncAPI, який є відкритою специфікацією того, як ви фактично фіксуєте ці події та перетворюєте їх на контракти. Отже, куди ми йдемо, це внизу в самій структурі, так само, як це була структура для Інтернету з HTML і HTTP для узгодження вмісту.

Ми опускаємося до самої структури того, що ми називаємо мережами додатків, і говоримо, що таке стандартні частини і стандартні моделі, які мають бути на місці, щоб дозволити створювати все на основі цього якнайпростіше спосіб?

ПОНЕДІЛОВИЙ РАНОК ZDNET

Monday Morning Opener — це наш вступний залп тижня в галузі технологій. Оскільки ми керуємо глобальним сайтом, ця редакційна стаття публікується в понеділок о 8 ранку за східним часом у Сіднеї, Австралія, тобто о 6 вечора за східним часом у США. Він написаний членом глобальної редакційної колегії ZDNet, яка складається з наших провідних редакторів з Азії, Австралії, Європи та Північної Америки.

• Salesforce грає в багатохмарну гру з Microsoft Azure, Google Cloud як договір AWS, який, ймовірно, буде продовжено
  
• Екосистема Android не готова до підліткового Pixel 4
• Ми повинні перестати посміхатись на шляху до держави, за якою ведеться спостереження
• Nike робить ставку на технічного директора Донаго, щоб прискорити цифрову трансформацію: чи спрацює це?
  
• Колишній керівник служби безпеки Twitter ділиться своїми порадами щодо найму спеціалістів з ІТ-безпеки та кібербезпеки
• ПК чи розкладний телефон? Ось і постає ваша наступна велика дилема пристрою
  
• У Китаї Apple є iPhone
  
• Генеральний директор Carvana Ерні Гарсія про науку про дані, інвестиції в технології та руйнування галузі
• Чому один розробник Java перейшов до Salesforce і не озирався назад