Що робить Erlang придатним для хмарних додатків?

Ми починаємо новий проект і впроваджуємо на базі наших корпорацій відкриту хмару (див. Http://www.openstack.org/ ). Проект є інструментом безпеки для нашої корпорації. В даний час ми запускаємо багато сотень виділених серверів для інструментів безпеки і передаємо їх нашим корпораціям для відкриття атаки.

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

Які сильні сторони erlang для хмарного програмування? Де є області, в яких особливо доречно використовувати ерланг?

cloud-computing erlang

— Дункан
джерело

Визначте "хмару", і ми можемо сказати вам, що ви можете знати. Термін "хмара" - це маркетинговий розмова і означає щось інше для кожної людини, яка ним користується.

Я думав, що сказати, що хмара opentack буде достатньою для визначення того, що ми реалізуємо. Дивіться openstack.org . Або ви вимагаєте отримати додаткову інформацію про проект? Це інструмент безпеки для нашої корпорації. В даний час ми запускаємо багато сотень виділених серверів для інструментів безпеки і передаємо їх нашим корпораціям для відкриття атаки.

— Дункан

Я відредагував питання, щоб сподіватись, що це покращиться і усунув проблему "маркетингу". Моє питання полягає у виборі найкращого інструменту для роботи. Я новобранець у stackexchange, тому не дуже сподіваюся на це.

— Дункан

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

"термін" хмара "туманний" - хороший! Це означає, що щось віртуальне, і вам слід вказати, чи є це "щось" програмним забезпеченням, операційною системою, одномашиною, багатомашиною та мережею чи чимось іншим.

— GlenPeterson

Відповіді:

Окрім того, що Erlang був спеціально розроблений для запуску в паралельних / паралельних / розподілених ситуаціях, дві основні методи, які він використовує, роблячи це можливим, це:

Ніяких побічних ефектів:

Це означає, що коли ви даєте функції функцію, яку слід виконати проти, вона не буде за винятком випадків, коли в дуже суворих випадках впливатиме на що-небудь інше в системі / запущеному процесі. Це означає, що якщо функцію виконувати 300 разів одночасно одночасно, жодне з цих 300 виконання функції не вплине на жодне з інших.

Техніка реалізації для забезпечення відсутності побічних ефектів називається "незмінністю", що, грубо означає, не може бути мутованою (зміненою). Це означає, що як тільки ви створюєте змінну, значення цієї змінної може не змінюватися. Erlang реалізує цю поведінку з "єдиним призначенням", тому після того, як ви присвоїте значення змінній, ви можете не призначити їй значення знову.

X = 1.
X = 2. // This is not a valid operation

Це гарантує, що жоден код не може випадково змінити значення X, спричиняючи перегоновий стан, тому воно, по суті, є безпечним для потоків і одночасне використання стає тривіальним. Це дуже незвична поведінка серед мов програмного забезпечення, і найбільший спосіб, коли Erlang встигає так добре підходити для одночасного виконання.

Акторська модель:

Це особливий спосіб моделювання, який показав, що робить розробку та управління одночасною обробкою дуже простою. Прямо з wikipedia (http://en.wikipedia.org/wiki/Actor_model):

Модель Актора приймає філософію, що все - це актор. Це схоже на все, що є об'єктовою філософією, яка використовується деякими об'єктно-орієнтованими мовами програмування, але відрізняється тим, що об'єктно-орієнтоване програмне забезпечення, як правило, виконується послідовно, тоді як модель Actor за своєю суттю є одночасною. Актор - це обчислювальна сутність, яка у відповідь на отримане повідомлення може одночасно: надсилати кінцеву кількість повідомлень іншим суб'єктам; створити скінчену кількість нових акторів; позначити поведінку, яку слід використовувати для наступного повідомлення, яке воно отримує. Немає передбачуваної послідовності вищезазначених дій, і їх можна було б проводити паралельно. Від'єднання відправника від надісланих комунікацій було принциповим просуванням моделі Актора, що дало можливість асинхронним структурам зв'язку та управління як моделей передачі повідомлень.

— Джиммі Хоффа
джерело

Про "Без побічних ефектів" ви говорите "Це дуже незвичайна поведінка серед мов програмного забезпечення" - я трохи здивований цьому. Не можете Java та C # зробити це сьогодні? Які мови ви знаєте, що мають викликати побічні ефекти при виклику функції?

— NoChance

@EmmadKareem Це не питання про те, чи можна писати програму без побічних ефектів; як ви зазначали, це можна зробити на Java або C #. Це, чи за замовчуванням немає побічних ефектів, і чи є підтримка компілятора для цього. Наприклад, у Java ви не можете сказати компілятору "у цього методу немає побічних ефектів". Це в свою чергу означає, що компілятор не може попередити вас, коли ви порушуєте правила!

— Андрес Ф.

@EmmadKareem Я не кажу, що неможливо написати C # або java без побічних ефектів (хоча це вкрай рідко), швидше кажу, що дуже мало мов програмування мають чітку політику, вбудовану в мову, яка відокремлює функції з побічними ефектами від тих, хто не має.

— Джиммі Хоффа

Було б чудово, якби Java мала анотацію @NoSideEffects, щоб застосувати метод, який повідомив компілятору примусово використовувати побічні ефекти для цього методу. У власному коді мені подобається вважати, що для методів немає побічних ефектів. Звичайно, деякі методи повинні бути мутаторами на такій мові, як Java, але багато хто не робить. Особливо, якщо ви віддаєте перевагу незмінним предметам у своїх конструкціях.

— GlenPeterson

Джиммі Хоффа та @AndresF., Дякую за роз'яснення.

— NoChance

Ерланг особливо сильний у паралельних / паралельних обчисленнях. Насправді він був розроблений спочатку саме для цієї мети. Це не має нічого спільного з хмарою, за винятком випадків, коли обчислювальні додатки паралельно розгортаються та розгортаються у "хмарних" випадках, щоб полегшити зростання / зменшення потужностей на вимогу.

Решта - лише маркетингово-розмовна.

— пап
джерело

Ерланга був розроблений для відмовостійких обчислювальних систем . Просто розподілене обчислення є необхідною умовою для цього (як можна надійно повернути результат, якщо хтось випадково проливає каву над вашою єдиною машиною, вам потрібно щонайменше дві машини) і паралельні та паралельні обчислення - це лише особливі випадки розподілених обчислень, тому Ерланг також буває хорошим у них. Але це не те, для чого було призначено.

— Йорг W Міттаг

@ JörgWMittag Поки ми ділимо волоски ... так, метою було досягти відмовостійкості. Цього вона досягла шляхом паралелізації. Він був розроблений для втілення цього в цифровий телефонний комутатор AX, який здійснював два ізольованих паралельних обчислювальних труби, причому одна працює в режимі гарячого очікування.

— пап

Так, вибачте, я мав би бути більш зрозумілим: хмарні обчислення розповсюджуються в значній мірі за визначенням, і це часто (не завжди, але зазвичай) реалізовано кластерами недорогих і, що важливіше ненадійних машин, але призначених для надання надійної послуги. Ось що робить Ерланг такою вдалою.

— Йорг W Міттаг

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

Це особливо так, якщо ви будуєте свою систему, використовуючи OTP (Open Telecom PLatform) рамки Erlang, яка забезпечує структуру та механізми (керівники дерев) для підтримки побудови деяких досить складних речей з набагато меншим ефектом, ніж ви могли собі уявити. Ерланг обробляє всі хитрі шматочки, щоб не потрібно.

— Гаррі Ходжсон
джерело