Антон Коренюшкін (Akshell) PaaS для виконання JavaScrip на сервері
Спільнота керівників ІТ-компаній, ІТ-підрозділів та сервісних центрів
учасників є співробітниками ІТ-компаній
20% з них - співвласники бізнесу
працюють у ІТ-службах інших компаній
Увійти за допомогою:
Авторизація
Новим користувачам
Презентація
Стенограма
Я почну взагалі з платформ. Чому всі говорять про платформи? Чому все роблять платформи в останній час? Відповім у наступному ключі. уявіть собі, що щоб доїхати сюди на автомобілі, вам для початку потрібно зібрати ось ці деталі. По-перше, не багато хто б із цим впорався. По-друге, це триває час. А по-третє, це довелося б робити кожному. І в певному сенсі web-розробка влаштована, почасти так. Тобто існує безліч інструментів, безліч програмного забезпечення для того, щоб створити веб-додатки. Але програмістам, розробникам доводиться начебто заново все це розгортати на своїх серверах, налаштовувати, адмініструвати і так далі. А взагалі, якщо доходить справа до масштабування, то тут взагалі все зрізу стає складно. Тому останнім часом пропонується безліч Platform as a Service (PaaS).
Основні переваги таких речей. Як характерні приклади можна навести Google App Engine, Oracle, призначені для будь-яких web-додатків взагалі. Або платформа Force.com призначена для бізнес-додатків. Переваги платформ очевидні. Це, по-перше, простота використання, порівняно з тим, щоб розгортати все це на своєму сервері. автоматична масштабованість. Мало хто собі насправді уявляє, що це таке. Тобто ваш додаток описує бізнес-логіку, аколи ви свій бізнес-додаток переносите на сервер, про це дбає платформа, що значно спрощує життя. Природно, значно менше турбот щодо адміністрування програми. Зазвичай клієнт не представляє всіх необхідних для роботи з базою даних інструментів, і не знає про набагато більшу кількість речей. Це, власне, залежить від специфіки платформи. Якщо це Google App Engine, то це в нас, в основному, база даних, причому дуже специфічна. Якщо це Force.com, то це безліч інструментів для бізнесу, для створення програми, що саме автоматизує бізнес-процеси. Ну, і зазвичай, крім усього цього, платформа надає якесь своє багате середовище, в якому можна збирати додатки з цеглинок. Тобто це набір бібліотек, набір сервісів на платформі і так далі.
Але її великий недолік у тому, що бізнес-логи прописані в такий спосіб, що це просто неможливо. Код перетворюється на «спагетті» з comeback-ів і це абсолютно нечитаемо. Тобто, що можна зробити в 2 рядки на традиційній парадигмі, в HMGS перетворюється на 20 рядків, причому, складністю в 8 рівнів. Але є спроби, одну з них ми зараз робимо, думаємо над нею. Я розмовляв із творцем нода на Keyskont, і за допомогою кейту є можливість створити легковажні процеси. У нього є поняття так званого контексту, і за допомогою цих контекстів можна створити кілька стеків виконання, і кожен стек, вони один від одного залежні, тобто у них якась одна загальна глобальна неуспейс, але при цьому стеки у кожного процесу будуть різні і створювати нові такі стеки досить дешево. І за рахунок цього можна зробити як би багатозадачність, як би стріт. Це буде реалізовано в такий спосіб. У єдиному головному будівельнику виконується асинхронний код, а вДодаткових виконується синхронний код, там немає блокуючого виклику і ми як би повертаємося в головний, і в основному здійснюємо руками перемикання між додатковими стрета, таким чином, створюємо новий код, і програмується бізнес-логіка.
Але є там деякі проблеми, знову ж таки. Проблеми, зокрема, з нотом та проблеми ось із цією моделлю. Weeton був створений для браузера, а не для сервера. І це накладає певне обмеження. Головне обмеження, це те, що він повільно запускається, повільно створює потоки, тому використовувати з контекстами, як я казав, в принципі, можливо, якщо контексти створювати швидко. І друге обмеження. Наприклад, він взагалі не підтримує стрічок від операційної системи, але він в єдиному рядку працює, і коли в нього включається гамбридж колешіон, а включається вона у нього невідомо коли, все заморожується. Тобто, якщо ви пишете додаток на ноді і ви не подбаєте про те, щоб він працював у багатьох процесах, то періодично він заморожуватиметься.
Наступна ініціатива – це Naurwal. Це навіть не платформа, а якась ініціатива створити поверх платформи загальний API. Нині вона є, але широко не використовується.
Остання – це наша улюблена платформа Akshion. Вона якраз створена для розробки бізнес-додатків. Вона має синхронні API. Це лише частина нашої платформи. Крім того, на ній можливі розробки браузерні. Можна зайти на її веб-сайт. Одним кліком можливі розробки. Можна написати код та одним кліком зберегти результати в інфраструктурі.
До речі, я ще забув сказати, що для нода існують, вони ростуть як гриби, сервіси, які хостить нод. Інтерфейс там простий, без жодної сервіс-розробки. Просто пишете код та робите туди. Власне, і весь інтерфейс.Крім цього, існує ще безліч Platform as a Service для нода. Насправді вони з'являються пачками, але створити базову якусь платформу, це справа окрема. Створити щось дійсно масштабоване і надійне, це, звичайно, складніше.
Ось, власне, все, що я хотів розповісти.
З залу: Чи грає роль продуктивність платформи?
Паралельно, себто, за трендами паралельно?
Із залу: Ну, так. Ну, може, для окремих машин.
Ну, звичайно, для окремих машин окремі тренди. Тут відомо, що з певних дій ми маємо домогтися шляхом програмування виконання якихось оптимальних дій. Головна відмінність, наприклад, у разі нода від Java тієї ж, вона полягає в асинхронності. Тобто, як ви обробляєте запити в традиційному середовищі, наприклад, ви запитуєте щось з бази даних і чекаєте, поки виконається.
Уявіть, що ви пишете IRC сервер. Це для нода класичний приклад. У серверній частині сервера IRC що відбувається? А відбуваються там довгі нитки реєстру. Ваш браузер робить запит на сервер, а сервер не дає відповіді, а як би притримує це з'єднання, тобто для цього створюється окремий рядок. Зайшло 200 людей на ваш IRC сервер, вам доведеться тримати 200 стреків. Зрозуміло, що це просто не масштабується, це неприйнятно, тим більше, всі ці стрілки просто висять. У той час, як у ноді вам достатньо одного потоку, одного процесу, який оброблятиметься асинхронно. Надійшло повідомлення від якогось користувача, ви по всіх канальчиках розіслали відповіді, але відповіді відбуваються асинхронно. Тобто ви не висите ні на чому, немає блокуючих викликів. У цьому головна відмінність нода. І, враховуючи, якісь браузерні доповнення та додатки, оновлення у браузері, це ідеальна платформадля бізнес-логіки Тому, як я вже казав, ми намагаємося взяти найкраще з обох світів і налагодити ці бізнес-процеси.
А Python хтось використовує? Ні? Тільки Java?
З залу: А Key Code для двигуна використовується?
Останні повідомлення з'являлися про те, що на Facebook його збираються використати. Але це дуже давня історія. Тієї ж асинхронності не Райян придумав. Якщо ви пам'ятаєте, був такий сервіс Funkle, він і зараз використовується. Для нього ще створили серверний Python, який робить фактично те саме. Так як Python не такий зручний, щоб на ньому не зробити блокуючий виклик, це потрібно дуже постаратися, потрібно використовувати тільки API твістів. Відповідно, було розроблено інші платформи. Але жодна з них не набула такої популярності як нід. Власне, стрічка новин на Facebook за допомогою твісту реалізована. За рахунок цього ви на ній можете отримувати дані по апдейту, тобто не чекати щоразу, а зайти на нього і одразу дивитися стрічку новин. Власне для цих речей і призначене нетипове програмування.
Чому б і ні. У сенсі для надання API?
Робити на ньому шаблони htme незручно, тобто це бізнес-логіка, це незручно, він для цього не призначений. Саме створювати копірейти на ньому добре, тому що ви можете створювати асинхронні речі, пам'ятаєте, що я говорив? Саме для цього він призначений найбільше. Сучасні web-додатки… Не те, щоб це єдиний спосіб, але багато хто так робить. В офісі ви колись отримуєте на сторінку від сервера початковий якийсь код клієнтський, і всі інші оновлення ви через API робите. І, відповідно, все оновлюється у самому клієнті. А сервер, він не отримує такої купчастості з'єднань.
Ну, ось наш приклад наведу розробки. Цеабсолютно односторінковий додаток. Тобто ви один раз отримали тестодемейд, який, природно, закешувався, і все інше ви на цих кнопках відкриття меню і так далі. Це вже через серверний API. Тобто, це фактично сервісна єдина.
Для того щоб створювати інтернет-магазини, напевно, це не найкраще рішення. Ось, як я й говорю, бізнес-логіка не товаришує з асинхронністю, тому що бізнес-логіка описує, що ви хочете. Хочу це, хочу це, хочу це. А не «зроби мені це, а потім виклич мені того». І потрібний ще один comeback, щоб повернутися і зробити це. Але я впевнений, що нам вдасться взяти найкраще з обох світів і створити платформу, яка була б універсальною.
Є стартап NauES, він створює речі, які синхронізують, роблять видимість одного середовища, на тому ж Google Space і так далі. Зрозуміло, що одного сервера буде недостатньо. Тим більше, що за такої моделі в цьому сервері використовуватиметься одночасно багато процесів. І потрібно за допомогою обміну легковажними повідомленнями підтримувати саме активні середовища, але це зараз поки що створюється.